Workflow & Core Tools · mattpocock/skills

to-tickets

Name: to-tickets
Author: mattpocock/skills

Break a plan, spec, or the current conversation into a set of tracer-bullet tickets, each declaring its blocking edges, published to the configured tracker (edges as text in one file per ticket locally, or native blocking links on a real tracker).

L4 High-Privilege · Graded auth & full auditV1 Commit-PinnedExternal WriteNetwork AccessWrite FileDual-pass Audit

Control levels describe skill capabilities and suggested control measures; they do not represent quality or safety certifications, nor do they dictate usability. Usage decisions rest entirely with users and administrators. Different agent hosts apply varying constraints; do not assume hosts provide automatic protection. Third-party skill copyrights belong to their original authors. Use at your own risk.

1How It Works & Mechanism

Pure prompt orchestration: The entire skill consists of a decomposition discipline for the model plus two output templates, with no scripts, no template files, and no runtime code. The artifact produced is not a document, but rather 'a set of tickets with blocking edges'.

skills/engineering/to-tickets/SKILL.md

Break a plan, spec, or conversation into a set of **tickets**: tracer-bullet vertical slices, each declaring the tickets that **block** it.

Actual directory inspection confirms only SKILL.md and agents/openai.yaml; the two templates (local / tracker) are embedded inline as Markdown within the main body.

Name evolution: The queue slug `to-issues` was removed at pinned HEAD—v1.1 merged to-plan and to-issues into to-tickets, completely eliminating to-issues (its capabilities were absorbed into the new skill).

CHANGELOG.md

**`to-plan` and `to-issues` are merged into one `to-tickets` skill, and `to-issues` is deleted.**

The same CHANGELOG notes that PR #469 (a0329ba) previously added wide-refactor (expand–contract) support to to-issues; this capability now exists entirely within the body of to-tickets, serving as concrete proof that 'legacy to-issues features have been merged'. This JSON records it under the actual HEAD name to-tickets.

The core mechanism is tracer-bullet vertical slicing combined with blocking edges: each ticket must cut through all layers (schema/API/UI/tests), be independently demonstrable, fit within a single fresh context window, and explicitly declare what blocks it; tickets with no blockers form the immediately workable frontier.

skills/engineering/to-tickets/SKILL.md

- Each slice cuts a narrow but COMPLETE path through every layer (schema, API, UI, tests): vertical, NOT a horizontal slice of one layer

The same section is supplemented by three other rules: demonstrable upon completion, single-window capacity, and prefactors first. Step 3 of the upstream workflow requires labeling each ticket with its blocking edges ("Give each ticket its **blocking edges**"), and Step 5 defines progression via the frontier ("Work the **frontier**: any ticket whose blockers are all done.").

Wide refactoring is an explicit exception to vertical slicing, scheduled instead via expand–contract: first add the new pattern, then migrate in batches by blast radius, and finally remove the old pattern; when even batched migrations cannot stay green, a shared integration branch is permitted where all batches block a final integration ticket.

skills/engineering/to-tickets/SKILL.md

**Wide refactors are the exception to vertical slicing.** A **wide refactor** is one mechanical change (rename a column, retype a shared symbol) whose **blast radius** fans across the whole codebase, so a single edit breaks thousands of call sites at once and no vertical slice can land green. Don't force it into a tracer bullet; sequence it as **expand–contract**.

This is the repo's dedicated solution for tasks like 'renaming a single column that breaks thousands of call sites'; the docs spend an entire section elaborating on this, specifically noting that 'green is only promised on the integration ticket'.

Mandatory user quiz before publishing: the decomposition is listed by number (title / blocked by / delivered behavior), querying item by item about granularity, edge correctness, and whether to merge or split, writing to the tracker only after user approval.

skills/engineering/to-tickets/SKILL.md

Are the blocking edges correct: does each ticket only depend on tickets that genuinely gate it?

This step directly combats horizontal slicing failure modes: the docs cite 'slicing by technical layer (one ticket for schema, one for API)' as a frequent pitfall, recommending the quiz stage interrogate each ticket with 'what does finishing this ticket demonstrate?'.

Output format adapts to the tracker switch, expressing blocking edges differently: local mode uses one file per ticket ordered by dependency (blockers first) and explicitly forbids combining them into a single file; real tracker mode creates issues in dependency order, prioritizing native blocking/subtask relationships and adding the ready-for-agent label.

skills/engineering/to-tickets/SKILL.md

- **Local files** → write one file per ticket under `.scratch/<feature-slug>/issues/<NN>-<slug>.md`, numbered from `01` in dependency order (blockers first). Each file's "Blocked by" lists the numbers/titles it depends on. Use the per-ticket file template below: one ticket per file, never a single combined file.

The real tracker branch appears on line 63, accompanied by the boundary discipline "Do NOT close or modify any parent issue." (line 67). The local one-file-per-ticket format also fixes concurrent write race conditions (docs: the root-level tickets.md in v1.1 was a bug that caused races).

2Core Capabilities

01Plan/Spec/Conversation → Ticket Collection: Capable of decomposing all three input types without requiring an existing written spec

02Vertical Slicing Discipline: End-to-end thin slices cutting across all layers, independently demonstrable, and completable within a single window

03Blocking Edge Declaration: Each ticket specifies prerequisite tickets, constructing a dependency graph ready for parallel evaluation

04Wide Refactor Expand–Contract Scheduling: Expand → batched migration → contract, leveraging shared integration branches when necessary

05Prefactor Prioritization: Surfaces refactoring opportunities that simplify downstream changes and places them first

06User Quiz Gate: Three-question check on granularity, blocking edges, and merge/split proposals, publishing only upon approval

07Dual-Template Publishing: Local mode with one file per ticket (NN prefix acts as ticket ID, e.g., /implement 03) or real tracker mode creating issues labeled ready-for-agent

08Input Reference Fetching: Fetches and reads full text and comments when user supplies spec paths, issue numbers, or URLs as arguments

09Anti-Staleness Discipline & Parent Issue Boundaries: Omits file paths and code snippets from ticket bodies (except prototype decision snippets) and leaves parent issues untouched

3External Dependencies

Kind	Dependency / Endpoint
cli	gh（GitHub CLI）——条件依赖，真 tracker 模式下的发布与原生依赖关系操作
cli	glab（GitLab CLI）——条件依赖
network	GitHub Issues + 原生 issue dependencies API（经 gh 批量建票、加阻断边、打标签）
network	用户以参数传入的任意 URL：skill 指示 fetch 该引用并读全文与评论（取数面由参数决定，未见主机白名单）
package	skills CLI / Claude Code 插件（分发渠道）

4Recommended Governance & Evidence

Suggested Controls for Safe Operation

For Agent Runtime

Graded/per-use authorization, sandbox recommended

For Administrators

Approval workflow, rollback support, full audit

Evidence & Triggers (File Paths & Excerpts)

外部 API: Executes posts, resource creation, or modification writes to external platforms
本地工作目录: File read/write and artifact output: Local mode: `.scratch/<feature-slug>/issues/<NN>-<slug>.md` one file per ticket, numbered in dependency order (combining into a single file is forbidden)

Audit Notes: Pure prompt skill: no script execution, no credential reads, and no network endpoints in files. Marked yellow because its final action modifies external state in batches—creating N issues with labels in real tracker mode (where N equals ticket count) or writing N files in local mode; furthermore, it includes a user-parameterized fetch entry point (reading full issues/URLs and comments), representing an expected data-retrieval surface. Triggering surface is tightly restricted by dual manifests (disable-model-invocation: true + allow_implicit_invocation: false), allowing only explicit user invocation, backed by a pre-publish human quiz gate. Does not qualify for orange: does not read credentials and does not execute unpinned third-party packages.

5Second-Pass Verification

[discrepancy] 队列 slug `to-issues` 在 pin commit 是否作为目录存在 — 不存在。HEAD 树内无 skills/engineering/to-issues（也无 to-tickets 之外的 to-plan）；CHANGELOG 明写 '`to-plan` and `to-issues` are merged into one `to-tickets` skill, and `to-issues` is deleted.'。本 JSON 以 HEAD 实名 to-tickets 记录，页面 slug 与文件名沿用任务书的 to-issues。
[ok] 『to-issues 的功能确已并入 to-tickets』是否属实（而非删掉即失去） — CHANGELOG PR #469 记 to-issues 曾获得 wide-refactor（expand–contract）与 Co-located reference blocks；现行 to-tickets/SKILL.md line 40 完整保留该段（expand/migrate/contract 与集成分支兜底），说明能力是迁移而非丢失。
[ok] 阻断边的落点是否真由 tracker 文档决定（而非 skill 硬编码路径） — to-tickets 正文只给形态要求（'Use the platform's native blocking / sub-issue relationship where it has one'）与本地路径约定；具体命令（gh api …/dependencies/blocked_by、gh issue edit --add-assignee 等）与 frontier 查询定义全在 setup-matt-pocock-skills/issue-tracker-github.md 内，两处措辞一致。
[ok] 『无网络外发』类声明是否成立 — skill 文件 token 扫描无 http/curl/fetch 关键字；网络行为全部经 tracker 文档定义的 gh/glab 间接发生，已按条件性记入 network_calls。
[discrepancy] 取参 fetch 是否有限制（主机白名单/大小/去指令化） — 定位不到任何限制：SKILL.md 只写 'fetch it and read its full body and comments'，无主机白名单、无大小上限、无 untrusted/防注入条款；对超长 spec 的截断问题反倒在 docs 页被当作环境问题（建议同窗口不要 clear/compact）来描述，说明 skill 层面无防护。此点按「定位不到不硬写」只记事实，不升级档位。
[ok] installs / stars 口径 — installs=353800 来自 skills.sh 注册表的旧 slug 记录（queue-100.json 的 to-issues 条目），仓库内无此数值；stars=262519 为 2026-09-15 gh api 实测。口径不同，页面并列时需标注来源。

6Verdict & Scenarios

Dependency graph as a first-class citizen: Every ticket must declare blocking edges, where unblocked tickets form the frontier—baking parallelism directly into artifacts rather than leaving it to verbal coordination

Actionable vertical slicing criteria (cuts across all layers / independently demonstrable / single-window capacity / prefactors first), paired with the quiz check ('what does this demonstrate?') to intercept horizontal slicing failures

Pragmatic approach to wide refactoring: Acknowledges mechanical changes that cannot be tracer-bulleted, providing expand–contract and integration branch fallbacks

Pre-publish human checkpoint: Granularity, blocking edges, and merge/split review + explicit approval prevents flushing flawed decompositions to the tracker in a single run

Shared dual templates for local and real trackers, with local one-file-per-ticket fixing previous single-file race conditions and unreferenceable ticket IDs

Best for: Ideal for engineering tasks where architectural decisions are settled but the work spans multiple context windows: decomposes specs or discussions into independently demonstrable, single-window tickets with visualized dependencies to spin up parallel agent sessions. Also suitable for teams needing to schedule wide refactorings via expand–migrate–contract, or skill authors looking to adopt a dual-template plus interactive quiz gating pattern.

Not for: Not suitable for changes that can be completed within a single context window (docs recommend /implement directly); not for early stages lacking decisions (use grilling → to-spec first); not for users expecting automated ticket dispatching, auto-closing, or autonomous progress tracking; and not suitable for repositories without setup-matt-pocock-skills, or scenarios requiring strict tracker-side consistency (native subtasks/blocking links) without manual gh CLI follow-ups.

Install Agent-Ready

① Verified Mirror 2026-09-15

Option A · Direct DownloadDownload to-tickets.tar.gz

sha256: 0a4d30fcc2a2ce67…

Option B · Copy Guide for Agent

install.json

Agents automatically download and verify mirrors from this JSON guide.

② Upstream GitHub

GitHub Repo ↗

Pinned to commit 3cca18b368.