Passed 15 of 18 test cases with the skill, and 11 of 18 without it.
Without skill59%
With skill82%
Checks it passed that the model alone missed
Reports the completion status across phases
Directs the user to the next appropriate phase command
Includes boundary context or upstream downstream references
and 8 more in the full report
7 fixed11 passed either way2 still failing2 broke
Pass-rate lift
+23 pp
Tokens
+64%
Agent turns
0%
Response time
+21%
Model gemini-3.6-flashMeasured 8/12/2026v218 of 22 cases passed with skill · 18 comparable
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 4 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 4
Prompt
Check status for `order-routing`. `steering/roadmap.md` lists `order-routing` as dependent on `checkout-core`. Default summary scripts ignore steering folder files.
What was checked, without and with the skill
Checked
Without skill
With skill
Includes upstream dependency information from the roadmap referencing checkout-core
Missed
Passed
case-08 · gemini-3.6-flash · 8/12/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md63 linessingle file
kiro-spec-status Skill
Core Mission
Success Criteria:
Show current phase and completion status
Identify next actions and blockers
Provide clear visibility into progress
Surface boundary readiness, upstream/downstream context, and likely revalidation needs when available
Execution Steps
Step 1: Load Spec Context
Read {{KIRO_DIR}}/specs/$ARGUMENTS/spec.json for metadata and phase status
Read {{KIRO_DIR}}/specs/$ARGUMENTS/brief.md if it exists
Read existing files: requirements.md, design.md, tasks.md (if they exist)
Check {{KIRO_DIR}}/specs/$ARGUMENTS/ directory for available files
Read {{KIRO_DIR}}/steering/roadmap.md if it exists and this spec appears in it
Step 2: Analyze Status
Parse each phase:
Requirements: Count requirements and acceptance criteria
Design: Check for architecture, components, diagrams, and whether boundary sections are present
Tasks: Count completed vs total tasks (parse - [x] vs - [ ])
Approvals: Check approval status in spec.json
Boundary context:
From brief.md: note Boundary Candidates, Upstream / Downstream, and Existing Spec Touchpoints if present
From design.md: note Boundary Commitments, Out of Boundary, Allowed Dependencies, and Revalidation Triggers if present
From roadmap.md: note upstream dependencies and whether this spec is adjacent to Existing Spec Updates
Revalidation watchlist:
Identify downstream specs, neighboring existing-spec updates, or rollout-sensitive design notes that may need revalidation if this spec changes
Call out when the current spec shape looks too broad and may want roadmap/design splitting instead of more local repair
Step 3: Generate Report
Create report in the language specified in spec.json covering:
Current Phase & Progress: Where the spec is in the workflow
Completion Status: Percentage complete for each phase
Task Breakdown: If tasks exist, show completed/remaining counts
Boundary Context: Upstream/downstream, out-of-boundary, and allowed dependency notes when available