From kiro
Use when running a feature through the full kiro spec-driven lifecycle. Orchestrates init, requirements, design, tasks, and implementation with quality gates, audit trail, and reviewer integration.
npx claudepluginhub softwarecatscom/scc-marketplace --plugin kiroThis skill uses the workspace's default tool permissions.
Searches, retrieves, and installs Agent Skills from prompts.chat registry using MCP tools like search_skills and get_skill. Activates for finding skills, browsing catalogs, or extending Claude.
Searches prompts.chat for AI prompt templates by keyword or category, retrieves by ID with variable handling, and improves prompts via AI. Use for discovering or enhancing prompts.
Compares coding agents like Claude Code and Aider on custom YAML-defined codebase tasks using git worktrees, measuring pass rate, cost, time, and consistency.
Orchestrate the full kiro spec-driven lifecycle for a feature -- from description to validated code -- with quality gates, an audit trail, and automatic implementation mode selection.
/kiro:pipeline "feature description..." # New feature
/kiro:pipeline {feature-name} # Resume existing spec
/kiro:pipeline {feature-name} --from=design # Resume from specific phase
/kiro:pipeline {feature-name} --sequential # Force sequential implementation
On invocation, determine the starting point:
.kiro/specs/: Existing spec. Read spec.json to determine current phase.--from= flag present: Override auto-detection, start at specified phase.pipeline-log.md exists: Read it to understand prior decisions.spec.json phase | Resume from |
|---|---|
initialized | Phase 2: Requirements |
requirements | Phase 3: Gap Analysis or Phase 4: Design |
design | Phase 5: Tasks |
tasks-generated | Phase 6: Implementation |
implementation-complete | Phase 7: Validation |
completed | Nothing -- inform user spec is done |
Skip if: spec already exists.
/kiro:spec-init with the feature descriptionpipeline-log.md:
/kiro:spec-requirements {feature}requirements.mdRun gap analysis.
/kiro:validate-gap {feature}/kiro:reviewer {feature} requirements/kiro:spec-design {feature}/kiro:validate-design {feature}design.md/kiro:spec-tasks {feature}tasks.md_Requirements: X.X_)- [ ]*)/kiro:reviewer {feature} tasks(P) markers to determine implementation mode/kiro:spec-impl {feature} (all pending tasks)--sequential was set, note in logPost-implementation completeness check:
After execution finishes, read tasks.md and verify ALL tasks are [x]. Do NOT log Phase 6 as COMPLETE if any tasks remain [ ]. Either execute the remaining tasks or explicitly log them as deferred with a reason. A Phase 6 status of COMPLETE means every task in tasks.md is checked.
Step 1 -- Tasks completeness gate (mandatory):
Read tasks.md and verify ALL tasks are [x]. If any tasks remain [ ], Phase 7 verdict is NO-GO. List the unchecked tasks in the log. Do NOT proceed to verification commands until every task is checked.
Step 2 -- Automated verification:
/kiro:validate-impl {feature}npm run build, make build, cargo build) -- compilation/transpilationnpm run test, pytest, go test) -- unit tests passDiscover project commands from: steering docs (.kiro/steering/tech.md), package.json scripts, Makefile/justfile targets, or README.md. If unclear, ask the user.
Step 3 -- E2E test gate (mandatory when E2E tasks exist):
If tasks.md contains E2E test tasks, E2E tests MUST run before the pipeline can declare GO. Ask the user for permission to run E2E tests. If the user declines, the Phase 7 verdict is GO-PENDING-E2E (not GO). spec.json phase stays implementation-complete (not completed). The pipeline log marks Status: COMPLETE (pending E2E). The feature is NOT done until E2E tests pass.
Step 4 -- Verdict:
[x], build passes, unit tests pass, coverage met, E2E tests passAll pipeline activity is logged to .kiro/specs/{feature}/pipeline-log.md.
Rules:
Format:
# Pipeline Log: {feature-name}
## Phase N: {name} -- {ISO-8601 timestamp}
- Key metric 1: value
- Key metric 2: value
- Quality gate: PASS/FAIL (reason)
- User approval: APPROVED/REJECTED (feedback if rejected)
- Status: COMPLETE/FAILED/SKIPPED
These thresholds are enforced at quality gates:
| Standard | Threshold | Enforced At |
|---|---|---|
| Unit test coverage | Project default (80%+ recommended) | Phase 2 (requirement), Phase 7 (validation) |
| E2E test coverage | Project default (80%+ recommended) | Phase 2 (requirement), Phase 7 (validation) |
| Substantive requirements review | GO from /kiro:reviewer | Phase 3 |
| Design review (structural) | GO from /kiro:validate-design | Phase 4 |
| Requirements traceability | All reqs mapped to tasks | Phase 5 |
| Tasks review (substantive) | GO from /kiro:reviewer | Phase 5 |
| Testing tasks | Dedicated groups, not optional | Phase 5 |
| All tasks checked | Every [ ] in tasks.md must be [x] | Phase 6 (post-impl), Phase 7 (pre-validation) |
| Build passes | Project build command succeeds | Phase 7 |
| E2E tests pass | All E2E scenarios green (when E2E tasks exist) | Phase 7 (mandatory gate) |
| Failure | Recovery |
|---|---|
| Mechanical quality gate fails | Log failure reason, present to user, re-invoke phase with guidance |
/kiro:reviewer returns NO-GO | Log HIGH issues with evidence, revise artifact to address them, re-invoke reviewer |
/kiro:reviewer returns GO-with-conditions | Log deferred issues in pipeline-log.md. Proceed automatically. Do NOT pause for user acknowledgment -- deferred issues are informational, not blocking. |
/kiro:reviewer returns NEEDS-INPUT | Present the reviewer's specific question and options to the user. Wait for answer. Re-invoke reviewer with the answer. |
| Design gets NO-GO from validate-design | Log critical issues, re-invoke /kiro:spec-design with review feedback |
| Implementation fails | Log error, identify failing task, re-invoke for that specific task |
| Tests fail in validation | Log failures, create remediation tasks, re-invoke implementation |
| User rejects phase output (when asked via NEEDS-INPUT) | Log rejection reason, re-invoke phase |
| Do NOT | Do Instead |
|---|---|
| Pause the pipeline for manual approval when reviewer gave GO | Proceed automatically -- only NEEDS-INPUT and NO-GO pause the pipeline |
| Continue after NO-GO design review | Fix design issues before proceeding to tasks |
Mark testing tasks as optional (*) | Testing is mandatory -- first-class tasks |
| Run implementation after NO-GO verdict | Fix issues before proceeding -- but GO/GO-with-conditions proceed automatically |
| Modify pipeline-log.md entries retroactively | Append new entries -- the log is immutable |
| Run E2E tests without permission | Ask the user before running E2E tests |
| Escalate fixable gaps to user as "conditions" | Fix them in the artifact, re-review, then present clean results |
| Declare Phase 6 COMPLETE with unchecked tasks | Verify every [ ] is [x] before marking COMPLETE |
| Skip E2E gate in Phase 7 because user hasn't given permission yet | Ask for permission. If declined, use GO-PENDING-E2E verdict -- never plain GO |
Set spec.json phase to completed without E2E passing | Phase stays implementation-complete until E2E tests run and pass |