Requirement Quality Agent Skill

Requirement Quality

Config Resolution

Skill supports project-specific standards. Order:

• Look for .lattice/config.yaml in repo root
• If found, check paths.requirement_standards for custom doc path
• If custom path exists, read doc and check YAML frontmatter for mode:
• mode: override (or no mode): Custom doc full precedence. Use instead of embedded defaults. Must be comprehensive — sole reference.
• mode: overlay: Read embedded ./references/defaults.md first, then apply custom doc sections on top. Custom sections replace matching sections in defaults (matched by heading). New sections appended after.
• If no config/path/file, read ./references/defaults.md

Custom standards produced by requirement-forge-refiner → consumed by this atom → composed by requirement-forge molecule.

Self-Validation Checklist

STOP: Before writing any feature file, verify ALL checks. If a check clearly fails → fix before writing. If judgment call (see Ambiguity Signals) → flag and surface options.

If validating an existing spec (not generating), same checks apply — "fix before writing" means "fix before marking approved." Present findings as a quality report with severity.

Draft vs approved enforcement: For status: draft — items 1, 2, 10 are required. Items 3–9, 11, 12 are advisories: flag findings but do not block write. For status: approved — all items required, no exceptions.

• PROBLEM STATEMENT: Names a specific user need or pain — not a solution in disguise, not a vague improvement? Identifies WHO has the problem (specific user type or role, not "users")?
• SCOPE: Has explicit out-of-scope items — not just in-scope?
• BOUNDARY CONDITIONS: Feature-wide edge cases, system limits, and constraints documented?
• ASSUMPTIONS: Statements the team proceeds with as true are explicit — not buried in ACs or unstated? If an assumption proves wrong, affected scenarios are identifiable?
• SCENARIO NAMES: Each scenario has a verb-phrase name (sentence case) that describes the situation — not a feature name, not an AC?
• AC FORMAT: Each AC follows the agreed format (default: Given/When/Then)? Each has a clear pass/fail condition — a tester can write an automated check without asking a clarifying question?
• FAILURE COVERAGE: At least one scenario covers a failure, error, or edge case?
• SCENARIO COUNT: Feature has no more than the agreed max (default: 5) scenarios? If at or over → challenge whether this is one feature or two.
• AC COUNT: Each scenario has no more than the agreed max (default: 6) ACs? If at or over → challenge whether this scenario is too broad.

10. INDEPENDENCE: Feature is self-contained — no unresolved external unknowns required before design-blueprint can begin? Any unresolved Open Questions affecting scope, behavior, or ACs are blockers unless each is marked non-blocking with a stated reason.

11. IMPLEMENTATION NOTES: Slices ordered chronologically, at the "what" level — no technical implementation specifics?

12. COHERENCE: All scenarios address the same user need in the Problem Statement? If a scenario serves a different need, it belongs in a separate feature.

Project-specific checks: if loaded doc contains a validation checklist section, apply those after base checklist.

When all checks pass: output "Spec passes requirement-quality — ready for write." (pre-write mode) or "Spec passes requirement-quality — status: approved." (validation mode).

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.