← Back to Godot · project planning pack
See how it helps
Specification and acceptance clarity
Turns a game-feature brief into clear player behavior and checkable acceptance criteria. Resolves conflicting rules, interruption cases and missing decisions before implementation hides those uncertainties.
specification-acceptance-review
Agents using this skill
When is it useful?
Use when a specification contains vague goals or conflicting business rules.
What does it help you do?
- Identifies the intended actor, outcome and impact on existing users.
- Checks eligibility, competing rules, interruption and concurrent changes.
- Converts ambiguity into concrete decision options and observable criteria.
Try asking this
Review the brief for a revive mechanic in cooperative play. Clarify who can revive, its cost and what happens if either player disconnects or two teammates act together. Produce observable acceptance cases for success, cancellation and insufficient resources, and identify choices that still need the designer's decision.
Detailed documentation
Read the skill’s original instructions, examples and checks in their authored language.
Show less
Specification & Acceptance Review
Use this skill when authoring or reviewing product specifications, task briefs, and implementation plans so requirements are complete, internally consistent, and verifiable before or during coding.
Workflow
- Verify problem clarity, scope boundaries, and user outcome (Marty Cagan & Gerald Weinberg):
- Confirm the specification clearly states:
- Target outcome: Which user or system actor needs this, and what concrete problem it solves.
- In-scope vs. non-goals: Explicit boundaries so implementation neither omits required flows nor drifts into unrequested work.
- Stakeholder impact: Who is affected when behavior changes, and what happens to existing users, data, or integrations.
- Confirm the specification clearly states:
- Audit business rules for completeness and internal consistency:
- Check every rule against edge conditions and competing rules:
- Preconditions & eligibility: What state must hold before an action is allowed?
- Conflict resolution: If Rule A and Rule B both apply (e.g., a discount cap vs. a minimum fee, or an admin override vs. a locked state), which rule wins?
- Failure, cancellation & retry: What happens when a multi-step flow is interrupted, rejected, or submitted twice?
- Empty, boundary & scale cases: Zero items, single item, maximum quota reached, expired records, or concurrent edits.
- Check every rule against edge conditions and competing rules:
- Ensure every acceptance criterion is falsifiable and testable:
- Replace vague adjectives ("intuitive", "fast", "secure", "handles errors gracefully") with observable, deterministic conditions ("returns 409 Conflict when version mismatches and preserves unsaved form input").
- Distinguish product decisions from implementation details:
- When requirements conflict or leave a business-critical behavior undefined, formulate a concise decision question with the concrete options and their consequences rather than guessing silently.
- Respect settled product and architectural trade-offs unless new evidence invalidates them.
Included files 1
SKILL.md