requirement-quality

Name: requirement-quality
Author: techygarg

165stars12forks

How to install requirement-quality?

techygarg/lattice/requirement-quality

$npx -y skills add techygarg/lattice --skill requirement-quality

Installs into the current project.

Summary

Apply requirement quality principles when generating or validating feature specifications. Enforces feature completeness, scenario structure, AC verifiability, feature independence, and implementation slice quality. Use when writing feature specs, validating existing requirements

Files · 1

View on GitHub

SKILL.md

1	# Requirement Quality
2
3	## Config Resolution
4
5	Skill supports project-specific standards. Order:
6
7	1. Look for `.lattice/config.yaml` in repo root
8	2. If found, check `paths.requirement_standards` for custom doc path
9	3. If custom path exists, read doc and check YAML frontmatter for `mode`:
10	- `mode: override` (or no mode): Custom doc full precedence. Use instead of embedded defaults. Must be comprehensive — sole reference.
11	- `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.
12	4. If no config/path/file, read `./references/defaults.md`
13
14	Custom standards produced by `requirement-forge-refiner` → consumed by this atom → composed by `requirement-forge` molecule.
15
16	## Self-Validation Checklist
17
18	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.
19
20	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.
21
22	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.
23
24	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")?
25	2. SCOPE: Has explicit out-of-scope items — not just in-scope?
26	3. BOUNDARY CONDITIONS: Feature-wide edge cases, system limits, and constraints documented?
27	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?
28	5. SCENARIO NAMES: Each scenario has a verb-phrase name (sentence case) that describes the situation — not a feature name, not an AC?
29	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?
30	7. FAILURE COVERAGE: At least one scenario covers a failure, error, or edge case?
31	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.
32	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.
33	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.
34	11. IMPLEMENTATION NOTES: Slices ordered chronologically, at the "what" level — no technical implementation specifics?
35	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.
36
37	Project-specific checks: if loaded doc contains a validation checklist section, apply those after base checklist.
38
39	When all checks pass: output "Spec passes requirement-quality — ready for write." (pre-write mode) or "Spec passes requirement-quality — status: approved." (validation mode).
40
41	## Active Anti-Pattern Scan
42
43	STOP: After checklist, scan for these. If found → fix or challenge before writing.
44
45	- [ ] 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
46	- [ ] Vague problem: "improve the experience", "make it faster", "better UX" → no verifiable outcome; push for specific, observable user impact
47	- [ ] Persona-less problem: Problem statement says "users" without identifying which user type or role → push for specificity; different personas produce different ACs
48	- [ ] 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
49	- [ ] **Boundaryles

People who liked this also viewed

6 picks

Type

requirement-quality

165stars12forks

View on GitHub

How to install requirement-quality?

techygarg/lattice/requirement-quality

$npx -y skills add techygarg/lattice --skill requirement-quality

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Requirement Quality
2
3	## Config Resolution
4
5	Skill supports project-specific standards. Order:
6
7	1. Look for `.lattice/config.yaml` in repo root
8	2. If found, check `paths.requirement_standards` for custom doc path
9	3. If custom path exists, read doc and check YAML frontmatter for `mode`:
10	- `mode: override` (or no mode): Custom doc full precedence. Use instead of embedded defaults. Must be comprehensive — sole reference.
11	- `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.
12	4. If no config/path/file, read `./references/defaults.md`
13
14	Custom standards produced by `requirement-forge-refiner` → consumed by this atom → composed by `requirement-forge` molecule.
15
16	## Self-Validation Checklist
17
18	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.
19
20	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.
21
22	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.
23
24	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")?
25	2. SCOPE: Has explicit out-of-scope items — not just in-scope?
26	3. BOUNDARY CONDITIONS: Feature-wide edge cases, system limits, and constraints documented?
27	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?
28	5. SCENARIO NAMES: Each scenario has a verb-phrase name (sentence case) that describes the situation — not a feature name, not an AC?
29	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?
30	7. FAILURE COVERAGE: At least one scenario covers a failure, error, or edge case?
31	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.
32	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.
33	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.
34	11. IMPLEMENTATION NOTES: Slices ordered chronologically, at the "what" level — no technical implementation specifics?
35	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.
36
37	Project-specific checks: if loaded doc contains a validation checklist section, apply those after base checklist.
38
39	When all checks pass: output "Spec passes requirement-quality — ready for write." (pre-write mode) or "Spec passes requirement-quality — status: approved." (validation mode).
40
41	## Active Anti-Pattern Scan
42
43	STOP: After checklist, scan for these. If found → fix or challenge before writing.
44
45	- [ ] 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
46	- [ ] Vague problem: "improve the experience", "make it faster", "better UX" → no verifiable outcome; push for specific, observable user impact
47	- [ ] Persona-less problem: Problem statement says "users" without identifying which user type or role → push for specificity; different personas produce different ACs
48	- [ ] 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
49	- [ ] **Boundaryles

People who liked this also viewed

6 picks

Type