القائمة
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.