to-issues

name	to-issues
description	Break any plan, spec, or PRD into independently-grabbable issues using vertical slices. Use after creating a PRD with /to-prd, after an architecture review with /architect, or any time a plan needs to be broken into actionable pieces.
argument-hint	[plan or PRD reference]

Break Plan into Issues

"A large task is just a collection of small tasks, waiting to be discovered."

Philosophy

Each issue should be something a developer (human or AI) can pick up, complete, and verify without needing to understand the entire project. Vertical slices, not horizontal layers.

Workflow

Step 1: Identify Vertical Slices

Slice by observable behavior, not by layer:

Bad (Horizontal)	Good (Vertical)
"Set up database tables"	"User can create an account"
"Add API endpoints"	"User can view order history"
"Write tests"	"User receives email on signup"

Step 2: Order by Dependency

Issue 1 (no deps) ──→ Issue 3 (depends on 1, 2)
Issue 2 (no deps) ──→ Issue 3
Issue 3 ──→ Issue 4 (depends on 3)

Step 3: Write Each Issue

## [Issue Title]

### Context
[Why this issue exists. Link to parent PRD.]

### Acceptance Criteria
- [ ] [Specific, testable criterion]
- [ ] [Specific, testable criterion]

### Technical Notes
[Which modules to touch, key decisions, things to watch out for.]

### Dependencies
- Blocked by: [Issue #X]
- Blocks: [Issue #Y]

### Suggested Approach
1. [Step 1]
2. [Step 2]
3. [Step 3]

Apply Goal-Driven principle: acceptance criteria must be objectively verifiable. "Make it work" is not acceptable.

Apply Simplicity First: each issue = smallest unit of independently valuable work. Too big? Split. Too small? Merge.

Step 4: Create Issues

Submit to project's issue tracker. Label: feature/bug/refactor, link to parent PRD, add priority labels.

Anti-Patterns

• Horizontal slicing — Issues for layers, not behaviors
• Vague acceptance criteria — Must be testable
• Giant issues — If it takes more than a day, split it
• Missing dependencies — If B requires A, say so explicitly

Integration

• Use /to-prd before /to-issues to create the plan
• Use /tdd when picking up an issue to implement
• Use /grill if an issue's requirements are unclear