Rendered from the source repository. Headings, examples, code, tables, links, and referenced images are preserved.
Requirements quality checklist
--strict validation proves a spec is well-FORMED; it doesn't prove it's well-SPECIFIED. This skill generates a tailored checklist and grades the change against it, so gaps in clarity or coverage surface before code — not in review.
When to use
- At the
sdd-feature-flowhuman approval gate, to decide whether to approve the spec. - Before
/opsx:applyor launching implementation on any non-trivial change.
Procedure
- Read the change:
openspec/changes/<id>/proposal.md,design.md,tasks.md, and the
delta spec(s); plus openspec/project.md (the constitution) if present.
- Generate the checklist, tailored to what this change touches. Cover at least:
- Completeness — is every stated requirement addressed by the design AND the tasks?
Are error/empty/edge cases specified, not just the happy path? Are non-goals explicit?
- Clarity — is each requirement testable and unambiguous (SHALL/MUST, concrete values)?
Any "should probably / TBD / etc." that hides a real decision?
- Consistency — do proposal, design, tasks and delta agree? Any contradiction in scope,
data model, or naming? Does anything violate the constitution?
- Testability — does each requirement have a scenario or a task that would fail if the
requirement were unmet? Is the verification path concrete?
- Assumptions — is every load-bearing assumption either confirmed or flagged as an open
question (NOT silently baked in)?
- Grade each item pass / fail / n-a with a one-line reason, and list the fails first.
- Recommend: approve as-is, approve with the listed fixes, or send back for revision.
Output
A compact table (item · verdict · reason), fails first, then a one-line recommendation. Read-only — this skill changes no files; it produces the checklist and the verdict.
