Menu
Wrap core checklist generation with BDD, NFR, and Visual Fidelity readiness gate.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
Wrap core analysis with behavior-first vertical consistency checks.
Apply approved architecture refactors by updating plan and task artifacts directly.
Perform a framework-agnostic architecture review validating implementation against spec.md, plan.md, tasks.md, and the governance and architecture constitutions.
Perform an architecture-aware verification gate validating implementation against spec.md, plan.md, tasks.md, and the Architecture Constitution.
Run a single architecture workflow that prefers memory-first context and can incorporate security review when available.
Run implementation with memory context, then review the produced implementation against security and architecture constraints.
| name | speckit-checklist |
| description | Wrap core checklist generation with BDD, NFR, and Visual Fidelity readiness gate. |
| compatibility | Requires spec-kit project structure with .specify/ directory |
| metadata | {"author":"github-spec-kit","source":"workflow-preset:.composed/speckit.checklist.md"} |
This wrapper must not redefine core-owned User Input, Pre-Execution Checks, extension hooks, base path resolution, or core file handling.
Checklists validate whether requirements are complete, clear, consistent, measurable, and ready for downstream planning. NOT for verification/testing: do not test implementation behavior, code execution, UI rendering, API responses, or whether the built system works.
CORE PRINCIPLE - Test the Requirements, Not the Implementation. Checklist questions must use requirement-quality forms such as "Are ... specified?", "Is ... quantified?", "Can ... be objectively verified?", or "Are ... requirements consistent?"
Use $ARGUMENTS as checklist intent. Generate dynamic clarifying questions with no pre-baked catalog only when the answer changes BDD, NFR, or Visual Fidelity checklist content. Use Q1/Q2/Q3 for initial questions and Q4/Q5 only for justified follow-up gaps.
For checklists/behavior-testability.md, create the file when absent; otherwise append or update without deleting existing checklist content. Before finishing, report the full path, item count, update mode, focus areas, depth level, actor/timing, must-have items, readiness status, and blockers.
Create or update checklists/behavior-testability.md as checklist artifacts only. This checklist is the plan-entry quality gate for BDD readiness and must evaluate requirements directly from spec.md; it must not depend on behavior drafts.
Include these sections:
Check that each applicable user story has observable acceptance behavior, each acceptance criterion is verifiable, and primary, alternate, exception, boundary, permission, validation, and state_conflict paths are covered when applicable.
Build a Case Coverage Matrix with one row per story or capability case type. Use case status: Required|Not Applicable|Unknown. Cover positive, negative, boundary, permission, validation, and state_conflict case types. Each row must have a stable Case ID. Required rows must cite the source spec.md section. Scenario IDs and case_coverage_blockers are assigned during /speckit.plan. Not Applicable requires rationale. Unknown must appear in Blocking Items. Required case type without observable acceptance behavior blocks PASS.
Check Given readiness from spec.md: required roles, permissions, starting state, entity state, and data are explicit enough for later fixture setup.
Check When readiness from spec.md: each trigger is an executable user action, request case, or system trigger.
Check Then readiness from spec.md: each outcome maps to feedback, business state, error semantics, or assertion intent.
Check Visual Fidelity Readiness when spec.md contains design-derived requirements, a design source, provider evidence blockers, or provider-specific design evidence requests. Also apply it when spec.md contains product-side visual requirements such as pixel-perfect, brand-critical, responsive visual, or UI visual acceptance requirements.
Use the behavior-testability checklist template as the visual gate authority.
Require source traceability, provider readiness status, evidence refs, and blockers, and clear visual requirements for state, responsive, accessibility, component mapping, and accepted exception coverage.
Build a Visual Fidelity Evidence Matrix with one row per visual requirement or visual proof obligation. Record Screenshot evidence level, declared visual proof required, provider evidence refs or screenshot refs, and any Gate Status: BLOCKED item in Blocking Items.
The Visual Fidelity Evidence Matrix alone decides visual planning readiness, proof level sufficiency, screenshot sufficiency, accepted exception rules, Gate Status, and Blocking Items.
Use one Visual Fidelity Evidence Matrix as the single visual readiness record; do not duplicate visual evidence decisions outside the matrix and Blocking Items.
Read visual facts from spec.md and evidence refs; do not call Figma, re-extract Figma evidence, rebuild provider matrices, or create another visual readiness path.
Do not add historical visual rules or alternate visual decision paths.
Responsive visual requirements block PASS only when they are complex, multi-state, or declare L2 or L3 visual proof; missing viewport-specific evidence then sets Gate Status: BLOCKED and lists the item in Blocking Items.
Screenshots support visual facts but do not create product semantics.
Check Non-Functional Requirement Readiness from spec.md: applicable performance, security and privacy, reliability and recovery, accessibility, compliance and auditability, observability, compatibility, data lifecycle, and cost or operational constraints are explicitly declared in spec.md as Required, Not Applicable, or Unknown.
For each NFR dimension, require either verifiable product-level criteria, a Not Applicable rationale, or an Unknown marker that identifies what must be clarified. Do not require technical designs such as SLAs, RTO/RPO formulas, cache layers, queues, deployment topology, or infrastructure choices unless the product requirement already states them.
Treat these NFR readiness gaps as blocking items: Required but missing from spec.md; Required but not verifiable from product-level criteria; Unknown and affects downstream design. Do not block planning for NFR dimensions marked Not Applicable with a rationale or for dimensions with explicit no-special-requirement statements.
Set Gate Status: PASS only when every applicable readiness item is checked and Blocking Items: none. Otherwise set Gate Status: BLOCKED and list each unchecked readiness item that prevents behavior projection or downstream planning.
Unchecked readiness items that prevent behavior projection or downstream planning are blocking items. Do not proceed to /speckit.plan. Requirement ambiguity returns to /speckit.clarify or /speckit.specify to resolve missing requirements before planning. Provider evidence readiness blockers return to /speckit.specify or provider intake, not /speckit.clarify.
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):
.specify/extensions.yml exists in the project root.hooks.before_checklist keyenabled is explicitly false. Treat hooks without an enabled field as enabled by default.condition expressions:
condition field, or it is null/empty, treat the hook as executablecondition, skip the hook and leave condition evaluation to the HookExecutor implementationoptional flag:
optional: true):
## Extension Hooks
**Optional Pre-Hook**: {extension}
Command: `/{command}`
Description: {description}
Prompt: {prompt}
To execute: `/{command}`
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.
{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..specify/extensions.yml does not exist, skip silentlySetup: 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.
hooks.after_checklist keyenabled is explicitly false. Treat hooks without an enabled field as enabled by default.condition expressions:
condition field, or it is null/empty, treat the hook as executablecondition, skip the hook and leave condition evaluation to the HookExecutor implementationoptional flag:
optional: true):
## Extension Hooks
**Optional Hook**: {extension}
Command: `/{command}`
Description: {description}
Prompt: {prompt}
To execute: `/{command}`
optional: false):
## Extension Hooks
**Automatic Hook**: {extension}
Executing: `/{command}`
EXECUTE_COMMAND: {command}
{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..specify/extensions.yml does not exist, skip silentlyBefore finishing, report the BDD, NFR, and Visual Fidelity readiness status and call out unchecked items that block planning.