菜单
Defines acceptance criteria from requirements through persona analysis and refinement. Use when clarifying requirements, defining what done looks like, or writing acceptance criteria.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Drives implementation outside-in: starts from an acceptance test for user-visible behavior, then works inward layer by layer, stubbing what doesn't exist yet. Use when building a feature across collaborating components to let design emerge from usage rather than speculation.
Autonomous end-to-end feature development with phased validation gates. Use when building major new functionality or adding substantial features.
End-to-end GitHub issue lifecycle: pick up an issue, create a worktree, build the fix or feature, open a PR, watch CI, and iterate until green. Use when picking up, fixing, or implementing a GitHub issue or ticket.
Decomposes work into ordered, shippable slices. Use when breaking down features, planning implementation order, or slicing work into deliverable increments.
Test-driven development (TDD) process used when writing code. Use whenever you are adding any new code, unless the user explicitly asks to skip TDD or the code is exploratory/spike.
Refactoring process. Invoke immediately when user or document mentions refactoring, or proactively when code gets too complex or messy.
| name | acceptance-criteria |
| description | Defines acceptance criteria from requirements through persona analysis and refinement. Use when clarifying requirements, defining what done looks like, or writing acceptance criteria. |
STARTER_CHARACTER = 🎯
Define what success looks like before thinking about code. Stay in the problem space — if you're naming functions, data structures, or config keys, you've left it.
Restate the requirement in your own words
Identify personas — who will actually interact with this feature, directly or indirectly? Don't settle for the obvious ones. Think about:
Present the personas to the user before continuing. You are likely wrong or incomplete — get confirmation.
Walk through each persona's real workflow — not the idealized flow, the actual one:
This is where weak personas get exposed. If you can't describe a concrete, realistic workflow, the persona is too vague.
From those workflows, identify:
If unknowns exist, ask the user — don't guess on important decisions
Write criteria to playground/{feature-name}-criteria.md:
# [Feature Name] Acceptance Criteria
## Personas
- [Persona]: [one-line description of their relationship to this feature]
## Must Have
- [ ] Criterion 1 (specific, testable)
- [ ] Criterion 2
## Out of Scope
- Item explicitly excluded
Use a short, hyphenated feature name (e.g., user-auth, invoice-export) consistently across all playground files.
Invoke /refinement-loop on the criteria file with these checks:
Do not consider this done until every criterion passes every check.