
To Issues
- 376 installs
- 1 repo stars
- Updated May 26, 2026
- camacho/ai-skills
to-issues is an agent skill that breaks plans, specs, or PRDs into independently grabbable GitHub issues using tracer-bullet vertical slices for developers who need parallel-ready implementation tickets.
About
to-issues is a planning skill in camacho/ai-skills that converts plans, specs, or PRDs into GitHub issues teammates or AFK agents can grab without hidden dependencies. Each issue is a tracer-bullet vertical slice cutting through schema, API, UI, and tests end-to-end—not a horizontal layer ticket. Slices are tagged HITL when human decisions are required or AFK when agents can implement and merge autonomously. The workflow gathers context (including fetched issue bodies via gh), optionally explores the codebase for domain vocabulary, drafts slices with blocker relationships, quizzes the user on granularity and dependencies, then publishes issues in dependency order with acceptance criteria and Blocked-by links. Issue bodies avoid stale file paths unless encoding prototype decisions. Developers reach for to-issues when converting a PRD, feature plan, or parent issue into a parallelizable issue backlog ready for agent execution.
- Tracer-bullet vertical slices
- Independent grab-and-ship tickets
- Maps plan sections to tracker items
- Reduces cross-issue blocking
- Supports agent parallelization
To Issues by the numbers
- 376 all-time installs (skills.sh)
- Ranked #822 of 3,282 Productivity & Planning skills by installs in the Skillselion catalog
- Data as of Jul 28, 2026 (Skillselion catalog sync)
npx skills add https://github.com/camacho/ai-skills --skill to-issuesAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 376 |
|---|---|
| repo stars | ★ 1 |
| Last updated | May 26, 2026 |
| Repository | camacho/ai-skills ↗ |
How do you split a PRD into GitHub issues?
Slice a plan or PRD into tracer-bullet issues teammates or agents can grab independently without hidden dependencies.
Who is it for?
Tech leads and agent orchestrators converting specs or plans into parallel-ready GitHub issues for mixed human and AFK agent execution.
Skip if: Teams without gh CLI access, horizontal layer-based ticketing, or one-off bug fixes that do not need plan decomposition.
When should I use this skill?
User wants to convert a plan into issues, create implementation tickets from a PRD, or break work into vertical slices
What you get
Numbered vertical-slice GitHub issues with acceptance criteria, HITL/AFK tags, and dependency-ordered Blocked-by links
- GitHub issues backlog
- dependency-ordered ticket set
Files
To Issues
Break a plan into independently-grabbable issues using vertical slices (tracer bullets).
The issue tracker should be accessible via gh. If label vocabulary is needed, check the project's AGENTS.md or issue templates.
Process
1. Gather context
Work from whatever is already in the conversation context. If the user passes an issue reference (issue number, URL, or path) as an argument, fetch it from the issue tracker and read its full body and comments.
2. Explore the codebase (optional)
If you have not already explored the codebase, do so to understand the current state of the code. Issue titles and descriptions should use the project's domain glossary vocabulary, and respect ADRs in the area you're touching.
3. Draft vertical slices
Break the plan into tracer bullet issues. Each issue is a thin vertical slice that cuts through ALL integration layers end-to-end, NOT a horizontal slice of one layer.
Slices may be 'HITL' or 'AFK'. HITL slices require human interaction, such as an architectural decision or a design review. AFK slices can be implemented and merged without human interaction. Prefer AFK over HITL where possible.
<vertical-slice-rules>
- Each slice delivers a narrow but COMPLETE path through every layer (schema, API, UI, tests)
- A completed slice is demoable or verifiable on its own
- Prefer many thin slices over few thick ones
</vertical-slice-rules>
4. Quiz the user
Present the proposed breakdown as a numbered list. For each slice, show:
- Title: short descriptive name
- Type: HITL / AFK
- Blocked by: which other slices (if any) must complete first
- User stories covered: which user stories this addresses (if the source material has them)
Ask the user:
- Does the granularity feel right? (too coarse / too fine)
- Are the dependency relationships correct?
- Should any slices be merged or split further?
- Are the correct slices marked as HITL and AFK?
Iterate until the user approves the breakdown.
5. Publish the issues to the issue tracker
For each approved slice, publish a new issue to the issue tracker. Use the issue body template below. Apply the needs-triage triage label so each issue enters the normal triage flow.
Publish issues in dependency order (blockers first) so you can reference real issue identifiers in the "Blocked by" field.
<issue-template>
Parent
A reference to the parent issue on the issue tracker (if the source was an existing issue, otherwise omit this section).
What to build
A concise description of this vertical slice. Describe the end-to-end behavior, not layer-by-layer implementation.
Acceptance criteria
- [ ] Criterion 1
- [ ] Criterion 2
- [ ] Criterion 3
Blocked by
- A reference to the blocking ticket (if any)
Or "None - can start immediately" if no blockers.
</issue-template>
Do NOT close or modify any parent issue.
Related skills
FAQ
What is a tracer bullet issue in to-issues?
to-issues defines tracer-bullet issues as thin vertical slices delivering a complete end-to-end path through every layer—schema, API, UI, and tests—so each ticket is independently demoable or verifiable.
How does to-issues publish GitHub issues?
to-issues uses the gh CLI to publish approved slices in dependency order, attaching acceptance criteria, HITL or AFK type, Blocked-by references to real issue IDs, and triage labels for AFK-ready work.