The /speckit.checklist command generates custom quality checklists that validate requirements completeness, clarity, and consistency throughout the Spec-Driven Development workflow. It implements the philosophy of "unit tests for English" - providing structured, repeatable validation criteria for natural language specifications before they become implementation plans.
This page covers the purpose, usage, and integration of the checklist command within the quality assurance system. For the broader constitutional enforcement mechanism, see 5.11 Constitutional Governance System. For cross-artifact validation, see 5.6 /speckit.analyze Command. For specification clarification, see 5.4 /speckit.clarify Command.
Sources: README.md265-269
The /speckit.checklist command is an optional quality enhancement command that sits alongside /speckit.clarify and /speckit.analyze in the validation layer of the Spec-Driven Development workflow. Unlike clarification (which resolves ambiguities through Q&A) or analysis (which checks cross-artifact consistency), checklist generation creates custom validation criteria tailored to your specific requirements.
| Aspect | Description |
|---|---|
| Type | Optional quality command |
| Category | Enhanced quality and validation |
| Primary Purpose | Generate custom quality checklists |
| Validation Target | Requirements completeness, clarity, consistency |
| Philosophy | "Unit tests for English" |
| Output | Structured checklist documents |
Sources: README.md261-269
The checklist command embodies the principle that natural language specifications can be validated with the same rigor as code. Just as unit tests verify code behavior, checklists verify specification quality through structured, repeatable criteria.
Key Principles:
Sources: README.md269
The checklist command integrates into the Spec-Driven Development workflow at validation checkpoints, primarily after specification creation and before or during planning.
Primary Usage Points:
| Workflow Stage | Checklist Focus | Validation Target |
|---|---|---|
| Post-Specification | Requirements completeness | User stories, acceptance criteria, edge cases |
| Post-Planning | Implementation plan quality | Technical completeness, dependency mapping, risk coverage |
| Pre-Implementation | Readiness assessment | All prerequisites, artifact consistency, gap identification |
Sources: README.md245-269
The command generates different checklist types based on the workflow stage and validation needs. Each checklist type targets specific quality dimensions.
Sources: README.md269
Validates that all functional and non-functional requirements are documented with sufficient detail.
| Criterion | Validation Question | Pass Condition |
|---|---|---|
| User Story Coverage | Are all user personas and their needs represented? | All identified personas have user stories |
| Acceptance Criteria | Does each user story have measurable acceptance criteria? | Each story has ≥1 testable criterion |
| Edge Case Documentation | Are boundary conditions and error scenarios defined? | Edge cases enumerated for critical flows |
| Non-Functional Requirements | Are performance, security, accessibility requirements specified? | NFRs documented with quantifiable targets |
| Dependency Identification | Are external systems and integrations documented? | All dependencies listed with interfaces |
Ensures specifications are unambiguous and interpretable without context gaps.
| Criterion | Validation Question | Pass Condition |
|---|---|---|
| Ambiguous Terminology | Are all domain terms explicitly defined? | No undefined acronyms or jargon |
| Vague Quantifiers | Are all quantities, frequencies, and limits precise? | No "many", "few", "fast" without numbers |
| Implicit Assumptions | Are assumptions about user behavior or system state explicit? | Assumptions documented in dedicated section |
| Reference Completeness | Are all references to external systems/specs complete? | All external refs have location/version info |
| Constraint Explicitness | Are all constraints (technical, business, regulatory) stated? | Constraints listed with rationale |
Validates internal coherence and absence of contradictions.
| Criterion | Validation Question | Pass Condition |
|---|---|---|
| Terminology Consistency | Is the same term used consistently throughout? | Single term per concept, glossary exists |
| Constraint Compatibility | Do constraints conflict with each other? | No contradictory constraints identified |
| User Story Coherence | Do user stories align with stated project goals? | Each story traceable to ≥1 project goal |
| Acceptance Criteria Alignment | Do acceptance criteria match user story descriptions? | Each criterion validates a story aspect |
| Cross-Reference Validity | Do internal references point to existing content? | All [REFERENCE] markers valid |
Sources: README.md269
The checklist command integrates with the Constitutional Governance System to validate that specifications and plans comply with the nine immutable principles.
The constitutional validation checklist ensures that:
Sources: README.md265-276
The checklist command complements other quality assurance commands in the validation layer.
Complementary Roles:
| Command | Purpose | Output | When to Use |
|---|---|---|---|
/speckit.clarify | Resolve underspecified areas through Q&A | Clarifications section in spec.md | When requirements have knowledge gaps |
/speckit.checklist | Validate quality through structured criteria | Standalone checklist document | When validating completeness/clarity |
/speckit.analyze | Check consistency across multiple artifacts | Analysis report with findings | After plan creation, before implementation |
Sources: README.md261-269
Generate a checklist to validate specification quality immediately after creation:
Request checklists tailored to project-specific requirements:
Validate alignment with constitutional principles during planning:
Create a comprehensive readiness checklist before implementation begins:
Sources: README.md265-269
While specific implementation details are not available in the provided source files, the checklist command generates structured validation documents that follow consistent patterns based on the Spec-Driven Development philosophy.
Sources: README.md269
Sources: README.md245-269
The checklist command complements the template-based enforcement mechanisms embedded in specification and plan templates.
Complementary Enforcement:
| Mechanism | Type | Timing | Flexibility |
|---|---|---|---|
| Template Checklists | Embedded in templates | Applied during document creation | Fixed structure per template |
| Command Checklists | Generated on demand | Applied at validation checkpoints | Fully customizable per request |
The template-based checklists provide baseline validation (e.g., the Review & Acceptance Checklist in spec-template.md), while the /speckit.checklist command allows for additional project-specific or domain-specific validation criteria.
Sources: README.md265-269
| Benefit | Description |
|---|---|
| Early Quality Detection | Catch specification issues before planning and implementation |
| Structured Validation | Replace subjective quality assessments with objective criteria |
| Repeatable Process | Apply consistent validation across features and iterations |
| Audit Trail | Document quality validation for compliance and review purposes |
| Custom Criteria | Adapt validation to project-specific standards and constraints |
| Reduced Rework | Prevent downstream issues by validating specifications early |
Sources: README.md265-269
The /speckit.checklist command implements the philosophy of "unit tests for English" by providing structured, repeatable validation criteria for natural language specifications. As an optional quality command, it complements /speckit.clarify (interactive Q&A) and /speckit.analyze (cross-artifact validation) to form a comprehensive quality assurance layer in the Spec-Driven Development workflow.
Key characteristics:
Sources: README.md245-269
Refresh this wiki