Checklist Purpose: "Unit Tests for English"

CRITICAL CONCEPT: Checklists are UNIT TESTS FOR REQUIREMENTS WRITING - they validate the quality, clarity, and completeness of requirements in a given domain.

NOT for verification/testing:

•NOT "Verify the button clicks correctly"
•NOT "Test error handling works"
•NOT "Confirm the API returns 200"
•NOT checking if code/implementation matches the spec

FOR requirements quality validation:

•"Are visual hierarchy requirements defined for all card types?" (completeness)
•"Is 'prominent display' quantified with specific sizing/positioning?" (clarity)
•"Are hover state requirements consistent across all interactive elements?" (consistency)
•"Are accessibility requirements defined for keyboard navigation?" (coverage)
•"Does the spec define what happens when logo image fails to load?" (edge cases)

Metaphor: If your spec is code written in English, the checklist is its unit test suite. You're testing whether the requirements are well-written, complete, unambiguous, and ready for implementation - NOT whether the implementation works.

User Input

text

$ARGUMENTS

You MUST consider the user input before proceeding (if not empty).

Memory Integration

This skill generates quality validation artifacts - no memory search/save needed.

Constitution Alignment

This skill enforces project principles:

•Testable Requirements: Every requirement must be verifiable
•Traceability: Checklist items link back to spec sections

Execution Steps

•
Setup: Run .specify/scripts/bash/check-prerequisites.sh --json from repo root and parse JSON for FEATURE_DIR and AVAILABLE_DOCS list.
- •All file paths must be absolute.
•
Clarify intent (dynamic): Derive up to THREE initial contextual clarifying questions (no pre-baked catalog). They MUST:
- •Be generated from the user's phrasing + extracted signals from spec/plan/tasks
- •Only ask about information that materially changes checklist content
- •Be skipped individually if already unambiguous in $ARGUMENTS
- •Prefer precision over breadth
•
Understand user request: Combine $ARGUMENTS + clarifying answers:
- •Derive checklist theme (e.g., security, review, deploy, ux)
- •Consolidate explicit must-have items mentioned by user
- •Map focus selections to category scaffolding
- •Infer any missing context from spec/plan/tasks (do NOT hallucinate)
•
Load feature context: Read from FEATURE_DIR:
- •spec.md: Feature requirements and scope
- •plan.md (if exists): Technical details, dependencies
- •tasks.md (if exists): Implementation tasks
•
Generate checklist - Create "Unit Tests for Requirements":
- •Create FEATURE_DIR/checklists/ directory if it doesn't exist
- •
  Generate unique checklist filename:
  - •Use short, descriptive name based on domain (e.g., ux.md, api.md, security.md)
  - •Format: [domain].md
  - •If file exists, append to existing file
- •Number items sequentially starting from CHK001
- •Each /speckit.checklist run creates a NEW file (never overwrites existing checklists)
CORE PRINCIPLE - Test the Requirements, Not the Implementation: Every checklist item MUST evaluate the REQUIREMENTS THEMSELVES for:
- •Completeness: Are all necessary requirements present?
- •Clarity: Are requirements unambiguous and specific?
- •Consistency: Do requirements align with each other?
- •Measurability: Can requirements be objectively verified?
- •Coverage: Are all scenarios/edge cases addressed?
Category Structure - Group items by requirement quality dimensions:
- •Requirement Completeness
- •Requirement Clarity
- •Requirement Consistency
- •Acceptance Criteria Quality
- •Scenario Coverage
- •Edge Case Coverage
- •Non-Functional Requirements
- •Dependencies & Assumptions
- •Ambiguities & Conflicts
REQUIRED PATTERNS:
- •"Are [requirement type] defined/specified/documented for [scenario]?"
- •"Is [vague term] quantified/clarified with specific criteria?"
- •"Are requirements consistent between [section A] and [section B]?"
- •"Can [requirement] be objectively measured/verified?"
- •"Are [edge cases/scenarios] addressed in requirements?"
- •"Does the spec define [missing aspect]?"
ABSOLUTELY PROHIBITED:
- •Any item starting with "Verify", "Test", "Confirm", "Check" + implementation behavior
- •References to code execution, user actions, system behavior
- •"Displays correctly", "works properly", "functions as expected"
- •"Click", "navigate", "render", "load", "execute"
Traceability Requirements:
- •MINIMUM: >=80% of items MUST include at least one traceability reference
- •Each item should reference: spec section [Spec section X.Y], or use markers: [Gap], [Ambiguity], [Conflict], [Assumption]
•
Structure Reference: Generate the checklist following the canonical template in .specify/templates/checklist-template.md for title, meta section, category headings, and ID formatting.
•
Report: Output full path to created checklist, item count, and remind user that each run creates a new file. Summarize:
- •Focus areas selected
- •Depth level
- •Actor/timing
- •Any explicit user-specified must-have items incorporated

Example Checklist Types & Sample Items

UX Requirements Quality: ux.md

•"Are visual hierarchy requirements defined with measurable criteria? [Clarity, Spec section FR-1]"
•"Is the number and positioning of UI elements explicitly specified? [Completeness, Spec section FR-1]"
•"Are interaction state requirements (hover, focus, active) consistently defined? [Consistency]"

API Requirements Quality: api.md

•"Are error response formats specified for all failure scenarios? [Completeness]"
•"Are rate limiting requirements quantified with specific thresholds? [Clarity]"
•"Are authentication requirements consistent across all endpoints? [Consistency]"

Security Requirements Quality: security.md

•"Are authentication requirements specified for all protected resources? [Coverage]"
•"Are data protection requirements defined for sensitive information? [Completeness]"
•"Is the threat model documented and requirements aligned to it? [Traceability]"

Handoff

After completing this skill:

•Review checklist: Manually review generated checklist items
•Update spec: Run /speckit.clarify if gaps identified

References

•.specify/templates/checklist-template.md - Checklist template
•spec.md - Feature specification