sheldon/loop-loop
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: add guidance for subjective acceptance criteria

Browse Source 
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:
Sheldon Finlay
2026-03-28 12:59:42 -04:00
parent 77fd9e0cd6
commit ce111b4cbe
1 changed files with 5 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
prompts/planner/plan.md
View File

@@ -24,12 +24,16 @@ Good criteria are specific and checkable:
- "Running `npm test` passes with no failures" - "Running `npm test` passes with no failures"
- "The config file contains entries for all three required env vars" - "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" - "The code is clean"
- "Works correctly" - "Works correctly"
- "Performance is improved" - "Performance is improved"
- "Error handling is robust" - "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 ## PRD Anti-Patterns
Avoid these common mistakes: Avoid these common mistakes: