1实现原理 · 为什么它能做到
纯 prompt 编排：整份 skill 是给模型的一套拆解纪律 + 两个输出模板，无脚本、无模板文件、无运行时代码。产出物不是文件而是「一组带阻断边的工单」。
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.
目录实测仅 SKILL.md 与 agents/openai.yaml；两种模板（本地 / tracker）以 Markdown 内联在正文中。
名称沿革：队列 slug `to-issues` 在 pin HEAD 已被删除——v1.1 把 to-plan 与 to-issues 合并为 to-tickets，to-issues 整体消失（其能力被吸收进新 skill）。
CHANGELOG.md
**`to-plan` and `to-issues` are merged into one `to-tickets` skill, and `to-issues` is deleted.**
同 CHANGELOG 另记 PR #469（a0329ba）曾为 to-issues 加 wide-refactor（expand–contract）能力，该能力现完整存在于 to-tickets 的正文里，可作为「旧 to-issues 功能已并入」的实证。本 JSON 以 HEAD 实名 to-tickets 记录。
核心机制是 tracer bullet 垂直切片 + 阻断边：每张工单必须切穿所有层（schema/API/UI/测试）且能独立演示，尺寸限定在一个新鲜上下文窗口内，并显式声明「被谁阻塞」；无阻塞者即为可立即开工的 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
同段落另三条规则补足：完成即可演示、单窗口容量、prefactor 先行。前端流程第 3 步要求给每张票标出 blocking edges（"Give each ticket its **blocking edges**"），第 5 步用 frontier（"Work the **frontier**: any ticket whose blockers are all done."）描述推进方式。
宽重构是垂直切片的显式例外，改按 expand–contract 排程：先加新形态、再按爆炸半径分批迁移、最后删旧形态；连分批都难保绿时，允许共用集成分支并让全部批次阻塞一张最终联调票。
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**.
这是 repo 内针对「重命名一列却炸掉上千调用点」这类工作的专门解法；docs 页用整节复述并把「绿只承诺在集成票上」单独点出。
发布前必过用户 quiz：把拆解结果按编号列出（标题/被谁阻塞/交付什么行为），逐条问粒度、阻断边是否正确、是否该合并或拆分，直到用户批准才写入 tracker。
skills/engineering/to-tickets/SKILL.md
Are the blocking edges correct: does each ticket only depend on tickets that genuinely gate it?
该步与反横切失败模式直接挂钩：docs 页把「产出按层切（schema 一张、API 一张）」列为高频失败，并建议在 quiz 阶段用「这张票做完能演示什么」逐张盘问。
输出形态随 tracker 切换而阻断边表达不同：本地模式一票一文件、编号即在依赖序（blockers first），明令禁止合并成单文件；真 tracker 模式按依赖序建 issue，优先用平台原生阻塞/子任务关系，并打 ready-for-agent 标签。
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.
真 tracker 分支见 line 63；另有边界纪律「Do NOT close or modify any parent issue.」（line 67）。本地一票一文件的形态也是并发写冲突的修复（docs：v1.1 的根级 tickets.md 是 bug，会 race）。
2核心能力
01计划/规格/会话 → 工单集合：三种输入都能拆，不强制先有书面 spec
02垂直切片纪律：切穿所有层的完整细径，可独立演示，单窗口可完成
03阻断边声明：每张票标出必须先完成的其它票，形成可并行判断的依赖图
04宽重构 expand–contract 排程：expand → 分批 migrate → contract，必要时共用集成分支
05prefactor 前置：先找让改动变简单的重构机会并排在最前
06用户 quiz 闸门：粒度/阻断边/合并拆分三问，批准后才发布
07双模板发布：本地一票一文件（NN 前缀即票号，可 /implement 03）或真 tracker 建 issue 并打 ready-for-agent 标签
08输入引用抓取：用户以参数传入 spec 路径/issue 号或 URL 时，取回并读全文与评论
09反陈旧纪律与父票边界：票正文不写文件路径/代码片段（原型决策片段例外），且不动父 issue
3外部依赖
| 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 插件（分发渠道） |
4管控建议与判定依据
建议配套管控措施
面向 Agent
分级或逐次授权，建议在沙箱运行
面向管理者
审批流程、可回滚、全程审计
判定依据（文件路径与关键语句摘要）
- 外部 API: 向外部平台执行发帖、资源创建或修改写入
- 本地工作目录: 文件读写与工件输出: 本地模式：`.scratch/<feature-slug>/issues/<NN>-<slug>.md` 一票一文件，按依赖序编号（禁止合并成单个 t
审计说明： 。纯指令 skill：无脚本执行、无凭证读取、文件内无网络端点。定黄的理由是它的完成动作会批量改变外部状态——真 tracker 模式下一次运行创建 N 张 issue 并打标签（N=票数），本地模式下写 N 个文件；且它有一个由用户参数决定主机的 fetch 入口（读 issue/URL 全文与评论），属可预期的常规取数面。触发面受双清单约束（disable-model-invocation: true + allow_implicit_invocation: false），只能用户显式调用，且发布前有 quiz 人工闸门。未触橙：不读凭证、不依赖未 pin 的第三方包执行。
5第二遍独立确认
- [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 实测。口径不同，页面并列时需标注来源。
6结论
适合： 适合决策已定、工作跨多个上下文窗口的工程任务：把 spec 或会话拆成可独立演示、单窗口能完成的票，并让依赖关系可视化以便并行开多个 agent 会话。也适合需要把「宽重构」这类反例工作排成 expand–migrate–contract 的团队，以及想抄「双模板 + 人工 quiz 闸门」写法的 skill 作者。
不适合： 不适合能在单个上下文窗口做完的改动（docs 直接建议走 /implement）；不适合还没有任何决定的阶段（应先 grilling → to-spec）；不适合期望 skill 自动派发工单、自动关票或自动维护进度的人；也不适合未跑 setup-matt-pocock-skills 的仓库，以及需要 tracker 侧强一致（子任务/阻塞关系必须原生落地）而不愿事后用 gh 手工补齐的场景。
Install Agent-Ready
① Verified Mirror 2026-09-15
Option A · Direct DownloadDownload to-tickets.tar.gz
sha256:
Option B · Copy Guide for Agent0a4d30fcc2a2ce67…agent 读 JSON 指南后会自动从本站下载安装，无需更多说明。
② Upstream GitHub
GitHub Repo ↗
Pinned to commit 3cca18b368.