/specs.task-review

description: "Provides capability to verify that implemented tasks meet specifications and pass code review. Use when needing to validate a completed task from devkit.task-implementation against its specification."
argument-hint: "[ --lang=java|spring|typescript|nestjs|react|python|general ] [ --task=\"docs/specs/XXX-feature/tasks/TASK-XXX.md\" ]"
allowed-tools: Task, Read, Write, Edit, Bash, Grep, Glob, TodoWrite, AskUserQuestion
model: inherit

Task Review

Verifies that implemented tasks meet specifications and pass code quality standards. This is the bridge between implementation and verification.

Overview

This command reviews a completed task to ensure: 1. **Task Implementation**: The task was implemented according to its specifications 2. **Spec Compliance**: The implementation aligns with the functional specification 3. **Code Quality**: The code passes code review standards 4. **Acceptance Criteria**: All acceptance criteria are met 5. **Definition of Done**: The documented completion conditions are fully satisfied

**Input**: `docs/specs/[id]/tasks/TASK-XXX.md` (from devkit.spec-to-tasks) **Output**: Review report with pass/fail status and findings

Workflow Position

Idea → Functional Specification → Tasks → Implementation → Review → Code Cleanup → Done
              (brainstorm)           (spec-to-tasks)       (task-implementation)  (task-review)   (code-cleanup)

Usage

# Review a specific task
/developer-kit-specs:specs.task-review docs/specs/001-user-auth/tasks/TASK-001.md

# With language specification for code review
/developer-kit-specs:specs.task-review --lang=spring docs/specs/001-user-auth/tasks/TASK-001.md

Arguments

| Argument | Required | Description | |----------|----------|-------------| | `--lang` | No | Target language/framework for code review | | `--task` | No | Task file path | | `--spec` | No | Path to spec folder |

Examples

Basic Usage

/developer-kit-specs:specs.task-review docs/specs/001-user-auth/tasks/TASK-001.md

With Language Specification

/developer-kit-specs:specs.task-review --lang=spring docs/specs/001-user-auth/tasks/TASK-001.md

Using Spec Detection

/developer-kit-specs:specs.task-review --task=TASK-001

Argument Parsing

1. Run the shared argument parser:

   python3 "${CLAUDE_PLUGIN_ROOT}/scripts/parse_args.py" "$ARGUMENTS"

Read the JSON output and extract:

• `task` → task file path (or construct from `spec` + `task_id`)
• `spec` → spec folder path
• `lang` → target language/framework
• `flags` → detect `--no-confirm`

2. If `spec` is null, auto-detect from git branch:

   branch=$(python3 "${CLAUDE_PLUGIN_ROOT}/scripts/current_branch.py")
   spec=$(python3 "${CLAUDE_PLUGIN_ROOT}/scripts/find_spec_from_branch.py")

3. Validate required parameters. If missing, ask user via AskUserQuestion.

Core Principles

• **Thorough verification**: Check every acceptance criterion and every DoD item
• **Spec alignment**: Ensure implementation matches functional requirements
• **Code quality**: Verify code passes review standards
• **Evidence-based**: Base findings on actual code, not assumptions
• **Use TodoWrite**: Track all progress throughout
• **No time estimates**: DO NOT provide or request time estimates

---

Phase 1: Task Analysis

**Goal**: Read and understand the task and its specifications

**Actions**:

1. (Argument parsing completed in Phase 0) 2. Read the task file (`docs/specs/[id]/tasks/TASK-XXX.md`) 3. Extract:

• Task ID and title
• Description
• Acceptance criteria
• Definition of Ready (DoR) and Definition of Done (DoD) sections
• Dependencies
• Reference to specification file
• `imp-requirements` and `ac-mapping` from frontmatter — which spec ACs this task claims to implement
• If either section is missing, stop the review and require the task document to be updated before continuing

4. Read the functional specification file (from task's spec reference) 5. Verify both files exist and are valid 6. If files not found, ask user for correct path via AskUserQuestion

---

Phase 2: Implementation Verification

**Goal**: Verify the task was implemented according to specifications

**Actions**:

1. Identify what files/components were created for this task:

• Check git diff to see what changed since task was started
• Look for new files matching the task scope
• Review implementation details

2. Verify implementation matches task description:

• Compare implemented functionality with task description
• Check if all described features are present
• Identify any deviations or missing parts

3. Document findings:

• What was implemented vs. what was specified
• Any deviations from the original plan
• Additional changes that were made

4. **Read decision-log.md if exists**:

• Check for `decision-log.md` in the spec folder
• If file exists, read any DEC entries related to this task (TASK-XXX)
• Use decision context to understand WHY deviations were made
• Reference specific decision IDs when explaining deviations in findings

---

Phase 3: Acceptance Criteria and DoD Validation

**Goal**: Verify all acceptance criteria and DoD items are met

**Actions**:

1. List all acceptance criteria from the task file 2. List all DoD items from the task file 3. For each acceptance criterion and DoD item:

• Identify code/tests/review evidence that validate it
• Check if tests exist and pass when relevant
• Verify the requirement is actually met

4. Mark each item as:

• ✅ Met (with evidence)
• ❌ Not met (with explanation)
• ⚠️ Partially met (with details) — treated as FAILED for `review_status`

5. **Update traceability-matrix.md**:

• Read `docs/specs/[id]/traceability-matrix.md`
• For this task (TASK-XXX), update the matrix:
• Fill in "Test Files" column with test file names created for this task
• Fill in "Code