Requirement Quality

Active Anti-Pattern Scan

STOP: After checklist, scan for these. If found → fix or challenge before writing.

• Solution as problem: Problem statement says "we need X" instead of "users cannot do Y" → ask what user need X addresses; rewrite around the need
• Vague problem: "improve the experience", "make it faster", "better UX" → no verifiable outcome; push for specific, observable user impact
• Persona-less problem: Problem statement says "users" without identifying which user type or role → push for specificity; different personas produce different ACs
• Hidden assumption: AC or scenario relies on an unstated assumption ("assumes user is logged in" but no Assumptions section records this) → make the assumption explicit or add a scenario covering the case where it doesn't hold
• Boundaryless scope: scope section lists only what is in scope, nothing explicitly out → force at least 3 explicit exclusions; undefined scope = infinite scope
• Happy-path-only spec: every scenario is a success path, no failure or error scenario → add at least one failure scenario before feature is complete
• AC sprawl: single scenario accumulates 7+ ACs → scenario too broad; propose split into two named scenarios
• Scenario sprawl: feature has 6+ scenarios → feature may be two; pause and challenge scope before adding more
• Vague AC: "the system should handle errors gracefully", "response should be fast", "it should work correctly" → no pass/fail condition; rewrite as concrete Given/When/Then
• Implementation AC: AC specifies a technical approach ("system shall use Redis", "shall call the /api/v2 endpoint") → rewrite as observable outcome
• Orphaned feature: depends_on is empty but feature references another feature's data or behavior in its scenarios → flag missing dependency
• Cross-epic feature undocumented: feature scenarios reference behaviors from a different epic but no cross-epic dependency is recorded → place feature in its primary epic, add the other epic as a cross-reference, record the dependency in depends_on frontmatter
• Technical task as feature: feature name or problem statement describes infrastructure, tooling, or engineering work ("Set up database schema", "Configure CI/CD", "Write unit tests") → redirect to implementation layer, challenge what user need it serves
• Wrong granularity — too fine: feature is actually a single acceptance criterion or a micro-behavior ("Show error on wrong password") → merge into a larger feature representing the complete user-facing behavior
• Wrong granularity — too coarse: feature encompasses an entire product area with 10+ implicit behaviors ("User management") → decompose into discrete independently-implementable features
• Generic slices: Implementation notes use placeholder labels that apply to any feature ("Core functionality", "Error handling", "Edge cases") → each slice must name the specific behavior being built for THIS feature
• Undefined domain terms: Scenarios use specialized/domain terms not defined anywhere in the spec → add inline definitions or a Glossary section

Ambiguity Signals

Flag these — present options and reasoning. If framework:collaborative-judgment is loaded, use it to structure the presentation.

• Feature boundary: two related behaviors — one feature or two? If Behavior A requires knowing Behavior B's design to spec its own ACs, they are one feature.
• Scenario granularity: one scenario with more ACs, or two separate scenarios? If both situations share the same precondition and trigger, group. If they differ in either → separate scenarios.
• Priority: feature serves multiple user types or epics with different urgency → surface for product decision; do not silently assign.
• Independence borderline: feature depends on another feature but the dependency is well-understood and stable → judgment call whether to mark dependent or proceed as independent.
• Assumption vs. requirement: a statement reads as both an assumption and a requirement → surface for product decision.

See ./references/defaults.md for epic/feature/scenario definitions, AC format examples, priority notation, status workflow, naming conventions, and implementation slice guidance.