메뉴
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.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Find deepening opportunities in a codebase — refactors that turn shallow modules into deep ones. Use when the codebase feels hard to change, bugs cluster in certain modules, adding features requires touching many files, or proactively every few days as a health check.
Collaborative design exploration before implementation. Use when starting a new feature or project, when the approach is unclear, or when multiple design directions exist. Unlike /grill (which aligns on a given plan), /brainstorm explores and creates the plan. Enforces a HARD-GATE: no code until design is approved.
Systematic debugging loop for hard bugs and performance regressions. Use when something is broken and you don't know why, when behavior is inconsistent, or when error messages are unclear. Follows reproduce → minimise → hypothesise → instrument → fix → regression-test.
Deep alignment session before coding. Use when starting a non-trivial feature, when requirements are ambiguous, before refactoring, or when the user's request could be interpreted multiple ways. Surfaces assumptions, presents tradeoffs, and produces a verified implementation plan.
Request and handle code reviews with technical rigor. Use after completing a feature or task, before merging. Covers both requesting reviews and responding to feedback — verify before implementing, push back when wrong, no performative agreement.
Test-driven development with red-green-refactor loop. Use when building features, fixing bugs, refactoring code, or when the user mentions TDD, test-first, or red-green-refactor. Builds one vertical slice at a time.
| 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] |
"A large task is just a collection of small tasks, waiting to be discovered."
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.
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" |
Issue 1 (no deps) ──→ Issue 3 (depends on 1, 2)
Issue 2 (no deps) ──→ Issue 3
Issue 3 ──→ Issue 4 (depends on 3)
## [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.
Submit to project's issue tracker. Label: feature/bug/refactor, link to parent PRD, add priority labels.
/to-prd before /to-issues to create the plan/tdd when picking up an issue to implement/grill if an issue's requirements are unclear