// 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.
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 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: Antigravity does not support programmatic sub-agent dispatch. Execute all tasks sequentially in the main context using the manual mode execution flow below.
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 subagents 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