- config-upgrade-snapshot, raft-adapter-conformance: correct stale
phase metadata (both showed "tasks-generated" though every task was
already complete) and record their validate-impl GO decisions with
known-limitations notes (bug-1471/bug-1472-remainder, bug-1474
angle-b) for future spec ownership.
- component-failover-adoption: catch up design/requirements/research
docs to the Phase 6 fix (bug-1548/bug-1549, commit d479b707) that
landed after this spec was already marked closed.
- Promote 3 roadmap backlog items to specs (2026-08-10 discovery):
component-rejoin-resync (apiserver/scheduler rejoin resync),
worker-rejoin-resync (worker job-fact resync, hard prereq for
raft-apply-decoupling's facts half), scheduler-sim-diagnostics
(open-ended scheduler REPL debug/troubleshoot capability).
- roadmap.md updated to reflect all of the above.
- kiro-steering/kiro-steering-custom SKILL.md: fix stale template path
(templates/steering/ -> .kiro/settings/templates/steering/) plus
minor doc corrections in the other kiro-spec-* skills.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
3.1 KiB
3.1 KiB
| name | description | allowed-tools | argument-hint |
|---|---|---|---|
| kiro-spec-init | Initialize a new specification with detailed project description | Bash, Read, Write, Glob, AskUserQuestion | <project-description> |
Spec Initialization
## Core Task Generate a unique feature name from the project description ($ARGUMENTS) and initialize the specification structure.Execution Steps
- Check for Brief: If
.kiro/specs/{feature-name}/brief.mdexists (created by/kiro-discovery), read it. The brief contains problem, approach, scope, and constraints from the discovery session. Use this to pre-fill the project description and skip clarification questions that the brief already answers. - Clarify Intent: The Project Description in requirements.md must contain three elements: (a) who has the problem, (b) current situation, (c) what should change. If a brief.md exists and covers these, skip to step 3. Otherwise, ask the user to clarify before proceeding. Ask as many questions as needed; do not fill in gaps with your own assumptions.
- Check Uniqueness: Verify
.kiro/specs/for naming conflicts. If the directory already exists with onlybrief.md(nospec.json), use that directory (discovery created it). - Create Directory:
.kiro/specs/[feature-name]/(skip if already exists from discovery) - Initialize Files Using Templates:
- Read
.kiro/settings/templates/specs/init.json - Read
.kiro/settings/templates/specs/requirements-init.md - Replace placeholders:
{{FEATURE_NAME}}→ generated feature name{{TIMESTAMP}}→ current ISO 8601 timestamp{{PROJECT_DESCRIPTION}}→ from brief.md if available, otherwise $ARGUMENTSen→ language code (detect from user's input language, default toen)
- Write
spec.jsonandrequirements.mdto spec directory
- Read
Important Constraints
- Do NOT generate requirements, design, or tasks. This skill only creates spec.json and requirements.md.
Output Description
Provide output in the language specified in spec.json with the following structure:
- Generated Feature Name:
feature-nameformat with 1-2 sentence rationale - Project Summary: Brief summary (1 sentence)
- Created Files: Bullet list with full paths
- Next Step: Command block showing
/kiro-spec-requirements <feature-name>
Format Requirements:
- Use Markdown headings (##, ###)
- Wrap commands in code blocks
- Keep total output concise (under 250 words)
- Use clear, professional language per
spec.json.language
Safety & Fallback
- Ambiguous Feature Name: If feature name generation is unclear, propose 2-3 options and ask user to select
- Template Missing: If template files don't exist in
.kiro/settings/templates/specs/, report error with specific missing file path and suggest checking repository setup - Directory Conflict: If feature name already exists, append numeric suffix (e.g.,
feature-name-2) and notify user of automatic conflict resolution - Write Failure: Report error with specific path and suggest checking permissions or disk space