spec-driven-dev

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Spec-Driven Development

规范驱动开发

Specs live in
.kiro/specs/<NN-name>/
. Numeric prefixes for ordering (
01-auth
,
02-api-layer
). Two modes:
  • Full ceremony (requirements.md → design.md → tasks.md): formal traceability, approval gates, multi-team
  • Fast-track (single
    spec.md
    ): one scratchpad for planner/builder/reviewer — no gates, cycle freely between hats
Detection:
spec.md
→ fast-track.
requirements.md
→ full ceremony. Never mix both. Small work: Add to an existing spec as tasks, or create a fast-track spec. Upgrade: Fast-track → full when >20 tasks or traceability needed: Context → requirements.md, Decisions → design.md, Tasks → tasks.md.
规范文件存放于
.kiro/specs/<NN-name>/
目录下。使用数字前缀排序(如
01-auth
02-api-layer
)。支持两种模式:
  • 完整流程(requirements.md → design.md → tasks.md):正式的可追溯性、审批关卡、适用于多团队场景
  • 快速通道(单个
    spec.md
    文件):供规划者/开发者/评审者共用的单一草稿本——无审批关卡,可自由切换角色
检测规则:存在
spec.md
则启用快速通道;存在
requirements.md
则启用完整流程。切勿混合使用两种模式。 小型任务:可添加至现有规范的任务列表中,或创建一个快速通道规范。 升级规则:当任务数量超过20个或需要可追溯性时,将快速通道规范升级为完整流程规范:上下文信息移入requirements.md,决策内容移入design.md,任务列表移入tasks.md。

Spec Lifecycle

规范生命周期

Every spec has a status. Write it in the first line of the top-level spec file (
spec.md
or
requirements.md
) as
Status: <STATE>
(plus a
Since:
date).
StateMeaningEditable?
DRAFTBeing planned, not yet approvedYes
ACTIVEApproved, implementation in progressYes (scope adjustments flow through
/spec-plan refine
)
SHIPPEDAll required tasks done; spec describes what was builtFrozen. Only forward-links to SUPERSEDED-BY or factual corrections
SUPERSEDEDReplaced by a newer spec; points forward to itFrozen. Same rule
OBSOLETEFeature removed; the spec is historical onlyFrozen. Same rule
Freeze on ship. Once a spec is SHIPPED, do not retroactively edit it to match new reality. Retroactive edits destroy the record of why each decision was made. New reality goes into a new spec and into the feature ledger.
Successor pattern. When a shipped feature needs rework, create a new spec (
NN-name-v2
or
NN-different-name
). Mark the old spec
SUPERSEDED
and add a
Superseded-by:
line pointing to the new spec. Update the feature ledger to reflect the transition.
每个规范都有一个状态。请在顶级规范文件(
spec.md
requirements.md
)的第一行中写入
Status: <STATE>
(同时标注
Since:
日期)。
状态含义是否可编辑?
DRAFT规划中,尚未获批
ACTIVE已获批,正在实施是(范围调整需通过
/spec-plan refine
流程)
SHIPPED所有必要任务已完成;规范描述已实现的功能冻结。仅可添加指向替代规范的链接或修正事实错误
SUPERSEDED已被新版本规范替代;需指向新规范冻结。遵循相同规则
OBSOLETE功能已移除;规范仅作历史记录冻结。遵循相同规则
上线即冻结。一旦规范进入SHIPPED状态,切勿为匹配新情况而追溯编辑规范。追溯编辑会破坏每项决策的记录依据。新情况应写入新规范并更新功能台账。
继任规范模式。当已上线的功能需要重构时,创建一个新规范(如
NN-name-v2
NN-different-name
)。将旧规范标记为SUPERSEDED,并添加
Superseded-by:
行指向新规范。更新功能台账以反映这一过渡。

Feature Ledger

功能台账

A project-level living inventory of features across all specs, organized by status. It is the source of truth for what exists right now; specs remain the source of truth for why each decision was made.
Location:
.kiro/FEATURES.md
(sibling of
specs/
and
steering/
). Read first. New agents should read this before any individual spec. Updated continuously. Every time a task ships, deprecates, or removes a feature, the corresponding ledger entry must be updated in the same session.
Structure is hierarchy-graphable so agents can later parse it into a tree or DAG:
  • H2 headers are domain paths:
    ## auth
    ,
    ## api/v2
    ,
    ## data/ingest
    . Nested domains use slash notation in the header.
  • H3 headers are feature ids (stable slugs):
    ### email-login
    .
  • A backticked status tag follows the feature id:
    `ACTIVE`
    .
  • Metadata follows as bold-key bullets (graph-parseable).
Template:
markdown
undefined
项目级的动态功能清单,涵盖所有规范中的功能,按状态分类。它是当前已实现功能的权威来源;而规范仍是每项决策依据的权威来源。
存放位置
.kiro/FEATURES.md
(与
specs/
steering/
同级)。 优先阅读:新Agent在查看任何单个规范前应先阅读此文件。 持续更新:每当任务上线、弃用或移除功能时,必须在同一会话中更新台账中对应的条目。
结构设计支持层级图形化解析,以便Agent后续将其转换为树状或有向无环图(DAG):
  • H2标题为领域路径:
    ## auth
    ## api/v2
    ## data/ingest
    。嵌套领域在标题中使用斜杠表示。
  • H3标题为功能ID(稳定的短标识):
    ### email-login
  • 功能ID后紧跟反引号包裹的状态标签:
    `ACTIVE`
  • 元数据以加粗关键字的项目符号呈现(支持图形解析)。
模板示例
markdown
undefined

Feature Ledger

Feature Ledger

Living inventory of features. Read this before any individual spec. Each H2 is a domain (slash-nested), each H3 is a feature id with a status tag; metadata bullets define graph edges.
Status values: DRAFT, PLANNED, IN-PROGRESS, BLOCKED, ACTIVE, DEPRECATED, SUPERSEDED, OBSOLETE
Last drift sweep: [YYYY-MM-DD]
Living inventory of features. Read this before any individual spec. Each H2 is a domain (slash-nested), each H3 is a feature id with a status tag; metadata bullets define graph edges.
Status values: DRAFT, PLANNED, IN-PROGRESS, BLOCKED, ACTIVE, DEPRECATED, SUPERSEDED, OBSOLETE
Last drift sweep: [YYYY-MM-DD]

auth

auth

email-login
ACTIVE

email-login
ACTIVE

  • spec: 01-auth
  • since: 2025-08-14
  • supersedes: [password-auth]
  • depends-on: [session-management]
  • description: Email + password login with session cookies.
  • spec: 01-auth
  • since: 2025-08-14
  • supersedes: [password-auth]
  • depends-on: [session-management]
  • description: Email + password login with session cookies.

magic-link
ACTIVE

magic-link
ACTIVE

  • spec: 01-auth
  • since: 2025-10-03
  • description: Passwordless one-time-link login via email.
  • spec: 01-auth
  • since: 2025-10-03
  • description: Passwordless one-time-link login via email.

password-auth
SUPERSEDED

password-auth
SUPERSEDED

  • spec: 01-auth
  • since: 2025-08-14
  • until: 2026-01-20
  • superseded-by: [email-login]
  • description: Original password-only flow, replaced by email-login.
  • spec: 01-auth
  • since: 2025-08-14
  • until: 2026-01-20
  • superseded-by: [email-login]
  • description: Original password-only flow, replaced by email-login.

api/v2

api/v2

bulk-export
IN-PROGRESS

bulk-export
IN-PROGRESS

  • spec: 05-bulk-export
  • target: 2026-Q2
  • depends-on: [session-management]
  • description: CSV/JSON export endpoint for user data.

**Graph model** (for downstream tools):

- Domain hierarchy: from H2 path.
- Feature id: H3 header, unique per project.
- Parent feature (subfeatures): `**parent**: <id>` bullet.
- Spec edges: `**spec**: <spec-id>`.
- Supersession edges: `**supersedes**` / `**superseded-by**`.
- Dependency edges: `**depends-on**`.
- Lifecycle edges: derived from status transitions recorded in the ledger's
  `since` / `until` fields.

**Append, don't rewrite.** Status transitions edit the row in place; obsolete
and superseded entries stay in the ledger. Never delete feature history.

**No separate snapshots needed.** A spec that is no longer the current one —
`SHIPPED`, `SUPERSEDED`, or `OBSOLETE` — is itself a dated record of what was
built then and why. Combined with the ledger's `since` / `until` fields and
git history on the ledger file, the project's state at any past point is
reconstructible without a separate snapshot artifact.
  • spec: 05-bulk-export
  • target: 2026-Q2
  • depends-on: [session-management]
  • description: CSV/JSON export endpoint for user data.

**图形模型**(供下游工具使用):

- 领域层级:来自H2路径。
- 功能ID:H3标题,每个项目唯一。
- 父功能(子功能):`**parent**: <id>`项目符号。
- 规范关联:`**spec**: <spec-id>`。
- 替代关联:`**supersedes**` / `**superseded-by**`。
- 依赖关联:`**depends-on**`。
- 生命周期关联:从台账`since`/`until`字段记录的状态转换中推导。

**仅追加,不重写**。状态转换直接在对应行编辑;已弃用和已替代的条目保留在台账中。切勿删除功能历史记录。

**无需单独快照**。不再是当前版本的规范——SHIPPED、SUPERSEDED或OBSOLETE状态的规范本身就是一份带有时间标记的记录,记录了当时实现的功能及决策依据。结合台账的`since`/`until`字段和台账文件的git历史,无需单独的快照工件即可重构项目在任何过去时间点的状态。

Spec Resolution

规范解析

SPEC →
.kiro/specs/*-SPEC/
or
.kiro/specs/SPEC/
. No name → auto-select if exactly one exists. Let SPEC_DIR = resolved directory. When creating, assign next available number.
SPEC →
.kiro/specs/*-SPEC/
.kiro/specs/SPEC/
。若未指定名称,当仅存在一个规范时自动选择。令SPEC_DIR为解析后的目录。创建规范时,分配下一个可用的数字前缀。

Core Loop

核心循环

mermaid
stateDiagram-v2
  [*] --> Plan : spec-plan create

  state Plan {
    [*] --> Scaffold
    Scaffold --> Scan
    Scan --> GenReqs : full
    Scan --> GenSpec : fast
    GenReqs --> Approve_R
    Approve_R --> GenReqs : revise
    Approve_R --> GenDesign : ok
    GenDesign --> Approve_D
    Approve_D --> GenDesign : revise
    Approve_D --> GenTasks : ok
    GenTasks --> Approve_T
    Approve_T --> GenTasks : revise
    GenSpec --> Ready
    Approve_T --> Ready
  }

  Plan --> Go : approved

  state Go {
    [*] --> Build
    state Build {
      [*] --> PickTask
      PickTask --> Implement
      Implement --> Test
      Test --> Implement : fix up to 3x
      Test --> Commit : pass
      Test --> Stuck : 3x fail
      Commit --> PickTask : more tasks
    }
    Build --> SelfReview : task done or stuck
    state SelfReview {
      [*] --> CheckSpec
      CheckSpec --> AddTests : coverage gaps
      CheckSpec --> MinorFix : add or tweak tasks
      AddTests --> CheckSpec
      MinorFix --> CheckSpec
      CheckSpec --> OK : clean
    }
    SelfReview --> Build : continue
    SelfReview --> Replan : drastic change
  }

  Replan --> Plan : human reviews new plan
  Go --> [*] : all tasks done
  Go --> [*] : stuck
Concurrency: Single orchestrator owns spec files, one sequential builder by default. Subagents OK for non-code work (research, docs, website). Parallel builders only when user explicitly requests AND tasks are truly independent.
StateEntryStops when
Plan
/spec-plan create [--fast]
User approves (full) or spec generated (fast)
Go
/spec-go
,
/spec-task
All done, needs human feedback, or stuck
Review
/spec-audit
,
/spec-status
,
/spec-plan refine
Findings presented
Resuming — detect from files on disk:
Files presentStateAction
NonePlan
/spec-plan create
spec.md
GoNext unchecked task
requirements.md
only
PlanGenerate design.md
requirements.md
+
design.md
PlanGenerate tasks.md
All 3 +
[ ]
tasks
GoNext task
All tasks
[x]
DoneAudit or merge
mermaid
stateDiagram-v2
  [*] --> Plan : spec-plan create

  state Plan {
    [*] --> Scaffold
    Scaffold --> Scan
    Scan --> GenReqs : full
    Scan --> GenSpec : fast
    GenReqs --> Approve_R
    Approve_R --> GenReqs : revise
    Approve_R --> GenDesign : ok
    GenDesign --> Approve_D
    Approve_D --> GenDesign : revise
    Approve_D --> GenTasks : ok
    GenTasks --> Approve_T
    Approve_T --> GenTasks : revise
    GenSpec --> Ready
    Approve_T --> Ready
  }

  Plan --> Go : approved

  state Go {
    [*] --> Build
    state Build {
      [*] --> PickTask
      PickTask --> Implement
      Implement --> Test
      Test --> Implement : fix up to 3x
      Test --> Commit : pass
      Test --> Stuck : 3x fail
      Commit --> PickTask : more tasks
    }
    Build --> SelfReview : task done or stuck
    state SelfReview {
      [*] --> CheckSpec
      CheckSpec --> AddTests : coverage gaps
      CheckSpec --> MinorFix : add or tweak tasks
      AddTests --> CheckSpec
      MinorFix --> CheckSpec
      CheckSpec --> OK : clean
    }
    SelfReview --> Build : continue
    SelfReview --> Replan : drastic change
  }

  Replan --> Plan : human reviews new plan
  Go --> [*] : all tasks done
  Go --> [*] : stuck
并发规则:单个协调者拥有规范文件的编辑权,默认采用单顺序开发者模式。子Agent可处理非代码工作(研究、文档、网站)。仅当用户明确要求且任务真正独立时,才可使用并行开发者模式。
状态触发方式终止条件
Plan(规划)
/spec-plan create [--fast]
用户审批通过(完整流程)或规范生成完成(快速通道)
Go(执行)
/spec-go
/spec-task
所有任务完成、需要人工反馈或陷入停滞
Review(回顾)
/spec-audit
/spec-status
/spec-plan refine
提交检查结果
恢复工作——从磁盘文件检测状态:
存在的文件状态操作
规划
/spec-plan create
spec.md
执行处理下一个未完成的任务
requirements.md
规划生成design.md
requirements.md
+
design.md
规划生成tasks.md
三个文件均存在且包含
[ ]
任务
执行处理下一个任务
所有任务标记为
[x]
完成审计或合并

Rules

规则

  1. Read before acting — feature ledger (
    .kiro/FEATURES.md
    ) first, then all spec files + steering docs if they exist.
  2. Re-anchor when uncertain — re-read spec if next action could deviate.
  3. Respect dependencies — never skip ahead.
  4. Tests are separate tasks.
  5. Commit per task
    feat(<spec>/<task>): [description]
  6. Minimal changes — only what the task requires.
  7. Respect spec lifecycle — never edit a SHIPPED / SUPERSEDED / OBSOLETE spec except for forward links or factual fixes. Create a successor spec instead.
  8. Update the ledger on ship — every feature transition (added, shipped, deprecated, removed) is reflected in
    .kiro/FEATURES.md
    in the same session.

  1. 行动前先阅读——优先阅读功能台账(
    .kiro/FEATURES.md
    ),然后阅读所有规范文件及 steering 文档(若存在)。
  2. 不确定时重新锚定——若下一步行动可能偏离规范,重新阅读规范。
  3. 尊重依赖关系——切勿跳过前置任务。
  4. 测试为独立任务
  5. 按任务提交——提交信息格式为
    feat(<spec>/<task>): [描述]
  6. 最小化变更——仅修改任务要求的内容。
  7. 遵守规范生命周期——切勿编辑SHIPPED/SUPERSEDED/OBSOLETE状态的规范,除非添加指向替代规范的链接或修正事实错误。应创建继任规范替代。
  8. 上线时更新台账——每个功能状态转换(新增、上线、弃用、移除)都必须在同一会话中反映到
    .kiro/FEATURES.md
    中。

Commands

命令

/spec-plan <name> [create|refine] [--fast]

/spec-plan <name> [create|refine] [--fast]

Auto-detected: create if spec doesn't exist, refine if it does.
自动检测:若规范不存在则执行create,若已存在则执行refine

Create (full ceremony)

创建(完整流程)

Scaffold: Create
.kiro/specs/NN-SPEC/
. Scan: Read README, manifests, source structure, tests, CI, steering docs. Align with conventions.
Generate requirements.md — template below. Generate first, iterate second. EARS format:
  • WHEN [event] THEN [system] SHALL [response]
  • IF [condition] THEN [system] SHALL [response]
  • WHILE [state] [system] SHALL [response]
  • [system] SHALL [response]
Write the file, then ask: "Please review requirements.md. Ready for design?"
Generate design.md — template below. Research if needed. Modules, interfaces, data flow, testing strategy, correctness properties validating requirements. Write the file, then ask: "Please review design.md. Ready for tasks?"
Generate tasks.md — template below. Each task one session. Depends/Requirements/Properties. Order: Foundation → Core → Tests → Polish. Every requirement → ≥1 task. Write the file, then ask: "Please review tasks.md. Ready to implement?"
// turbo Commit:
git add -A && git commit -m "spec(SPEC): create requirements, design, and tasks"
脚手架搭建:创建
.kiro/specs/NN-SPEC/
目录。 扫描:读取README、清单文件、源码结构、测试、CI配置、steering文档。确保与现有约定一致。
生成requirements.md——模板如下。先生成,再迭代优化。采用EARS格式:
  • WHEN [event] THEN [system] SHALL [response]
  • IF [condition] THEN [system] SHALL [response]
  • WHILE [state] [system] SHALL [response]
  • [system] SHALL [response]
写入文件后,询问:"请审阅requirements.md。是否准备好进入设计阶段?"
生成design.md——模板如下。必要时进行调研。内容包括模块、接口、数据流、测试策略、验证需求的正确性属性。写入文件后,询问:"请审阅design.md。是否准备好生成任务列表?"
生成tasks.md——模板如下。每个任务对应一个会话。包含依赖/需求/属性。顺序:基础架构 → 核心功能 → 测试 → 优化。每个需求对应至少一个任务。写入文件后,询问:"请审阅tasks.md。是否准备好开始实施?"
// 快速操作 提交
git add -A && git commit -m "spec(SPEC): create requirements, design, and tasks"

Create (fast-track)

创建(快速通道)

Same scaffold and scan. Generate
spec.md
(template below): Context, Decisions (can start empty), Tasks by P1/P2/P3. Iterate if feedback, then move on.
// turbo Commit:
git add -A && git commit -m "spec(SPEC): create fast-track spec"
执行相同的脚手架搭建和扫描步骤。生成
spec.md
(模板如下):包含上下文、决策(可初始为空)、按P1/P2/P3优先级划分的任务。根据反馈迭代后即可进入下一阶段。
// 快速操作 提交:
git add -A && git commit -m "spec(SPEC): create fast-track spec"

Refine (full ceremony)

优化(完整流程)

  1. Read requirements.md, design.md, tasks.md + scan repo for drift.
  2. Ask what should change (or use
    /spec-audit
    findings).
  3. Refinement: merge redundant requirements, separate what from how, collapse over-specified sub-requirements, merge overlapping properties, cascade renumbering, validate traceability (requirement → property → task), align spec with disk.
  4. Trace changes top-down and bottom-up. Done tasks (
    [x]
    ): update references, do NOT uncheck.
  5. Ask: "Please review the updated spec files. Approve refinement?"
// turbo Commit:
git add -A && git commit -m "spec(SPEC): refine — [brief]"
  1. 读取requirements.md、design.md、tasks.md并扫描仓库以检测偏差。
  2. 询问需要修改的内容(或使用
    /spec-audit
    的检查结果)。
  3. 优化操作:合并冗余需求、分离需求与实现细节、合并过度细分的子需求、合并重叠属性、重新编号、验证可追溯性(需求→属性→任务)、使规范与磁盘内容一致。
  4. 自上而下和自下而上跟踪变更。已完成的任务(
    [x]
    ):更新引用,切勿取消勾选。
  5. 询问:"请审阅更新后的规范文件。是否批准此次优化?"
// 快速操作 提交:
git add -A && git commit -m "spec(SPEC): refine — [简要说明]"

Refine (fast-track)

优化(快速通道)

Read
spec.md
, scan for drift, update Context/Decisions/Tasks, re-prioritize. If >20 tasks, suggest promoting to full ceremony. Append to Log.
// turbo Commit:
git add -A && git commit -m "spec(SPEC): refine fast-track — [brief]"

读取
spec.md
,扫描检测偏差,更新上下文/决策/任务,重新排序优先级。若任务数量超过20个,建议升级为完整流程规范。在日志中追加记录。
// 快速操作 提交:
git add -A && git commit -m "spec(SPEC): refine fast-track — [简要说明]"

/spec-go <name> [count]

/spec-go <name> [count]

Also triggered by: "run the spec", "implement the spec", "loop the spec", "build the spec".
This is a loop — do NOT stop after one task. Keep cycling build→self-review→build until: all tasks done, human feedback needed, or stuck on repeated failures. Optional count limits tasks per session.
Build phase:
  1. Read spec — full: requirements.md, design.md, tasks.md (+ steering). Fast-track: spec.md. Also read
    .kiro/FEATURES.md
    if present.
  2. Pick next task — first
    [ ]
    with all deps satisfied. Only optional left → STOP.
  3. Announce — "Starting task [ID]: [TITLE]"
  4. Implement — read relevant code first. Test tasks: Red-Green-Refactor. Implementation tasks: write code, run existing tests.
  5. Test — failures → fix up to 3x. Still failing → mark
    [!] BLOCKED: reason
    , skip to next. No unblocked tasks → STOP (stuck). // turbo
  6. Lint if configured.
  7. Update — mark task
    [x]
    .
  8. Update the feature ledger — if the task ships, deprecates, supersedes, or removes a feature, update the corresponding entry in
    .kiro/FEATURES.md
    . Add new features as
    IN-PROGRESS
    ACTIVE
    when fully shipped. Never delete prior entries; mark them SUPERSEDED / OBSOLETE with a forward link. // turbo
  9. Commit
    git add -A && git commit -m "feat(SPEC/[ID]): [description]"
Self-review phase (every 3 tasks or after a BLOCKED): 10. Re-read spec, check for drift. Primary job: ensure test coverage — for each completed task, verify a test task exists that covers it. If not, append a test task so the builder implements and runs it next. Tests must pass before the reviewer signs off. 11. Ledger consistency check — features marked ACTIVE in
.kiro/FEATURES.md
must correspond to shipped tasks; features marked IN-PROGRESS must have an open task. Fix inconsistencies inline. 12. Minor fixes (add/drop/tweak tasks, add test tasks) → apply inline, continue. Drastic changes (wrong requirements, architecture rethink, scope shift) → STOP, go to Plan for human review. 13. Report checkpoint:
Checkpoint: SPEC — N/TOTAL tasks done
  Completed this session:
    [x] 1.1: [title]
    [x] 1.2: [title]
  Blocked:
    [!] 2.1: [reason]
  Tests: PASS/FAIL
  Next: [ID]: [title]
  Spec drift: [none / what was fixed]
DO NOT STOP HERE. Go back to Build phase step 2 and pick the next task. Only stop when: all tasks
[x]
, a task needs human input, or stuck on repeated failures.

也可通过以下指令触发:"run the spec"、"implement the spec"、"loop the spec"、"build the spec"。
此为循环操作——完成单个任务后请勿停止。持续循环执行构建→自我回顾→构建,直到:所有任务完成、需要人工反馈或多次失败陷入停滞。可选的count参数用于限制单次会话处理的任务数量。
构建阶段
  1. 读取规范——完整流程:requirements.md、design.md、tasks.md(+ steering文档)。快速通道:spec.md。若存在
    .kiro/FEATURES.md
    也需读取。
  2. 选择下一个任务——第一个所有依赖均已满足的
    [ ]
    任务。若仅剩可选任务→停止。
  3. 通知——"Starting task [ID]: [TITLE]"
  4. 实施——先阅读相关代码。测试任务:采用红-绿-重构模式。实现任务:编写代码,运行现有测试。
  5. 测试——失败→最多修复3次。仍失败→标记为
    [!] BLOCKED: reason
    ,跳过至下一个任务。若无未阻塞任务→停止(陷入停滞)。 // 快速操作
  6. 代码检查(若已配置)。
  7. 更新——标记任务为
    [x]
  8. 更新功能台账——若任务涉及功能上线、弃用、替代或移除,更新
    .kiro/FEATURES.md
    中对应的条目。新增功能标记为
    IN-PROGRESS
    →完全上线后改为
    ACTIVE
    。切勿删除原有条目;将其标记为SUPERSEDED/OBSOLETE并添加指向新条目的链接。 // 快速操作
  9. 提交——
    git add -A && git commit -m "feat(SPEC/[ID]): [描述]"
自我回顾阶段(每完成3个任务或遇到阻塞后执行): 10. 重新阅读规范,检查偏差。核心任务:确保测试覆盖率——针对每个已完成的任务,验证是否存在对应的测试任务。若不存在,追加测试任务以便开发者下一步实现并运行。测试必须通过后评审者才可签字确认。 11. 台账一致性检查——
.kiro/FEATURES.md
中标记为ACTIVE的功能必须对应已上线的任务;标记为IN-PROGRESS的功能必须存在未完成的任务。即时修正不一致之处。 12. 小修改(添加/删除/调整任务、追加测试任务)→即时应用,继续执行。重大变更(需求错误、架构重构、范围调整)→停止,进入规划阶段等待人工评审。 13. ** checkpoint报告**:
Checkpoint: SPEC — N/TOTAL tasks done
  Completed this session:
    [x] 1.1: [title]
    [x] 1.2: [title]
  Blocked:
    [!] 2.1: [reason]
  Tests: PASS/FAIL
  Next: [ID]: [title]
  Spec drift: [none / what was fixed]
请勿在此处停止。返回构建阶段步骤2选择下一个任务。仅在以下情况停止:所有任务标记为
[x]
、任务需要人工输入或多次失败陷入停滞。

/spec-task <name> <task>

/spec-task <name> <task>

Single task build. Same as
/spec-go
build steps 1–9 for one task. Verify deps first — if unmet, STOP. When run by a subagent in a parallel worktree, never modify spec files or the feature ledger — only write code, tests, docs. Orchestrator updates status and ledger after merge.
→ Report:
Task [ID] complete: [title]
  Tests: PASS/FAIL
  Files changed: [list]
  Follow-up: [issues or "none"]

单个任务构建。与
/spec-go
的构建步骤1–9完全一致,仅处理单个任务。先验证依赖关系——若依赖未满足,停止执行。当由子Agent在并行工作树中执行时,切勿修改规范文件或功能台账——仅可编写代码、测试、文档。协调者在合并后更新状态和台账。
→ 报告格式
Task [ID] complete: [title]
  Tests: PASS/FAIL
  Files changed: [list]
  Follow-up: [issues or "none"]

/spec-audit <name>

/spec-audit <name>

Read requirements.md, design.md, tasks.md, and the feature ledger. Run checks:
  1. Traceability — orphan requirements, orphan properties, broken references
  2. Redundancy — duplicates, subset properties, implementation details in requirements
  3. Stale language — future tense on done tasks, checked goals with unchecked subs
  4. Spec↔disk drift — design directory vs actual repo
  5. Doc sync — README/docs vs spec
  6. Ledger sync — features referenced in this spec must appear in the ledger with consistent status; shipped tasks must correspond to ACTIVE ledger entries
→ Print report:
Audit: SPEC
  Traceability:
    ✓ N requirements → M properties → K tasks
    ⚠ R[N] has no validating property
    ⚠ P[N] has no implementing task
  Redundancy:
    ⚠ R[N] and R[M] describe same behavior
  Stale language:
    ⚠ R[N] future tense but task [ID] done
  Spec↔disk drift:
    ✗ spec lists "[path]" — not on disk
  Doc sync:
    ⚠ README says "[X]" but spec says "[Y]"
  Summary: E errors, W warnings
Suggest
/spec-plan SPEC refine
.

读取requirements.md、design.md、tasks.md和功能台账。执行以下检查:
  1. 可追溯性——孤立需求、孤立属性、无效引用
  2. 冗余性——重复内容、子集属性、需求中包含实现细节
  3. 过时表述——已完成任务仍使用将来时态、已勾选的目标对应未勾选的子任务
  4. 规范与磁盘偏差——设计目录与实际仓库不符
  5. 文档同步——README/文档与规范不一致
  6. 台账同步——本规范中引用的功能必须在台账中存在且状态一致;已完成的任务必须对应台账中的ACTIVE条目
→ 输出报告格式
Audit: SPEC
  Traceability:
    ✓ N requirements → M properties → K tasks
    ⚠ R[N] has no validating property
    ⚠ P[N] has no implementing task
  Redundancy:
    ⚠ R[N] and R[M] describe same behavior
  Stale language:
    ⚠ R[N] future tense but task [ID] done
  Spec↔disk drift:
    ✗ spec lists "[path]" — not on disk
  Doc sync:
    ⚠ README says "[X]" but spec says "[Y]"
  Summary: E errors, W warnings
建议执行
/spec-plan SPEC refine

/spec-status

/spec-status

Discover all specs in
.kiro/specs/
. Read tasks, count status marks, compute completion. Also read each spec's
Status:
lifecycle line and report it.
→ Print dashboard:
SPEC STATUS
  01-auth [SHIPPED]:
    Progress: ███████████ 7/7 (100%)
    Status:   1.1✓ 1.2✓ 1.3✓ 2.1✓ 2.2✓ 3.1✓ 3.2✓
    Blocked:  none
  02-api-layer [ACTIVE]:
    Progress: ██░░░░░░░░ 1/5 (20%)
    Status:   1.1✓ 1.2○ 2.1○ 2.2○ 3.1○*
    Blocked:  none
  03-legacy-export [SUPERSEDED → 05-bulk-export]:
    Progress: ███████ 3/5 (historical)
发现
.kiro/specs/
中的所有规范。读取任务列表,统计状态标记,计算完成进度。同时读取每个规范的
Status:
生命周期行并报告。
→ 输出仪表盘格式
SPEC STATUS
  01-auth [SHIPPED]:
    Progress: ███████████ 7/7 (100%)
    Status:   1.1✓ 1.2✓ 1.3✓ 2.1✓ 2.2✓ 3.1✓ 3.2✓
    Blocked:  none
  02-api-layer [ACTIVE]:
    Progress: ██░░░░░░░░ 1/5 (20%)
    Status:   1.1✓ 1.2○ 2.1○ 2.2○ 3.1○*
    Blocked:  none
  03-legacy-export [SUPERSEDED → 05-bulk-export]:
    Progress: ███████ 3/5 (historical)

/spec-ledger [audit | add <feature> <spec> | update <feature> <status> | drift-sweep]

/spec-ledger [audit | add <feature> <spec> | update <feature> <status> | drift-sweep]

Manage the project feature ledger at
.kiro/FEATURES.md
.
  • No args: print the ledger grouped by status.
  • audit
    :
    check every feature entry against code and specs. Flag:
    • ghost features (ACTIVE in ledger but not in code)
    • orphan features (in code but missing from ledger)
    • lifecycle mismatches (SHIPPED spec with non-ACTIVE feature)
    • broken supersession chains (superseded-by points to missing id)
  • add <feature-id> <spec-id>
    :
    append a new feature entry as
    PLANNED
    or
    IN-PROGRESS
    (depending on task state), under the appropriate domain H2.
  • update <feature-id> <STATUS>
    :
    transition a feature. Sets
    until:
    for DEPRECATED / SUPERSEDED / OBSOLETE; prompts for
    superseded-by:
    if needed.
  • drift-sweep
    :
    run
    audit
    , resolve non-ambiguous entries automatically, report the ambiguous ones, then stamp
    Last drift sweep: <date>
    in the ledger header.
Never delete prior entries. Status transitions edit in place; superseded and obsolete entries remain as historical record. Point-in-time reconstruction comes from the frozen shipped specs + git history on
FEATURES.md
— no separate snapshot artifact is maintained.
// turbo Commit:
git add .kiro/FEATURES.md && git commit -m "feat(ledger): <change summary>"
管理位于
.kiro/FEATURES.md
的项目功能台账。
  • 无参数:按状态分组输出台账内容。
  • audit
    :检查每个功能条目与代码和规范的一致性。标记以下问题:
    • 幽灵功能(台账中标记为ACTIVE但代码中不存在)
    • 孤立功能(代码中存在但台账中缺失)
    • 生命周期不匹配(规范为SHIPPED但功能状态非ACTIVE)
    • 无效替代链(superseded-by指向不存在的ID)
  • add <feature-id> <spec-id>
    :追加新功能条目,状态为
    PLANNED
    IN-PROGRESS
    (取决于任务状态),归入对应领域的H2标题下。
  • update <feature-id> <STATUS>
    :转换功能状态。对于DEPRECATED/SUPERSEDED/OBSOLETE状态,设置
    until:
    字段;若需要,提示输入
    superseded-by:
  • drift-sweep
    :执行
    audit
    ,自动解决无歧义的条目,报告有歧义的条目,然后在台账头部标记
    Last drift sweep: <date>
切勿删除原有条目。状态转换直接在对应行编辑;已替代和已弃用的条目保留为历史记录。结合冻结的已上线规范和
FEATURES.md
的git历史,可重构任意时间点的状态——无需维护单独的快照工件。
// 快速操作 提交:
git add .kiro/FEATURES.md && git commit -m "feat(ledger): <change summary>"

/spec-merge <name>

/spec-merge <name>

// turbo Find branches (
git branch --list "task/*"
,
git worktree list
), ask which to merge. Merge each (
git merge <branch> --no-edit
), resolve conflicts intelligently. Clean up branches/worktrees (confirm). Verify tasks status, tests, lint. Commit fixes:
git add -A && git commit -m "chore(SPEC): post-merge fixes"
// 快速操作 查找分支(
git branch --list "task/*"
git worktree list
),询问需要合并的分支。逐个合并(
git merge <branch> --no-edit
),智能解决冲突。清理分支/工作树(需确认)。验证任务状态、测试、代码检查。提交修复:
git add -A && git commit -m "chore(SPEC): post-merge fixes"

/spec-reset <name>

/spec-reset <name>

Confirm with user. Reset all status marks (
[x]
/
[~]
/
[!]
[ ]
, preserve
*
). // turbo Commit:
git add -A && git commit -m "chore(SPEC): reset progress"
需用户确认。重置所有状态标记(
[x]
/
[~]
/
[!]
[ ]
,保留
*
)。 // 快速操作 提交:
git add -A && git commit -m "chore(SPEC): reset progress"

/spec-help

/spec-help

Print the Core Loop diagram and command table from this skill, then ask what the user wants to do.

输出本技能文档中的核心循环图和命令表,然后询问用户需求。

Templates

模板

requirements.md

requirements.md

markdown
undefined
markdown
undefined

Requirements Document

Requirements Document

Status: DRAFT Since: [YYYY-MM-DD] Features: [feature-id, feature-id]
<!-- Status values: DRAFT, ACTIVE, SHIPPED, SUPERSEDED, OBSOLETE --> <!-- Once SHIPPED, this file is frozen except for forward links or factual fixes. -->
Status: DRAFT Since: [YYYY-MM-DD] Features: [feature-id, feature-id]
<!-- Status values: DRAFT, ACTIVE, SHIPPED, SUPERSEDED, OBSOLETE --> <!-- Once SHIPPED, this file is frozen except for forward links or factual fixes. -->

Introduction

Introduction

<!-- What this spec covers and why -->
<!-- What this spec covers and why -->

Glossary

Glossary

  • Term_1: Definition
  • Term_1: Definition

Requirements

Requirements

Requirement 1: [Feature area]

Requirement 1: [Feature area]

User Story: As a [role], I want [action], so that [benefit].
User Story: As a [role], I want [action], so that [benefit].

Acceptance Criteria

Acceptance Criteria

  1. WHEN [trigger], THE [Component] SHALL [expected behavior]
  2. WHEN [trigger], THE [Component] SHALL [expected behavior]
  1. WHEN [trigger], THE [Component] SHALL [expected behavior]
  2. WHEN [trigger], THE [Component] SHALL [expected behavior]

Requirement 2: [Feature area]

Requirement 2: [Feature area]

User Story: As a [role], I want [action], so that [benefit].
User Story: As a [role], I want [action], so that [benefit].

Acceptance Criteria

Acceptance Criteria

  1. WHEN [trigger], THE [Component] SHALL [expected behavior]
  1. WHEN [trigger], THE [Component] SHALL [expected behavior]

Non-Functional

Non-Functional

NF 1: [Performance / reliability / security requirement]
NF 1: [Performance / reliability / security requirement]

Out of Scope

Out of Scope

<!-- What this spec explicitly does NOT cover -->
undefined
<!-- What this spec explicitly does NOT cover -->
undefined

design.md

design.md

markdown
undefined
markdown
undefined

Design: [SPEC NAME]

Design: [SPEC NAME]

Tech Stack

Tech Stack

  • Language:
  • Framework:
  • Testing:
  • Linter:
  • Language:
  • Framework:
  • Testing:
  • Linter:

Directory Structure

Directory Structure

``` src/ tests/ ```
``` src/ tests/ ```

Architecture Overview

Architecture Overview

```mermaid graph TD A[Module A] --> B[Module B] A --> C[Module C] B --> D[Shared Service] C --> D ```
```mermaid graph TD A[Module A] --> B[Module B] A --> C[Module C] B --> D[Shared Service] C --> D ```

Module Design

Module Design

[Module 1]

[Module 1]

  • Purpose: [what it does]
  • Interface: ``` [function signatures, class interfaces, API endpoints] ```
  • Dependencies: [what it depends on]
  • Purpose: [what it does]
  • Interface: ``` [function signatures, class interfaces, API endpoints] ```
  • Dependencies: [what it depends on]

Data Flow

Data Flow

```mermaid sequenceDiagram participant User participant CLI participant Service participant Store User->>CLI: command CLI->>Service: process(args) Service->>Store: read/write Store-->>Service: result Service-->>CLI: output CLI-->>User: display ```
```mermaid sequenceDiagram participant User participant CLI participant Service participant Store User->>CLI: command CLI->>Service: process(args) Service->>Store: read/write Store-->>Service: result Service-->>CLI: output CLI-->>User: display ```

State Management

State Management

<!-- Omit if stateless -->
<!-- Omit if stateless -->

Data Models

Data Models

<!-- Omit if simple -->
<!-- Omit if simple -->

Error Handling Strategy

Error Handling Strategy

Testing Strategy

Testing Strategy

  • Property tests: Verify design invariants (required)
  • E2E tests: Validate user stories end-to-end (required)
  • Unit tests: Complex internal logic only (optional)
  • Test command:
    [command]
  • Lint command:
    [command]
  • Property tests: Verify design invariants (required)
  • E2E tests: Validate user stories end-to-end (required)
  • Unit tests: Complex internal logic only (optional)
  • Test command:
    [command]
  • Lint command:
    [command]

Constraints

Constraints

Correctness Properties

Correctness Properties

Property 1: [Property name]

Property 1: [Property name]

  • Statement: For any [condition], when [action], then [expected outcome]
  • Validates: Requirement 1.1, 1.2
  • Example: [concrete example]
  • Test approach: [how to verify]
  • Statement: For any [condition], when [action], then [expected outcome]
  • Validates: Requirement 1.1, 1.2
  • Example: [concrete example]
  • Test approach: [how to verify]

Edge Cases

Edge Cases

Decisions

Decisions

Decision: [Title]

Decision: [Title]

Context: [Situation] Options: 1. [Option] — Pros / Cons 2. [Option] — Pros / Cons Decision: [Chosen] Rationale: [Why]
Context: [Situation] Options: 1. [Option] — Pros / Cons 2. [Option] — Pros / Cons Decision: [Chosen] Rationale: [Why]

Security Considerations

Security Considerations

<!-- If applicable -->

**Diagram guidance**: Always include component diagram. Add sequence (multi-actor), state (stateful), ER (data-heavy). Omit empty sections.
<!-- If applicable -->

**图表指南**:必须包含组件图。根据需求添加序列图(多角色)、状态图(有状态场景)、ER图(数据密集场景)。省略空章节。

tasks.md

tasks.md

markdown
undefined
markdown
undefined

Tasks: [SPEC NAME]

Tasks: [SPEC NAME]

Status marks

Status marks

<!-- [ ] pending | [x] done | [~] skipped | [!] BLOCKED: reason | [ ]* optional -->
<!-- [ ] pending | [x] done | [~] skipped | [!] BLOCKED: reason | [ ]* optional -->

Tasks

Tasks

  • 1. Setup phase
    • 1.1 [Completed task title]
      • [What was implemented]
      • Depends: —
      • Requirements: 1.1, 1.2
      • Properties: 1
    • 1.2 [Completed task title]
      • Depends: 1.1
  • 2. Core phase
    • [!] 2.1 [Blocked task] BLOCKED: [reason]
      • Depends: 1.1
      • Requirements: 2.1
      • Properties: 2
    • 2.2 [Pending task]
      • Depends: 1.1, 1.2
    • 2.3 Write property test for [property name]
      • Depends: 2.2
      • Properties: 2
    • [ ]* 2.4 [Optional task]
      • Depends: 2.2
  • 3. E2E Tests
    • 3.1 E2E — [User story scenario]
      • Depends: 2.2, 2.3
      • Requirements: 1.1, 2.1
  • 1. Setup phase
    • 1.1 [Completed task title]
      • [What was implemented]
      • Depends: —
      • Requirements: 1.1, 1.2
      • Properties: 1
    • 1.2 [Completed task title]
      • Depends: 1.1
  • 2. Core phase
    • [!] 2.1 [Blocked task] BLOCKED: [reason]
      • Depends: 1.1
      • Requirements: 2.1
      • Properties: 2
    • 2.2 [Pending task]
      • Depends: 1.1, 1.2
    • 2.3 Write property test for [property name]
      • Depends: 2.2
      • Properties: 2
    • [ ]* 2.4 [Optional task]
      • Depends: 2.2
  • 3. E2E Tests
    • 3.1 E2E — [User story scenario]
      • Depends: 2.2, 2.3
      • Requirements: 1.1, 2.1

Notes

Notes


**Conventions**: Hierarchical IDs. Parents = phase headers (checked when all children done). **Depends** required; **Requirements**/**Properties** for traceability. Tests = separate sub-tasks. Each task 30 min – 2 hours.

**约定**:层级ID。父级为阶段标题(所有子任务完成后勾选)。**Depends**为必填项;**Requirements**/**Properties**用于可追溯性。测试为独立子任务。每个任务耗时30分钟–2小时。

spec.md (fast-track)

spec.md (快速通道)

This is the single working scratchpad for all three hats: planner (Context + Constraints + Tasks), builder (check off tasks + append Log), reviewer (Decisions + flag issues + add test tasks in Log). No gates — cycle freely between hats throughout the work.
markdown
undefined
这是供三种角色共用的单一工作草稿本:规划者(上下文+约束+任务)、开发者(勾选任务+追加日志)、评审者(决策+标记问题+在日志中添加测试任务)。无审批关卡——工作过程中可自由切换角色。
markdown
undefined

[SPEC NAME]

[SPEC NAME]

Status: DRAFT Since: [YYYY-MM-DD] Features: [feature-id, feature-id]
<!-- Status values: DRAFT, ACTIVE, SHIPPED, SUPERSEDED, OBSOLETE --> <!-- Once SHIPPED, this file is frozen except for forward links or factual fixes. -->
Status: DRAFT Since: [YYYY-MM-DD] Features: [feature-id, feature-id]
<!-- Status values: DRAFT, ACTIVE, SHIPPED, SUPERSEDED, OBSOLETE --> <!-- Once SHIPPED, this file is frozen except for forward links or factual fixes. -->

Context

Context

<!-- Why this work exists, who it's for, what success looks like. -->
[2-3 sentences describing the problem and motivation]
<!-- Why this work exists, who it's for, what success looks like. -->
[2-3 sentences describing the problem and motivation]

Constraints

Constraints

<!-- Non-negotiable boundaries: tech stack, perf, compatibility, timeline. -->
  • [e.g., Must use existing auth system]
  • [e.g., Python 3.11+, no new dependencies]
<!-- Non-negotiable boundaries: tech stack, perf, compatibility, timeline. -->
  • [e.g., Must use existing auth system]
  • [e.g., Python 3.11+, no new dependencies]

Decisions

Decisions

<!-- Key choices made. Add as you go — capture the fork, the choice, and why. -->
<!-- Key choices made. Add as you go — capture the fork, the choice, and why. -->

D1: [Decision title]

D1: [Decision title]

Choice: [what was decided] Why: [rationale — what was the alternative, why not that]
Choice: [what was decided] Why: [rationale — what was the alternative, why not that]

D2: [Decision title]

D2: [Decision title]

Choice: [what was decided] Why: [rationale]
Choice: [what was decided] Why: [rationale]

Tasks

Tasks

<!-- [ ] pending | [x] done | [~] skipped | [!] BLOCKED: reason -->
<!-- [ ] pending | [x] done | [~] skipped | [!] BLOCKED: reason -->

P1 — Must Do

P1 — Must Do

  • 1.1 [Completed task]
  • 1.2 [Pending task]
  • 1.3 Test: [what to verify for 1.1-1.2]
  • 1.1 [Completed task]
  • 1.2 [Pending task]
  • 1.3 Test: [what to verify for 1.1-1.2]

P2 — Should Do

P2 — Should Do

  • 2.1 [Task description]
  • 2.1 [Task description]

P3 — Nice to Have

P3 — Nice to Have

  • 3.1 [Task description]
  • 3.1 [Task description]

Open Questions

Open Questions

<!-- Unknowns that need research or user input before proceeding. -->
  • [Question — what needs answering, who can answer it]
  • [Resolved question — answer found, see D2]
<!-- Unknowns that need research or user input before proceeding. -->
  • [Question — what needs answering, who can answer it]
  • [Resolved question — answer found, see D2]

Log

Log

<!-- Append as you go. Date + what happened + decisions made + issues found. -->
[YYYY-MM-DD] — [what was done, what was learned, what changed] [YYYY-MM-DD] — [reviewer hat: added test task 1.3, found gap in X]

**Conventions**: IDs = `<priority>.<sequence>`. No Depends/Requirements metadata — keep lightweight. Status marks same as full ceremony. The Log is where the reviewer hat lives — flag drift, record why tasks were added/dropped, note test coverage gaps. Open Questions track unknowns that block or inform tasks.

---
<!-- Append as you go. Date + what happened + decisions made + issues found. -->
[YYYY-MM-DD] — [what was done, what was learned, what changed] [YYYY-MM-DD] — [reviewer hat: added test task 1.3, found gap in X]

**约定**:ID格式为`<priority>.<sequence>`。无需Depends/Requirements元数据——保持轻量化。状态标记与完整流程一致。日志是评审者角色的工作区——标记偏差、记录任务增删原因、标注测试覆盖率缺口。待解决问题用于跟踪阻碍或影响任务的未知事项。

---

Steering Docs (optional)

Steering Docs(可选)

Read-only project context at
.kiro/steering/
(root, not inside
specs/
):
product.md
(vision),
structure.md
(repo layout),
tech.md
(stack decisions). Read during planning and before implementing. Never modify during execution.
只读项目上下文存放在
.kiro/steering/
目录下(根目录,不在
specs/
内):
product.md
(愿景)、
structure.md
(仓库布局)、
tech.md
(技术栈决策)。规划阶段和实施前需阅读。执行过程中切勿修改。

Analytic Specs

分析类规范

When analytic/notebook/experiment-oriented, pair with
analytic-workbench
. Requirements should cover artifact outputs, review checkpoints, promotion criteria. Design should make notebook vs module boundaries explicit. Tasks should separate exploratory → review → promotion stages.
当规范面向分析/笔记本/实验场景时,需与
analytic-workbench
配合使用。需求应涵盖工件输出、评审检查点、推广标准。设计需明确笔记本与模块的边界。任务应划分为探索→评审→推广阶段。