/kiro-validate-impl

name: kiro-validate-impl
description: Validate feature-level integration after all tasks are implemented. Checks cross-task consistency, full test suite, and overall spec coverage.

Implementation Integration Validation

<background_information> Individual tasks are usually reviewed during implementation. Your job is to catch problems that only become visible when looking across all tasks together.

Boundary terminology continuity:

• discovery identifies `Boundary Candidates`
• design fixes `Boundary Commitments`
• tasks constrain execution with `_Boundary:_`
• feature validation checks for cross-task `Boundary Violations`

• **Success Criteria**:
• All tasks marked `[x]` in tasks.md
• Full test suite passes (not just per-task tests)
• Cross-task integration works (data flows between components, interfaces match)
• Requirements coverage is complete across all tasks (no gaps between tasks)
• Design structure is reflected end-to-end (not just per-component)
• No orphaned code, conflicting implementations, integration seams, or boundary spillover

**What This Skill Does NOT Do**: This skill is not a full replacement for task-local review during `/kiro-impl`. This skill does NOT re-check every individual task acceptance criterion, every per-file reality check, or every single-task spec detail unless a concrete integration finding forces it.

This skill's main question is: when the completed tasks are viewed together, do they still respect the designed boundary seams and dependency direction? </background_information>

<instructions>

Execution Steps

1. Detect Validation Target

**If no arguments provided** (`$1` empty):

• Parse conversation history for `/kiro-impl <feature> [tasks]` commands
• Extract feature names and task numbers from each execution
• Aggregate all implemented tasks by feature
• Report detected implementations (e.g., "user-auth: 1.1, 1.2, 1.3")
• If no history found, scan `{{KIRO_DIR}}/specs/` for features with completed tasks `[x]`

**If feature provided** (`$1` present, `$2` empty):

• Use specified feature
• Detect all completed tasks `[x]` in `{{KIRO_DIR}}/specs/$1/tasks.md`

**If both feature and tasks provided** (`$1` and `$2` present):

• Validate specified feature and tasks only (e.g., `user-auth 1.1,1.2`)

Sub-agent Dispatch (parallel)

The following validation dimensions are independent and can be dispatched as **sub-agents**. The agent should decide the optimal decomposition based on feature scope — split, merge, or skip sub-agents as appropriate. Each sub-agent returns a **structured findings summary** to keep the main context clean for GO/NO-GO synthesis.

**Typical validation dimensions** (adjust as appropriate):

• **Test execution**: Run the complete test suite, report pass/fail with details
• **Requirements coverage**: Build requirements → implementation matrix, report gaps
• **Design alignment**: Verify architecture matches design.md, report drift and dependency violations
• **Cross-task integration**: Verify data flows, API contracts, shared state consistency

If multi-agent is not available, run checks sequentially in main context.

After all checks complete, synthesize findings for GO/NO-GO/MANUAL_VERIFY_REQUIRED assessment.

If the implementation run explicitly skipped task-local review (for example `--review off`), tighten scrutiny on obvious task-level gaps that surface during integration validation and call out that reduced review coverage in the report.

2. Load Context

For each detected feature:

• Read `{{KIRO_DIR}}/specs/<feature>/spec.json` for metadata
• Read `{{KIRO_DIR}}/specs/<feature>/requirements.md` for requirements
• Read `{{KIRO_DIR}}/specs/<feature>/design.md` for design structure
• Read `{{KIRO_DIR}}/specs/<feature>/tasks.md` for task list and Implementation Notes
• Core steering context: `product.md`, `tech.md`, `structure.md`
• Additional steering files only when directly relevant to the validated boundaries, runtime prerequisites, integrations, domain rules, security/performance constraints, or team conventions that affect the GO/NO-GO call

**Discover canonical 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 feature-level 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)
• If multiple candidates exist, prefer the command with the smallest setup cost that still exercises the real built artifact

3. Execute Integration Validation

Mechanical Checks (run commands, use results)

**A. Full Test Suite**

• Run the discovered canonical full-test command. Use the exit code.
• If tests fail → NO-GO. No judgment needed.
• If the canonical test command cannot be identified → `MANUAL_VERIFY_REQUIRED`

**B. Residual TBD/TODO/FIXME**

• Run: `grep -rn "TBD\|TODO\|FIXME\|HACK\|XXX" <files-in-feature-boundary>`
• If matches found that were introduced by this feature → flag as Warning

**C. Residual Hardcoded Secrets**

• Run: `grep -rn "password\s*=\|api_key\s*=\|secret\s*=\|token\s*=" <files-in-feature-boundary>` (case-insensitive)
• If matches found that aren't environment variable references → flag as Critical

**D. Runtime Liveness (Smoke Boot)**

• Run the discovered canonical smoke command that proves the built artifact actually starts and reaches its first usable state.
• Examples if relevant: open the root URL in a headless browser and require zero boot-time console errors; launch Electron and wait for the