Checklists

requirements.md

Specification Quality Checklist: Coordination artifacts get one durable home

Purpose: Validate specification completeness and quality before proceeding to planning Created: 2026-10-01 Mission: spec.md

Content Quality

  • ✅ No implementation details (languages, frameworks, APIs)
  • ✅ Focused on user value and business needs
  • ✅ Written for non-technical stakeholders
  • ✅ All mandatory sections completed

Requirement Completeness

  • ✅ No [NEEDS CLARIFICATION] markers remain
  • ✅ Requirements are testable and unambiguous
  • ✅ Requirement types are separated (Functional / Non-Functional / Constraints)
  • ✅ IDs are unique across FR-###, NFR-###, C-### and SC-### entries, and match the requirement-ID grammar (optional lowercase letter suffix; <mission-slug>#<ID> only for another mission's ID)
  • ✅ All requirement rows include a non-empty Status value
  • ✅ Non-functional requirements include measurable thresholds
  • ✅ Every FR row and success criterion carries a delivery label and no-op mark
  • ✅ Success criteria are measurable
  • ✅ Success criteria are technology-agnostic (no implementation details)
  • ✅ All acceptance scenarios are defined
  • ✅ Edge cases are identified
  • ✅ Scope is clearly bounded
  • ✅ Dependencies and assumptions identified

Mission Readiness

  • ✅ All functional requirements have clear acceptance criteria
  • ✅ User scenarios cover primary flows
  • ✅ Mission meets measurable outcomes defined in Success Criteria
  • ✅ No implementation details leak into specification

Notes

  • Audience. This is a developer-tooling Mission, so its "users" are Spec Kitty operators and agents. The CLI command names (accept, spec-commit, doctor decisions), branch and surface names, and ADR identifiers are domain vocabulary for that audience, not implementation details. File paths, function names and line numbers are deliberately kept out of the spec; they live in the grounding evidence and belong in plan.
  • FR-016 is no-op passable by design. It is a documentation requirement, verified by review against merged behaviour.
  • The create-leg mechanism is a recorded plan-phase decision (Assumptions), not a spec ambiguity.
  • Validation: 1 iteration, all items pass.