// Implement approved tasks using TDD with subagent dispatch. Runs all pending tasks autonomously or selected tasks manually.
Implement approved tasks using TDD with subagent dispatch. Runs all pending tasks autonomously or selected tasks manually.
Validate feature-level integration after all tasks are implemented. Checks cross-task consistency, full test suite, and overall spec coverage.
Implement approved tasks using TDD with native subagent dispatch. Runs all pending tasks autonomously or selected tasks manually.
Validate feature-level integration after all tasks are implemented. Checks cross-task consistency, full test suite, and overall spec coverage.
Validate feature-level integration after all tasks are implemented. Checks cross-task consistency, full test suite, and overall spec coverage.
Implement approved tasks using TDD with subagent dispatch. Runs all pending tasks autonomously or selected tasks manually.
| name | kiro-impl |
| description | Implement approved tasks using TDD with subagent dispatch. Runs all pending tasks autonomously or selected tasks manually. |
<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:
Review Mode:
required--review required|inline|offskip review or without review as offrequired
</background_information>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.mdproduct.md, tech.md, structure.mdThe following research areas are independent and can be executed in parallel:
After all parallel research completes, synthesize implementation brief before starting.
Validate approvals:
Discover validation commands:
package.json, pyproject.toml, go.mod, Cargo.toml, app manifests), task runners (Makefile, justfile), CI/workflow files, existing e2e/integration configs, then README*TEST_COMMANDS, BUILD_COMMANDS, and SMOKE_COMMANDSSMOKE_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)Establish repo baseline:
git status --porcelain and note any pre-existing uncommitted changesParse arguments:
$1$2 (e.g., "1.1" or "1,2,3"): manual mode--review required or omitted → required--review inline → inline--review off, skip review, or without review → offBuild task queue:
_Blocked:_ annotation_Depends:_ annotations -- verify referenced tasks are [x]_Boundary:_ annotations to understand the task's component scopeIteration 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:
templates/implementer-prompt.md from this skill's directoryREQ-* aliases)## 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.b) Handle implementer status:
## Status Report block and - STATUS: field.STATUS is missing, ambiguous, or replaced with prose, re-dispatch the implementer once requesting the exact structured status block only. Do NOT proceed to review without a parseable READY_FOR_REVIEW | BLOCKED | NEEDS_CONTEXT value.c) Review the task:
required:
templates/reviewer-prompt.md from this skill's directorykiro-review protocol to this task-local review._Boundary:_ scope, validation commands, implementer report, and the actual git diff as the primary source of truth.git diff itself to read the actual code changes and verify against the specinline:
kiro-review in the parent context using the same task evidence and the actual git diffoff:
d) Handle reviewer verdict:
off:
[x] or making any success claim, apply kiro-verify-completion using fresh evidence from the current code state; then mark task [x] in tasks.md and perform selective git commit## Review Verdict block and - VERDICT: field.VERDICT is missing, ambiguous, or replaced with prose, re-dispatch the reviewer once requesting the exact structured verdict only. Do NOT mark the task complete, commit, or continue to the next task without a parseable APPROVED | REJECTED value.[x] or making any success claim, apply kiro-verify-completion using fresh evidence from the current code state; then mark task [x] in tasks.md and perform selective git commite) Commit (parent-only, selective staging):
git add -A or git add .git add <file1> <file2> ... with explicit file pathsfeat(<feature-name>): <task description>f) Record learnings:
## Implementation Notes section at the bottom of tasks.mdg) Debug subagent (triggered by BLOCKED, NEEDS_CONTEXT unresolved, or REJECTED after 2 remediation rounds):
The debug subagent runs in a fresh context — it receives only the error information, not the failed implementation history. This avoids the context pollution that causes infinite retry loops.
templates/debugger-prompt.md from this skill's directorygit diff of the current uncommitted changeskiro-debug protocol to this failure investigation.git diff, task/spec refs, and any relevant Implementation Notes.Handle debug report:
NEXT_ACTION from the debug report's exact structured field.NEXT_ACTION: STOP_FOR_HUMAN → append _Blocked: <ROOT_CAUSE>_ to tasks.md, stop the feature run, and report that human review is required before continuingNEXT_ACTION: BLOCK_TASK → append _Blocked: <ROOT_CAUSE>_ to tasks.md, skip to next taskNEXT_ACTION: RETRY_TASK → preserve the current worktree; do NOT reset or discard unrelated changes. Spawn a new implementer sub-agent with the debug report's FIX_PLAN, NOTES, and the current git diff, and require it to repair the task with explicit edits only
_Blocked: debug attempted twice, still failing — <ROOT_CAUSE>_ to tasks.md, skip## Implementation Notes (this helps subsequent tasks avoid the same issue)(P) markers: Tasks marked (P) in tasks.md indicate they have no inter-dependencies and could theoretically run in parallel. However, kiro-impl processes them sequentially (one at a time) to avoid git conflicts and simplify review. The (P) marker is informational for task planning, not an execution directive.
Fallback: If multi-agent is not available, fall back to manual mode execution for all tasks.
For each selected task:
1. Build Task Brief: Before writing any code, read the relevant sections of requirements.md and design.md for this task and clarify:
2. Execute TDD cycle (Kent Beck's RED → GREEN → REFACTOR):
required: Apply kiro-review before marking the task complete. If the host supports fresh sub-agents in manual mode, use a fresh reviewer; otherwise perform the review in the main context using the kiro-review protocol. Do NOT continue until the verdict is parseably APPROVED.inline: Apply kiro-review in the main context before marking the task complete.off: Skip task-local review, but note that kiro-validate-impl becomes the primary quality gate before any feature-level completion claim.required|inline: Only after review returns APPROVED, apply kiro-verify-completion, then update the checkbox from - [ ] to - [x] in tasks.md.off: Apply kiro-verify-completion, then update the checkbox from - [ ] to - [x] in tasks.md.Autonomous mode:
$kiro-validate-impl $1 as a GO/NO-GO gatekiro-verify-completion to the feature-level claim using the validation result and fresh supporting evidenceManual mode:
$kiro-validate-impl $1 but do not auto-executeoff, treat $kiro-validate-impl $1 as mandatory before any feature-level success claimFor tasks that add or change behavior, enforce RED → GREEN with a feature flag:
Skip this protocol for: refactoring, configuration, documentation, or tasks with no behavioral change.
STATUS or reviewer VERDICT from surrounding prose; only the exact structured fields countgit checkout ., git reset --hard, or similar destructive rollback inside the implementation loopgit add -A or git add .; always stage explicit file pathsAutonomous mode: For each task, report: task ID, implementer status, reviewer verdict, files changed, commit hash. After all tasks: final validation result.
Manual mode: Tasks executed with test results. Status of completed/remaining tasks.
Format: Concise, in the language specified in spec.json.
Tasks Not Approved or Missing Spec Files:
$kiro-spec-requirements, $kiro-spec-design, $kiro-spec-tasks"Test Failures:
All Tasks Blocked:
Spec Conflicts with Reality:
_Blocked: <reason>_ -- do not silently work around itUpstream Ownership Detected:
Task Plan Invalidated During Implementation:
NEXT_ACTION: STOP_FOR_HUMAN because of task ordering, boundary, or decomposition problems, stop and return for human review of tasks.md or the approved plan instead of forcing a code workaroundSession Interrupted:
$kiro-impl $1 — completed tasks are already [x] in tasks.md and committed to git