To Issues
Turn an approved plan, spec, or PRD into thin vertical-slice tickets your agent or team can pick up one at a time in the issue tracker.
Overview
To Issues is an agent skill most often used in Build (also Validate scope) that splits plans, specs, or PRDs into independently assignable vertical-slice issues on your project tracker.
Install
npx skills add https://github.com/vinvcn/mattpocock-skills-zh-cn --skill to-issuesWhat is this skill?
- Four-step workflow: gather context, optional codebase exploration, draft tracer-bullet slices, quiz user before filing
- Each slice is a thin end-to-end vertical path (schema, API, UI, tests)—not horizontal layer-only tickets
- Labels every slice HITL (human gates) or AFK (autonomous implement-and-merge)
- Maps Blocked-by dependencies and user stories covered per slice
- Uses project issue-tracker and triage label vocabulary from matt-pocock skills setup when provided
- 4-step process: gather context, explore codebase, draft slices, quiz user
- 3 vertical-slice rules: end-to-end layers, demoable completeness, prefer thin slices
- 2 slice types: HITL and AFK
Adoption & trust: 504 installs on skills.sh; 485 GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
You have an approved plan or PRD but only a vague todo list—or horizontal tickets that cannot be demoed end-to-end—so nobody knows what to implement next.
Who is it for?
Solo builders moving from writing-plans or a merged spec into a tracker backlog with vertical slices sized for agent or human pickup.
Skip if: Greenfield ideation with no plan yet, one-off bug fixes that do not need slicing, or teams that forbid agent-created tracker tickets without manual review.
When should I use this skill?
User wants to convert a plan into issues, create implementation tickets, or break down work into issues.
What do I get? / Deliverables
You get a reviewed set of tracer-bullet issues with HITL/AFK labels, dependencies, and story mapping, ready for humans or agents to implement slice by slice.
- Numbered vertical-slice breakdown with titles, HITL/AFK, blocked-by, and user-story coverage
- Created or updated issues on the project issue tracker after user approval
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Issue breakdown is the handoff from scoped intent to executable backlog—canonical on the Build shelf under PM because it produces tracker-ready implementation work. Subphase pm fits skills that structure delivery work (tickets, slices, dependencies) rather than writing code directly.
Where it fits
After a PRD draft, slice scope into demoable vertical issues before committing to a full build estimate.
Convert an approved implementation plan into numbered AFK slices your coding agent can merge without human gates.
Ensure each database-and-API slice includes schema, endpoints, and tests in one ticket instead of separate layer epics.
Break launch checklist items into blocked-by ordered slices so release tasks ship in dependency-safe order.
How it compares
Use instead of copying bullet lists into one epic—this enforces vertical completeness and explicit HITL/AFK and dependency edges per slice.
Common Questions / FAQ
Who is to-issues for?
Solo and indie builders using Claude Code, Cursor, Codex, or similar agents who already have a plan or PRD and want structured, independently assignable issues—not another document.
When should I use to-issues?
In Validate when you are scoping a PRD into deliverable chunks, and in Build PM when you convert an approved plan into tracker tickets; also right before an execution sprint when work must be thin vertical slices with clear blockers.
Is to-issues safe to install?
It may read repo context and create or update issues on your tracker—review the Security Audits panel on this Prism page and restrict tracker tokens and project permissions before letting an agent file tickets.
SKILL.md
READMESKILL.md - To Issues
# To Issues 使用 vertical slices（tracer bullets）把计划拆成可独立领取的 issue tracker issues。 Issue tracker 和 triage label vocabulary 应该已经提供给你；如果没有，运行 `/setup-matt-pocock-skills`。 ## Process ### 1. Gather context 基于 conversation context 中已有内容工作。如果用户传入 issue reference（issue number、URL 或 path）作为参数，从 issue tracker 获取它，并读取完整 body 和 comments。 ### 2. Explore the codebase (optional) 如果还没探索 codebase，就先探索，以理解代码当前状态。Issue titles 和 descriptions 应使用项目 domain glossary vocabulary，并遵守相关 ADRs。 ### 3. Draft vertical slices 把计划拆成 **tracer bullet** issues。每个 issue 都是一个薄 vertical slice，end-to-end 穿过所有 integration layers，而不是某一层的 horizontal slice。 Slices 可以是 `HITL` 或 `AFK`。HITL slices 需要人类交互，例如 architecture decision 或 design review。AFK slices 可以无人交互地实现并合并。尽可能优先 AFK。 <vertical-slice-rules> - 每个 slice 都交付一条窄但 COMPLETE 的路径，穿过每一层（schema, API, UI, tests） - 完成后的 slice 自身可 demo 或验证 - 偏好多而薄的 slices，而不是少而厚的 slices </vertical-slice-rules> ### 4. Quiz the user 把 proposed breakdown 作为编号列表展示。每个 slice 显示： - **Title**：短描述名 - **Type**：HITL / AFK - **Blocked by**：哪些其他 slices 必须先完成（如果有） - **User stories covered**：覆盖哪些 user stories（如果 source material 中有） 询问用户： - Granularity 是否合适？（too coarse / too fine） - Dependency relationships 是否正确？ - 是否需要 merge 或继续 split 某些 slices？ - HITL 和 AFK 标记是否正确？ 迭代直到用户批准 breakdown。 ### 5. Publish the issues to the issue tracker 对每个批准的 slice，把新 issue 发布到 issue tracker。使用下面的 issue body template。这些 issues 被视为已准备好给 AFK agents 接手；除非另有指示，发布时应用正确的 triage label。 按 dependency order 发布 issues（blockers first），这样可以在 "Blocked by" 字段引用真实 issue identifiers。 <issue-template> ## Parent 对 issue tracker 中 parent issue 的引用（如果 source 是现有 issue；否则省略本 section）。 ## What to build 这个 vertical slice 的简洁描述。描述 end-to-end behavior，不要按 layer-by-layer implementation 描述。 避免具体 file paths 或 code snippets；它们很快会过时。例外：如果 prototype 产出的 snippet 比 prose 更精确地编码了某个决策（state machine、reducer、schema、type shape），可以内联在这里，并简短说明它来自 prototype。保留决策密集部分，不要放完整 working demo。 ## Acceptance criteria - [ ] Criterion 1 - [ ] Criterion 2 - [ ] Criterion 3 ## Blocked by - 对 blocking issue 的引用（如果有） 如果没有 blocker，写 "None - can start immediately"。 </issue-template> 不要 close 或 modify 任何 parent issue。