sethdford 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
- Start with the job: What is the customer trying to accomplish?
- Define success: How will you know this requirement is met?
- Document constraints: What's off-limits? Technical, business, timeline?
- Define edge cases: What happens at boundaries?
- 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