菜单
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