/kiro-impl

name: kiro-impl
description: Implement approved tasks using TDD with subagent dispatch. Runs all pending tasks autonomously or selected tasks manually.

kiro-impl Skill

<background_information> You operate in two modes:

• **Autonomous mode** (no task numbers): Dispatch a fresh sub-agent per task, with independent review after each
• **Manual mode** (task numbers provided): Execute selected tasks directly in the main context

• **Success Criteria**:
• All tests written before implementation code
• Code passes all tests with no regressions
• Tasks marked as completed in tasks.md
• Implementation aligns with design and requirements
• Task completion follows the selected review mode
• **Review Mode**:
• Default is `required`
• Accept explicit forms: `--review required|inline|off`
• Also accept clear natural-language opt-outs such as `skip review` or `without review` as `off`
• If the request is ambiguous, keep `required`

</background_information>

<instructions>

Step 1: Gather Context

If steering/spec context is already available from conversation, skip redundant file reads. Otherwise, load all necessary context:

• `{{KIRO_DIR}}/specs/{feature}/spec.json`, `requirements.md`, `design.md`, `tasks.md`
• Core steering context: `product.md`, `tech.md`, `structure.md`
• Additional steering files only when directly relevant to the selected task's boundary, runtime prerequisites, integrations, domain rules, security/performance constraints, or team conventions that affect implementation or validation
• Relevant local agent skills or playbooks only when they clearly match the task's host environment or use case; read the specific artifact(s) you need, not entire directories

Parallel Research

The following research areas are independent and can be executed in parallel: 1. **Spec context loading**: spec.json, requirements.md, design.md, tasks.md 2. **Steering, playbooks, & patterns**: Core steering, task-relevant extra steering, matching local agent skills/playbooks, and existing code patterns

After all parallel research completes, synthesize implementation brief before starting.

Preflight

**Validate approvals**:

• Verify tasks are approved in spec.json (stop if not, see Safety & Fallback)

**Discover validation commands**:

• Inspect repository-local sources of truth in this order: project scripts/manifests (`package.json`, `pyproject.toml`, `go.mod`, `Cargo.toml`, app manifests), task runners (`Makefile`, `justfile`), CI/workflow files, existing e2e/integration configs, then `README*`
• Derive a canonical validation set for this repo: `TEST_COMMANDS`, `BUILD_COMMANDS`, and `SMOKE_COMMANDS`
• Prefer commands already used by repo automation over ad hoc shell pipelines
• For `SMOKE_COMMANDS`, choose the lightest trustworthy runtime-liveness check for the app shape (for example: root URL load, Electron launch, CLI `--help`, service health endpoint, mobile simulator/e2e harness if one already exists)
• Keep the full command set in the parent context, and pass only the task-relevant subset to implementer and reviewer sub-agents

**Establish repo baseline**:

• Run `git status --porcelain` and note any pre-existing uncommitted changes

Step 2: Select Tasks & Determine Mode

**Parse arguments**:

• Extract feature name from `$1`
• If task numbers provided in `$2` (e.g., "1.1" or "1,2,3"): **manual mode**
• If no task numbers: **autonomous mode** (all pending tasks)
• Determine review mode from the invocation:
• `--review required` or omitted → `required`
• `--review inline` → `inline`
• `--review off`, `skip review`, or `without review` → `off`

**Build task queue**:

• Read tasks.md, identify actionable sub-tasks (X.Y numbering like 1.1, 2.3)
• Major tasks (1., 2.) are grouping headers, not execution units
• Skip tasks with `_Blocked:_` annotation
• For each selected task, check `_Depends:_` annotations -- verify referenced tasks are `[x]`
• If prerequisites incomplete, execute them first or warn the user
• Use `_Boundary:_` annotations to understand the task's component scope

Step 3: Execute Implementation

Autonomous Mode (sub-agent dispatch)

**Iteration discipline**: Process exactly ONE sub-task (e.g., 1.1) per iteration. Do NOT batch multiple sub-tasks into a single sub-agent dispatch. Each iteration follows the full cycle: dispatch implementer → review → commit → re-read tasks.md → next.

**Context management**: At the start of each iteration, re-read `tasks.md` to determine the next actionable sub-task. Do NOT rely on accumulated memory of previous iterations. After completing each iteration, retain only a one-line summary (e.g., "1.1: READY_FOR_REVIEW, 3 files changed") and discard the full status report and reviewer details.

If multi-agent capability is available, for each task (one at a time):

**a) Dispatch implementer**:

• Read `templates/implementer-prompt.md` from this skill's directory
• Construct a prompt by combining the template with task-specific context:
• Task description and boundary scope
• Paths to spec files: requirements.md, design.md, tasks.md
• Exact requirement and design section numbers this task must satisfy (using source numbering, NOT invented `REQ-*` aliases)
• Task-relevant steering context and parent-discovered validation commands (tests/build/smoke as relevant)
• Whether the task is behavioral (Feature Flag Protocol) or non-behavioral
• **Previous learnings**: Include any `## Implementation Notes` entries from tasks.md that are relevant to this task's boundary or dependencies (e.g., "better-sqlite3 requires separate rebuild for Electron"). This prevents the same mistakes from recurring.
• The implementer sub-agent will read the spec files and build its own Task Brief (acceptance criteria, completion definition, design constraints, verification method) before implementation
• Spawn a fresh sub-agent with this prompt

**b) Handle implementer status**:

• Parse implementer status only from the exact `#