Menu
Generate a custom checklist for the current feature based on user requirements.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Detects whether Spectatui has fallen behind upstream GitHub Spec-Kit by capturing the real `specify` CLI surface (via uvx, not by reading prose), reading spec-kit's actual upstream source — slash-command templates, document skeletons, shared scripts — for features invisible to `--help`, and comparing all of that against Spectatui's actual code. Use this whenever the user asks whether Spectatui supports something from Spec-Kit, mentions Spec-Kit/specify-cli releases or changelogs, asks what's new upstream, wants a gap analysis or integration roadmap between Spectatui and Spec-Kit, or wants to know if the CLI wrapper is out of date — even if they just say "check for spec-kit updates" or "are we behind on spec-kit" without naming this skill.
Perform a non-destructive cross-artifact consistency and quality analysis across spec.md, plan.md, and tasks.md after task generation.
Identify underspecified areas in the current feature spec by asking up to 5 highly targeted clarification questions and encoding answers back into the spec.
Create or update the project constitution from interactive or provided principle inputs, ensuring all dependent templates stay in sync.
Assess the current codebase against the feature's spec, plan, and tasks, then append any remaining unbuilt work as new tasks to tasks.md so implement can complete it.
Execute the implementation plan by processing and executing all tasks defined in tasks.md
| name | speckit-checklist |
| description | Generate a custom checklist for the current feature based on user requirements. |
| argument-hint | Domain or focus area for the checklist |
| compatibility | Requires spec-kit project structure with .specify/ directory |
| metadata | {"author":"github-spec-kit","source":"templates/commands/checklist.md"} |
| user-invocable | true |
| disable-model-invocation | false |
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:
FOR requirements quality validation:
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.
$ARGUMENTS
You MUST consider the user input before proceeding (if not empty).
Check for extension hooks (before checklist generation):
Check if .specify/extensions.yml exists in the project root.
If it exists, read it and look for entries under the hooks.before_checklist key
If the YAML cannot be parsed or is invalid, skip hook checking silently and continue normally
Filter out hooks where enabled is explicitly false. Treat hooks without an enabled field as enabled by default.
For each remaining hook, do not attempt to interpret or evaluate hook condition expressions:
condition field, or it is null/empty, treat the hook as executablecondition, skip the hook and leave condition evaluation to the HookExecutor implementationWhen constructing slash commands from hook command names, replace dots (.) with hyphens (-). For example, speckit.git.commit → /speckit-git-commit.
For each executable hook, output the following based on its optional flag:
Optional hook (optional: true):
## Extension Hooks
**Optional Pre-Hook**: {extension}
Command: `/{command}`
Description: {description}
Prompt: {prompt}
To execute: `/{command}`
Mandatory hook (optional: false):
## Extension Hooks
**Automatic Pre-Hook**: {extension}
Executing: `/{command}`
EXECUTE_COMMAND: {command}
Wait for the result of the hook command before proceeding to the Execution Steps.
After emitting the block above you MUST actually invoke the hook and wait for it to finish before continuing. Run it the same way you would run the command yourself in this agent/session (the invocation may differ from the literal {command} id shown above, e.g. a skills-mode agent runs it as /skill:speckit-... or $speckit-...). Emitting the block alone does not run the hook.
If no hooks are registered or .specify/extensions.yml does not exist, skip silently
Setup: Run .specify/scripts/bash/check-prerequisites.sh --json from repo root and parse JSON for FEATURE_DIR and AVAILABLE_DOCS list.
IF EXISTS: Load .specify/memory/constitution.md for project principles and governance constraints.
Clarify intent (dynamic): Derive up to THREE initial contextual clarifying questions (no pre-baked catalog). They MUST:
$ARGUMENTSGeneration algorithm:
Question formatting rules:
Defaults when interaction impossible:
Output the questions (label Q1/Q2/Q3). After answers: if ≥2 scenario classes (Alternate / Exception / Recovery / Non-Functional domain) remain unclear, you MAY ask up to TWO more targeted follow‑ups (Q4/Q5) with a one-line justification each (e.g., "Unresolved recovery path risk"). Do not exceed five total questions. Skip escalation if user explicitly declines more.
Understand user request: Combine $ARGUMENTS + clarifying answers:
Load feature context: Read from FEATURE_DIR:
Context Loading Strategy:
Generate checklist - Create "Unit Tests for Requirements":
FEATURE_DIR/checklists/ directory if it doesn't existux.md, api.md, security.md)[domain].mdCORE PRINCIPLE - Test the Requirements, Not the Implementation: Every checklist item MUST evaluate the REQUIREMENTS THEMSELVES for:
Category Structure - Group items by requirement quality dimensions:
HOW TO WRITE CHECKLIST ITEMS - "Unit Tests for English":
❌ WRONG (Testing implementation):
✅ CORRECT (Testing requirements quality):
ITEM STRUCTURE: Each item should follow this pattern:
[Spec §X.Y] when checking existing requirements[Gap] marker when checking for missing requirementsEXAMPLES BY QUALITY DIMENSION:
Completeness:
Clarity:
Consistency:
Coverage:
Measurability:
Scenario Classification & Coverage (Requirements Quality Focus):
Traceability Requirements:
[Spec §X.Y], or use markers: [Gap], [Ambiguity], [Conflict], [Assumption]Surface & Resolve Issues (Requirements Quality Problems): Ask questions about the requirements themselves:
Content Consolidation:
🚫 ABSOLUTELY PROHIBITED - These make it an implementation test, not a requirements test:
✅ REQUIRED PATTERNS - These test requirements quality:
Structure Reference: Generate the checklist following the canonical template in .specify/templates/checklist-template.md for title, meta section, category headings, and ID formatting. If template is unavailable, use: H1 title, purpose/created meta lines, ## category sections containing - [ ] CHK### <requirement item> lines with globally incrementing IDs starting at CHK001.
Report: Output full path to checklist file, item count, and summarize whether the run created a new file or appended to an existing one. Summarize:
Important: Each /speckit-checklist command invocation uses a short, descriptive checklist filename and either creates a new file or appends to an existing one. This allows:
ux.md, test.md, security.md)checklists/ folderTo avoid clutter, use descriptive types and clean up obsolete checklists when done.
UX Requirements Quality: ux.md
Sample items (testing the requirements, NOT the implementation):
API Requirements Quality: api.md
Sample items:
Performance Requirements Quality: performance.md
Sample items:
Security Requirements Quality: security.md
Sample items:
❌ WRONG - These test implementation, not requirements:
- [ ] CHK001 - Verify landing page displays 3 episode cards [Spec §FR-001]
- [ ] CHK002 - Test hover states work correctly on desktop [Spec §FR-003]
- [ ] CHK003 - Confirm logo click navigates to home page [Spec §FR-010]
- [ ] CHK004 - Check that related episodes section shows 3-5 items [Spec §FR-005]
✅ CORRECT - These test requirements quality:
- [ ] CHK001 - Are the number and layout of featured episodes explicitly specified? [Completeness, Spec §FR-001]
- [ ] CHK002 - Are hover state requirements consistently defined for all interactive elements? [Consistency, Spec §FR-003]
- [ ] CHK003 - Are navigation requirements clear for all clickable brand elements? [Clarity, Spec §FR-010]
- [ ] CHK004 - Is the selection criteria for related episodes documented? [Gap, Spec §FR-005]
- [ ] CHK005 - Are loading state requirements defined for asynchronous episode data? [Gap]
- [ ] CHK006 - Can "visual hierarchy" requirements be objectively measured? [Measurability, Spec §FR-001]
Key Differences:
Check for extension hooks (after checklist generation):
Check if .specify/extensions.yml exists in the project root.
If it exists, read it and look for entries under the hooks.after_checklist key
If the YAML cannot be parsed or is invalid, skip hook checking silently and continue normally
Filter out hooks where enabled is explicitly false. Treat hooks without an enabled field as enabled by default.
For each remaining hook, do not attempt to interpret or evaluate hook condition expressions:
condition field, or it is null/empty, treat the hook as executablecondition, skip the hook and leave condition evaluation to the HookExecutor implementationWhen constructing slash commands from hook command names, replace dots (.) with hyphens (-). For example, speckit.git.commit → /speckit-git-commit.
For each executable hook, output the following based on its optional flag:
Optional hook (optional: true):
## Extension Hooks
**Optional Hook**: {extension}
Command: `/{command}`
Description: {description}
Prompt: {prompt}
To execute: `/{command}`
Mandatory hook (optional: false):
## Extension Hooks
**Automatic Hook**: {extension}
Executing: `/{command}`
EXECUTE_COMMAND: {command}
After emitting the block above you MUST actually invoke the hook and wait for it to finish before continuing. Run it the same way you would run the command yourself in this agent/session (the invocation may differ from the literal {command} id shown above, e.g. a skills-mode agent runs it as /skill:speckit-... or $speckit-...). Emitting the block alone does not run the hook.
If no hooks are registered or .specify/extensions.yml does not exist, skip silently