kiro-impl
starsforks
How to install kiro-impl?
gotalab/cc-sdd/kiro-impl
$npx -y skills add gotalab/cc-sdd --skill kiro-implImplement approved tasks using TDD with subagent dispatch. Runs all pending tasks autonomously or selected tasks manually.
SKILL.md
| 1 | # kiro-impl Skill |
| 2 | |
| 3 | <background_information> |
| 4 | You operate in two modes: |
| 5 | - **Autonomous mode** (no task numbers): Dispatch a fresh sub-agent per task, with independent review after each |
| 6 | - **Manual mode** (task numbers provided): Execute selected tasks directly in the main context |
| 7 | |
| 8 | - **Success Criteria**: |
| 9 | - All tests written before implementation code |
| 10 | - Code passes all tests with no regressions |
| 11 | - Tasks marked as completed in tasks.md |
| 12 | - Implementation aligns with design and requirements |
| 13 | - Task completion follows the selected review mode |
| 14 | - **Review Mode**: |
| 15 | - Default is `required` |
| 16 | - Accept explicit forms: `--review required|inline|off` |
| 17 | - Also accept clear natural-language opt-outs such as `skip review` or `without review` as `off` |
| 18 | - If the request is ambiguous, keep `required` |
| 19 | </background_information> |
| 20 | |
| 21 | <instructions> |
| 22 | |
| 23 | ## Step 1: Gather Context |
| 24 | |
| 25 | If steering/spec context is already available from conversation, skip redundant file reads. |
| 26 | Otherwise, load all necessary context: |
| 27 | - `{{KIRO_DIR}}/specs/{feature}/spec.json`, `requirements.md`, `design.md`, `tasks.md` |
| 28 | - Core steering context: `product.md`, `tech.md`, `structure.md` |
| 29 | - Additional steering files only when directly relevant to the selected task's boundary, runtime prerequisites, integrations, domain rules, security/performance constraints, or team conventions that affect implementation or validation |
| 30 | - Relevant local agent skills or playbooks only when they clearly match the task's host environment or use case; read the specific artifact(s) you need, not entire directories |
| 31 | |
| 32 | ### Parallel Research |
| 33 | |
| 34 | The following research areas are independent and can be executed in parallel: |
| 35 | 1. **Spec context loading**: spec.json, requirements.md, design.md, tasks.md |
| 36 | 2. **Steering, playbooks, & patterns**: Core steering, task-relevant extra steering, matching local agent skills/playbooks, and existing code patterns |
| 37 | |
| 38 | After all parallel research completes, synthesize implementation brief before starting. |
| 39 | |
| 40 | ### Preflight |
| 41 | |
| 42 | **Validate approvals**: |
| 43 | - Verify tasks are approved in spec.json (stop if not, see Safety & Fallback) |
| 44 | |
| 45 | **Discover validation commands**: |
| 46 | - 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*` |
| 47 | - Derive a canonical validation set for this repo: `TEST_COMMANDS`, `BUILD_COMMANDS`, and `SMOKE_COMMANDS` |
| 48 | - Prefer commands already used by repo automation over ad hoc shell pipelines |
| 49 | - 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) |
| 50 | - Keep the full command set in the parent context, and pass only the task-relevant subset to implementer and reviewer sub-agents |
| 51 | |
| 52 | **Establish repo baseline**: |
| 53 | - Run `git status --porcelain` and note any pre-existing uncommitted changes |
| 54 | |
| 55 | ## Step 2: Select Tasks & Determine Mode |
| 56 | |
| 57 | **Parse arguments**: |
| 58 | - Extract feature name from `$1` |
| 59 | - If task numbers provided in `$2` (e.g., "1.1" or "1,2,3"): **manual mode** |
| 60 | - If no task numbers: **autonomous mode** (all pending tasks) |
| 61 | - Determine review mode from the invocation: |
| 62 | - `--review required` or omitted → `required` |
| 63 | - `--review inline` → `inline` |
| 64 | - `--review off`, `skip review`, or `without review` → `off` |
| 65 | |
| 66 | **Build task queue**: |
| 67 | - Read tasks.md, identify actionable sub-tasks (X.Y numbering like 1.1, 2.3) |
| 68 | - Major tasks (1., 2.) are grouping headers, not execution units |
| 69 | - Skip tasks with `_Blocked:_` annotation |
| 70 | - For each selected task, check `_Depends:_` annotations -- verify referenced tasks are `[x]` |
| 71 | - If prerequisites incomplete, execute them first or warn the user |
| 72 | - Use `_Boundary:_` annotations to understand the task's component scope |
| 73 | |
| 74 | ## Step 3: Execute Implementation |
| 75 | |
| 76 | ### Autonomous Mode (sub-agent dispatch) |
| 77 | |
| 78 | **Iteration 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. |
| 79 | |
| 80 | **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. |
| 81 | |
| 82 | If multi-agent capability is available, for each task (one at a time): |
| 83 | |
| 84 | **a) Dispatch implementer**: |
| 85 | - Read `templates/implementer-prompt.md` from this skill's directory |
| 86 | - Construct a prompt by combining the template with task-specific |
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
