kiro-validate-impl
starsforks
How to install kiro-validate-impl?
gotalab/cc-sdd/kiro-validate-impl
$npx -y skills add gotalab/cc-sdd --skill kiro-validate-implValidate feature-level integration after all tasks are implemented. Checks cross-task consistency, full test suite, and overall spec coverage.
SKILL.md
| 1 | # Implementation Integration Validation |
| 2 | |
| 3 | <background_information> |
| 4 | Individual tasks are usually reviewed during implementation. Your job is to catch problems that only become visible when looking across all tasks together. |
| 5 | |
| 6 | Boundary terminology continuity: |
| 7 | - discovery identifies `Boundary Candidates` |
| 8 | - design fixes `Boundary Commitments` |
| 9 | - tasks constrain execution with `_Boundary:_` |
| 10 | - feature validation checks for cross-task `Boundary Violations` |
| 11 | |
| 12 | - **Success Criteria**: |
| 13 | - All tasks marked `[x]` in tasks.md |
| 14 | - Full test suite passes (not just per-task tests) |
| 15 | - Cross-task integration works (data flows between components, interfaces match) |
| 16 | - Requirements coverage is complete across all tasks (no gaps between tasks) |
| 17 | - Design structure is reflected end-to-end (not just per-component) |
| 18 | - No orphaned code, conflicting implementations, integration seams, or boundary spillover |
| 19 | |
| 20 | **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. |
| 21 | |
| 22 | This skill's main question is: when the completed tasks are viewed together, do they still respect the designed boundary seams and dependency direction? |
| 23 | </background_information> |
| 24 | |
| 25 | <instructions> |
| 26 | ## Execution Steps |
| 27 | |
| 28 | ### 1. Detect Validation Target |
| 29 | |
| 30 | **If no arguments provided** (`$1` empty): |
| 31 | - Parse conversation history for `/kiro-impl <feature> [tasks]` commands |
| 32 | - Extract feature names and task numbers from each execution |
| 33 | - Aggregate all implemented tasks by feature |
| 34 | - Report detected implementations (e.g., "user-auth: 1.1, 1.2, 1.3") |
| 35 | - If no history found, scan `{{KIRO_DIR}}/specs/` for features with completed tasks `[x]` |
| 36 | |
| 37 | **If feature provided** (`$1` present, `$2` empty): |
| 38 | - Use specified feature |
| 39 | - Detect all completed tasks `[x]` in `{{KIRO_DIR}}/specs/$1/tasks.md` |
| 40 | |
| 41 | **If both feature and tasks provided** (`$1` and `$2` present): |
| 42 | - Validate specified feature and tasks only (e.g., `user-auth 1.1,1.2`) |
| 43 | |
| 44 | #### Sub-agent Dispatch (parallel) |
| 45 | |
| 46 | 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. |
| 47 | |
| 48 | **Typical validation dimensions** (adjust as appropriate): |
| 49 | - **Test execution**: Run the complete test suite, report pass/fail with details |
| 50 | - **Requirements coverage**: Build requirements → implementation matrix, report gaps |
| 51 | - **Design alignment**: Verify architecture matches design.md, report drift and dependency violations |
| 52 | - **Cross-task integration**: Verify data flows, API contracts, shared state consistency |
| 53 | |
| 54 | If multi-agent is not available, run checks sequentially in main context. |
| 55 | |
| 56 | After all checks complete, synthesize findings for GO/NO-GO/MANUAL_VERIFY_REQUIRED assessment. |
| 57 | |
| 58 | 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. |
| 59 | |
| 60 | ### 2. Load Context |
| 61 | |
| 62 | For each detected feature: |
| 63 | - Read `{{KIRO_DIR}}/specs/<feature>/spec.json` for metadata |
| 64 | - Read `{{KIRO_DIR}}/specs/<feature>/requirements.md` for requirements |
| 65 | - Read `{{KIRO_DIR}}/specs/<feature>/design.md` for design structure |
| 66 | - Read `{{KIRO_DIR}}/specs/<feature>/tasks.md` for task list and Implementation Notes |
| 67 | - Core steering context: `product.md`, `tech.md`, `structure.md` |
| 68 | - 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 |
| 69 | |
| 70 | **Discover canonical validation commands**: |
| 71 | - 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*` |
| 72 | - Derive a feature-level validation set for this repo: `TEST_COMMANDS`, `BUILD_COMMANDS`, and `SMOKE_COMMANDS` |
| 73 | - Prefer commands already used by repo automation over ad hoc shell pipelines |
| 74 | - 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) |
| 75 | - If multiple candidates exist, prefer the command with the smallest setup cost that still exercises the real built artifact |
| 76 | |
| 77 | ### 3. Execute Integration Va |
People who liked this also viewed
6 picksType
- hyperframes-cliUse the HyperFrames CLI development loop: init, add, catalog, capture, lint, check, snapshot, compare, grade-compare, preview, play, present, beats, keyframes, single or batch render, publish, cloud, SkillsJul 2026
- request-refactor-planSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- analyze-projectRigor Analyze / Rigor Audit read-only skill for deep learning research repositories. Use when the user wants to read and understand a repository, inspect model structure and training or inference entrSkillsMay 2026
- explore-codeRigor Improve implementation leaf skill for auditable candidate implementation in deep learning research repositories. Use when the researcher explicitly authorizes exploratory work on an isolated braSkillsMay 2026
- ubiquitous-languageSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- scaffold-exercisesSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
