requirement-quality

Requirement Quality

Config Resolution

Skill supports project-specific standards. Order:

1. Look for .lattice/config.yaml in the repo root
2. If found, check paths.requirement_standards for a custom document path
3. If a custom document exists at that path, read it and check its YAML frontmatter for mode:
   • mode: override: the custom document has full precedence. Use it instead of the embedded defaults. It must be comprehensive — treat it as the sole reference.
   • mode: overlay (or no mode field): read the embedded ./references/defaults.md first, then apply the custom document's sections on top. A custom section replaces the matching default section (matched by exact heading); new sections append after the defaults.
4. If a custom path is configured but no document exists at it → tell the user which configured path is missing, then fall back to ./references/defaults.md
5. If there is no config file or no paths.requirement_standards key → 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.

1. 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")?
2. SCOPE: Has explicit out-of-scope items — not just in-scope?
3. BOUNDARY CONDITIONS: Feature-wide edge cases, system limits, and constraints documented?
4. 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?
5. SCENARIO NAMES: Each scenario has a verb-phrase name (sentence case) that describes the situation — not a feature name, not an AC?
6. 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?
7. FAILURE COVERAGE: At least one scenario covers a failure, error, or edge case?
8. 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.
9. 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.