feat: add guidance for subjective acceptance criteria
Planner now has examples for design/UX criteria that are evaluable without being purely binary. Prevents the planner from avoiding qualitative criteria just because they aren't grep-checkable.
This commit is contained in:
@@ -24,12 +24,16 @@ Good criteria are specific and checkable:
|
||||
- "Running `npm test` passes with no failures"
|
||||
- "The config file contains entries for all three required env vars"
|
||||
|
||||
Bad criteria are vague or subjective:
|
||||
Bad criteria are vague with no way to check:
|
||||
- "The code is clean"
|
||||
- "Works correctly"
|
||||
- "Performance is improved"
|
||||
- "Error handling is robust"
|
||||
|
||||
For subjective work (design, UX, documentation), criteria should define what to evaluate and how to judge it — not just say "looks good":
|
||||
- "Design uses a consistent color palette and typography — no default library styles"
|
||||
- "A user can complete the primary action without guessing what to click"
|
||||
|
||||
## PRD Anti-Patterns
|
||||
|
||||
Avoid these common mistakes:
|
||||
|
||||
Reference in New Issue
Block a user