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.
How this skill is triggered — by the user, by Claude, or both
Slash command
/kiro:pipeline-orchestrationThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
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.
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 |
npx claudepluginhub softwarecatscom/scc-marketplace --plugin kiroOrchestrates multi-session projects by implementing one feature per cycle from feature-list.json through TDD pipeline with quality gates and code review.
Enforces a gated Spec → Plan → Build → Test → Review → Ship lifecycle for multi-file features and projects, preventing AI coding agents from skipping specification and verification steps.
Orchestrates multi-phase project execution by dispatching dedicated persona agents for planning, execution, verification, and review. Use after spec approval for automated phase chaining.