/speckit.verify

description: Validates implementation completion by checking tasks, logic, tests, and code quality against specifications. Use when you need to verify that all tasks are properly completed.
argument-hint: "[optional-focus-area]"
allowed-tools: Read, Glob, Grep, Bash

Verify Feature Implementation - Comprehensive Validation

Overview

Validates implementation completion by checking tasks, logic, tests, and code quality against specifications. Use when you need to verify that all tasks are properly completed.

Usage

/speckit.verify $ARGUMENTS

Arguments

| Argument | Description | |--------------|------------------------------------------| | `$ARGUMENTS` | Combined arguments passed to the command |

Execution Steps

Execution Instructions

**Agent Selection**: To execute this task, use the following approach:

• Primary: Use `general-purpose` agent with appropriate domain expertise
• Or use specialized agent if available for the specific task type

User Input

$ARGUMENTS

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

Outline

**Goal**: Perform comprehensive verification of the implemented feature against specifications, ensuring all requirements are met, tests pass, and code quality standards are satisfied. This command runs AFTER `/speckit.implement` completes.

**Critical Principle**: This is a READ-ONLY analysis command. The ONLY file that may be written is `verification-report.md` in the feature directory. No other modifications are permitted.

1. Setup & Prerequisites

Run `.specify/scripts/bash/check-prerequisites.sh --json --require-tasks --include-tasks` from repo root and parse JSON for:

• FEATURE_DIR (absolute path)
• AVAILABLE_DOCS list
• Repository root

For single quotes in args like "I'm Groot", use escape syntax: e.g 'I'\''m Groot' (or double-quote if possible: "I'm Groot").

Abort if implementation appears incomplete with guidance to run `/speckit.implement` first.

2. Load Verification Context

**Load artifacts in order** (progressive, on-demand):

**Required**:

• tasks.md: Verify all tasks marked completed [X]
• spec.md: Requirements, user stories, acceptance criteria
• plan.md: Tech stack, architecture, file structure

**Optional** (load if present):

• data-model.md: Entity definitions and relationships
• contracts/: API specifications
• research.md: Technical decisions and constraints
• quickstart.md: Integration scenarios
• checklists/: Quality validation items

**Codebase**:

• Implementation files referenced in tasks.md
• Test files (unit, integration, e2e)
• Configuration files
• Documentation updates

3. Task Completion Verification

**Check tasks.md**:

For each task in tasks.md:

• [ ] Task is marked [X] or [x] (completed)
• [ ] No tasks remain with [ ] (incomplete)
• [ ] All file paths mentioned exist in codebase
• [ ] Implementation addresses task description

**Output**:

TASK COMPLETION STATUS
Total tasks: X
Completed: X [X%]
Incomplete: X [X%]
Status: [PASS/FAIL]

**If incomplete tasks found**:

INCOMPLETE TASKS:
- [Task ID]: [Description] → [Reason not completed]

Verification FAILS if any task incomplete unless justified (explicitly marked as deferred/optional in tasks.md).

4. Requirements Coverage Analysis

**Map implementation to specification**:

For each requirement in spec.md:

A. Functional Requirements

• [ ] Implementation code exists
• [ ] Code logic matches requirement description
• [ ] All acceptance criteria satisfied
• [ ] Edge cases handled

B. Non-Functional Requirements

• [ ] Performance targets met (if specified)
• [ ] Security measures implemented
• [ ] Accessibility requirements satisfied
• [ ] Scalability considerations addressed

C. User Stories

• [ ] All user actions supported
• [ ] Success criteria demonstrable
• [ ] Error scenarios handled gracefully

**Output format**:

REQUIREMENT: [ID or description]
Status: [COVERED/PARTIAL/MISSING]
Implementation: [File paths]
Evidence: [Specific code references]
Acceptance Criteria Met: X/Y
Issues: [If any]

5. Architecture & Design Compliance

**Verify against plan.md**:

A. Tech Stack Compliance

• [ ] All specified libraries/frameworks used correctly
• [ ] No unauthorized dependencies introduced
• [ ] Version constraints respected

B. Project Structure

• [ ] Files in expected locations per plan.md
• [ ] Directory structure follows specification
• [ ] Naming conventions consistent

C. Architectural Patterns

• [ ] Separation of concerns maintained
• [ ] Design patterns correctly applied
• [ ] Component boundaries respected
• [ ] Integration points match contracts

**Output**:

ARCHITECTURE COMPLIANCE
Tech Stack: [COMPLIANT/VIOLATIONS]
- [Package]: [Expected version] → [Actual version] [Status]

Structure: [COMPLIANT/VIOLATIONS]
- [Expected pattern] → [Actual implementation] [Status]

Design Patterns: [COMPLIANT/VIOLATIONS]
- [Pattern]: [Assessment]

6. Data Model Validation

**If data-model.md exists**:

For each entity:

• [ ] Entity class/model exists
• [ ] All fields present with correct types
• [ ] Relationships implemented correctly
• [ ] Validations in place
• [ ] State transitions (if any) handled

**Check**:

• Foreign key constraints
• Cascade behaviors
• Index definitions
• Migration files (if applicable)

**Output**:

DATA MODEL VERIFICATION
Entity: [Name]
- Fields: [X/Y present, types correct]
- Relationships: [X/Y implemented]
- Validations: [List]
- Status: [PASS/FAIL]

7. Contract Compliance

**If contracts/ exists**:

For each contract file:

A. API Endpoints

• [ ] Route/path matches contract
• [ ] HTTP methods correct
• [ ] Request schema validation implemented
• [ ] Response schema matches contract
• [ ] Status codes per specification

B. Error Handling

• [ ] All error cases from contract covered
• [ ] Error response format matches contract
• [ ] App