用途：把计划或规格拆解为独立可领取的 issue，采用贯穿各集成层的垂直切片（曳光弹）方式，issue 以仓库内 markdown 文件形式存在，不依赖外部 issue 跟踪器。issues/ 即跟踪器，BACKLOG.md 是入口。
主要能力与产物：默认路径为 issues/BACKLOG.md（仅 todo 与进行中）、issues/ARCHIVE.md（验收后移入）、issues/NNN-kebab-case-title.md（issue 文件）、CONTEXT.md（领域词汇表）、docs/INTENT-AND-DESIGN.md 或 docs/REQUIREMENTS-AND-NOTES.md（产品规格）。若仓库已有不同命名，以仓库命名为准。缺失词汇表或规格时仅说明一次并从对话起草，不在此创建。若跟踪器不存在，需先按 backlog-template.md 创建 BACKLOG.md 与 ARCHIVE.md，再写任何 issue 文件。
两种模式：Breakdown 模式用于新范围、需多个依赖切片，执行完整流程；Straggler 模式用于单个自包含的后续项（bug、文档同步、小改动、回归），跳过第 3、4 步，直接写单个 issue 文件、追加一行 BACKLOG 并把 Blocked by 设为 —，报告 id。已完成 issue 的回归应新建 issue，不重开或修改已完成文件。
流程：1) 收集上下文，读取对话、相关 issue 文件、词汇表、规格、BACKLOG.md 与 ARCHIVE.md（用于确定已用最大编号）；2) 可选地探索代码库；3) 起草垂直切片，可为 HITL（需人工交互，如架构决策、设计评审）或 AFK（可无人交互实现合并），优先 AFK；唯一例外是脚手架切片（项目无可用测试运行器时，第一个切片搭建骨架、依赖、含一个通过测试的测试运行器及启动方式，其余切片均被其阻塞）；4) 向用户逐项确认标题、类型、依赖、覆盖的用户故事，并询问粒度、依赖、合并拆分、HITL/AFK 标注，迭代至批准；5) 写入仓库。
写入规则：编号取 BACKLOG.md、ARCHIVE.md 及 issues/ 文件名中最高编号后的下一个三位 id，绝不复用，新跟踪器从 001 起；文件名 NNN-kebab-case-title.md；按依赖顺序编写（先写阻塞项）。issue 文件含 frontmatter（id、title、type）及 What to build、Acceptance criteria、Blocked by 三节。验收标准可标注 proof: runtime（需驱动运行中应用并观察结果，用于路由、认证、UI、集成等用户可见行为）或 proof: migration（需在真实迁移数据上验证，用于模式与数据形态变更），未标注表示通过测试即可，应克制使用。BACKLOG.md 的 Order 表新增行：| NNN | Title | AFK | — | todo |，新 issue 状态为 todo；必要时在表下加一行依赖链说明。队列整洁：BACKLOG.md 只保留 todo 与进行中，验收行移至 ARCHIVE.md，不要用折叠隐藏已完成行。若 BACKLOG.md 仍有已完成行，除非用户要求迁移，否则不要擅自改动；除用户明确要求重写，不要修改已完成 issue 文件。
限制：物理 HITL issue 的证明不得要求本地模拟器；脚手切片是唯一允许违反垂直切片规则的例外；对已有可用测试框架的项目不要创建脚手架切片；不在此技能中编写词汇表或规格。