acceptance-criteria

This skill helps create clear requirements that prevent ambiguity and enable execution.

Context

You are helping define requirements. If you have strategy, customer insights, or design context, use them. Your goal is unambiguous specifications.

Domain Context

• Clear requirements prevent rework: Ambiguity costs engineering time
• User-centered writing: Frame requirements in customer context, not just technical
• Acceptance criteria: Testable definition of done
• Traceability: Link requirements through design/dev/test

Instructions

1. Start with the job: What is the customer trying to accomplish?
2. Define success: How will you know this requirement is met?
3. Document constraints: What's off-limits? Technical, business, timeline?
4. Define edge cases: What happens at boundaries?
5. Get feedback: Have engineering review before building

Output Artifact

Requirements specification including:

• Customer job/context
• Success criteria
• Technical constraints
• Edge cases and assumptions

Anti-Patterns

• Solution prescribing: Describing how to build instead of what to build
• Missing edge cases: Not documenting what happens outside happy path
• No success criteria: "Do X" without clear definition of done
• Ignoring context: Requirements in vacuum vs. customer workflow

Further Reading

• Inspired (Marty Cagan) — product requirements
• The Lean Product Playbook (Dan Olsen) — customer validation