Download tools/cc-sdd/templates/agents/antigravity-skills/skills/kiro-validate-impl/SKILL.md from the publisher, or copy the path and open the repository. PlugMCP lists the skill and does not host the file.
Where does kiro-validate-impl live?
The publisher keeps it at https://github.com/gotalab/cc-sdd.
Which agents can use kiro-validate-impl?
Claude, Cursor, and Codex can read a SKILL.md you add from the publisher's repository.
Validate feature-level integration after all tasks are implemented. Checks cross-task consistency, full test suite, and overall spec coverage.
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>
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
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
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
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
Use explicitly requested skills and task-relevant local skills/playbooks, including design, accessibility, and UX. Select by description and read only needed guidance, even for small tasks; preserve required checks and host/project rules.
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
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 main process ready signal and first renderer load; run a CLI with --help; start a service and hit its health endpoint.
If boot produces a runtime crash, unhandled exception, module-load failure, native ABI mismatch, or missing required env/config → NO-GO.
If no trustworthy smoke command can be identified, or the required runtime environment is unavailable → MANUAL_VERIFY_REQUIRED
Judgment Checks (read code, compare to spec)
E. Cross-Task Integration
Identify where tasks share interfaces, data models, or API contracts
Verify that Task A's output format matches Task B's expected input
Check for conflicting assumptions between tasks (naming conventions, error codes, data shapes)
Verify shared state (database schemas, config, environment) is consistent across tasks
Verify integration work happens at the intended seams rather than by leaking one boundary's behavior into another
F. Requirements Coverage Gaps
Map every requirement section to at least one completed task
Identify requirements that no single task fully covers (cross-cutting requirements)
Identify requirements partially covered by multiple tasks but not fully by any
Use the original section numbering from requirements.md; do NOT invent REQ-* aliases
G. Design End-to-End Alignment
Verify the overall component graph matches design.md
Check that integration patterns (event flow, API boundaries, dependency injection) work as designed
Verify dependency direction follows design.md's architecture (no upward imports)
Verify File Structure Plan matches the actual file layout
Identify any architectural drift from the original design
Use the original section numbering from design.md
G.5 Boundary Audit
Compare completed work against the design's Boundary Commitments, Out of Boundary, Allowed Dependencies, and Revalidation Triggers
Identify cross-task spillover where one area quietly absorbed another boundary's responsibility
Identify downstream-specific workarounds embedded upstream "to make integration easier"
Identify new hidden dependencies or shared ownership that were not declared in the design
If a revalidation trigger fired, verify the affected adjacent specs or integration points were actually re-checked
H. Blocked Tasks & Implementation Notes
Check for any tasks still marked _Blocked:_ — report why and assess impact on feature completeness
Review ## Implementation Notes in tasks.md for cross-cutting insights that need attention
4. Generate Report
Before returning GO, apply the kiro-verify-completion protocol to the feature-level claim. Tests alone are insufficient: include full-suite, runtime liveness, coverage, integration, design-alignment, and blocked-task status in the evidence.
Classify concrete failures by ownership before writing remediation:
LOCAL if the defect belongs to the feature being validated
UPSTREAM if the root cause belongs to a dependency, foundation, shared platform, or earlier spec
UNCLEAR if ownership cannot be established from the available evidence
If ownership is UPSTREAM, do not collapse the issue into local remediation for this feature. Name the owning upstream spec and explain which dependent specs should be revalidated after that upstream fix lands.
Provide summary in the language specified in spec.json:
If NO-GO, REMEDIATION is mandatory — identify the exact issue and what needs to change.
Important Constraints
Strict Final Gate: Return GO only when all integration checks passed; return NO-GO for concrete failures and MANUAL_VERIFY_REQUIRED when mandatory validation could not be completed
Boundary integrity over convenience: Do not return GO if the feature only works by smearing responsibilities across boundaries, even when tests pass
Safety & Fallback
Error Scenarios
No Implementation Found: If no /kiro-impl in history and no [x] tasks, report "No implementations detected"
Test Command Unknown: Return MANUAL_VERIFY_REQUIRED and explain which validation command is missing; do not return GO
Missing Spec Files: Stop with error if spec.json/requirements.md/design.md missing
Next Steps Guidance
If GO Decision:
Feature validated end-to-end and ready for deployment or next feature
If NO-GO Decision:
Address integration issues listed
Re-run /kiro-impl <feature> [tasks] for targeted fixes
Re-validate with /kiro-validate-impl [feature]
Session Interrupted:
Safe to re-run — validation is read-only and idempotent
If MANUAL_VERIFY_REQUIRED:
Do not treat the feature as complete
Provide the exact missing validation step or environment prerequisite
How do I install kiro-validate-impl?
Download tools/cc-sdd/templates/agents/antigravity-skills/skills/kiro-validate-impl/SKILL.md from the publisher, or copy the path and open the repository. PlugMCP lists the skill and does not host the file.
Where does kiro-validate-impl live?
The publisher keeps it at https://github.com/gotalab/cc-sdd.
Which agents can use kiro-validate-impl?
Claude, Cursor, and Codex can read a SKILL.md you add from the publisher's repository.