/specs.task-implementation

description: Provides guided task implementation capability for executing specific tasks from a task list generated by spec-to-tasks. Use when implementing a specific task from a task list (use --task= prefix).
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 Implementation

Overview

You are helping a developer implement a specific task from a task list generated by `/developer-kit-specs:specs.spec-to-tasks`. This command follows a focused workflow optimized for single-task implementation.

Usage

/developer-kit-specs:specs.task-implementation [--lang=java|spring|typescript|nestjs|react|python|general] --task=task-name

Arguments

| Argument | Required | Description | |----------|----------|-------------| | `--lang` | No | Target language/framework | | `--task` | Yes | Task file path (e.g., docs/specs/XXX-feature/tasks/TASK-001.md) | | `--spec` | No | Path to spec folder |

Examples

Basic Usage

/developer-kit-specs:specs.task-implementation --task=docs/specs/001-feature/tasks/TASK-001.md

With Language Specification

/developer-kit-specs:specs.task-implementation --lang=spring --task=docs/specs/001-feature/tasks/TASK-002.md

Auto-Detect Spec from Branch

/developer-kit-specs:specs.task-implementation --lang=typescript --task=TASK-003

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` → boolean flags

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.

Action Routing

The `--action` flag determines the workflow path:

| Action | Workflow | Description | |--------|----------|-------------| | *(default)* | T-1 → T-7 | Full implementation workflow | | `cleanup` | T-7 only | Jump directly to post-review code cleanup |

After argument parsing, check the `action` field in the JSON output:

• If `action` is `null` or absent → proceed with the full implementation workflow (T-1 through T-6, T-7 optional)
• If `action` is `cleanup` → skip to **T-7: Code Cleanup** directly, using the provided `--task=` path

When routing to T-7 directly, still perform **T-7.1: Verify Review Status** to confirm the task is in `reviewed` state before executing cleanup.

Task Mode Detection

This command ONLY operates in Task Mode. If no `--task=` parameter is provided, inform the user that they should use the spec-driven flow (`devkit.brainstorm` → `devkit.spec-to-tasks`) or `/developer-kit:devkit.feature-development` for non-spec work.

Core Principles

• **Ask clarifying questions only when the task or codebase leaves ambiguity**: default to executing the task as written; use AskUserQuestion only for real blockers, dependency conflicts, or multiple valid interpretations.
• **Understand before acting**: Read and comprehend task requirements first
• **Read files identified by agents**: When launching agents, ask them to return lists of the most important files to

read. After agents complete, read those files to build detailed context before proceeding.

• **Follow acceptance criteria and DoD**: Implement exactly what is specified in the task and complete the documented Definition of Done
• **Use TodoWrite**: Track all progress throughout
• **No time estimates**: DO NOT provide or request time estimates or implementation timelines at any phase

---

Workflow: Task Implementation (10 Steps)

This command implements a specific task following a focused workflow:

• T-1: Task Identification
• T-2: Git State Check
• T-3: Dependency Check
• T-3.5: Knowledge Graph Validation
• T-3.6: Contract Validation
• T-3.7: Review Feedback Check
• T-4: Implementation
• T-5: Verification
• T-6: Task Completion
• T-7: Code Cleanup (Post-Review)

---

T-1: Task Identification

**Goal**: Extract and validate the task from the task list

**Actions**:

1. (Argument parsing completed in Phase 0) 2. Read the task file and extract:

• Task ID and title from YAML frontmatter
• Description
• Acceptance criteria
• Definition of Ready (DoR) and Definition of Done (DoD) sections
• Dependencies from YAML frontmatter
• Reference to specification file
• `imp-requirements` and `ac-mapping` from frontmatter — which spec ACs this task implements
• If either section is missing, stop and instruct the user to update the task document before implementation

3. **Spec Traceability Gate **:

• If the task file has `spec` reference, read the spec file to get full context:
• Load the spec's acceptance criteria list with their `[IMP]`/`[SEF]`/`[EXT]` taxonomy
• Identify which ACs this task covers (from `ac-mapping`)
• Identify which `[IMP]` ACs remain for other tasks
• Display to implementator:

   Task Traceability Context:
   - This task: TASK-XXX — "[title]"
   - Implements Spec ACs: [ac-mapping, e.g., AC-1, AC-3]
   - Corresponding REQ-IDs: [imp-requirements, e.g., REQ-001, REQ-003]
   
   Full Specification Context:
   - Total spec ACs: N ([I] implementable / [S] side-effect / [E] external)
   - This task covers: X/[I] implementable criteria
   - Remaining [IMP] criteria will be covered by: [list other tasks from task list]
   - Primary bounded context: [from spec's Bounded Context Impact Statement, if present]

• If the task has a **Cross-Boundary Warning** section: read it and note the risk level before proce