skills/zixun-github/aisdlc/spec-implementation-plan

spec-implementation-plan

SKILL.md

spec-implementation-plan(I1:实现计划 / plan.md SSOT)

概览

I1 的目标是把 {FEATURE_DIR}/requirements/*{FEATURE_DIR}/design/* 转换为可直接执行的实现计划 {FEATURE_DIR}/implementation/plan.md,并将其作为唯一执行清单与状态 SSOT(checkbox 任务 + 每任务步骤 + 最小验证 + 提交点 + 审计信息)。

开始时宣布:「我正在使用 spec-implementation-plan 技能创建实现计划(plan.md SSOT)。」

何时使用 / 不使用

  • 使用时机
    • 你需要产出或更新 {FEATURE_DIR}/implementation/plan.md(I1 必做)。
    • 你准备进入 I2 执行,但当前没有“可勾选 + 可执行”的任务清单。
  • 不要用在
    • spec-context 失败、拿不到 FEATURE_DIR(此时必须停止)。
    • 输入侧 SSOT 不足:requirements/solution.mdrequirements/prd.md 都不存在,且无法追溯范围/验收(必须在 plan.md 标注 NEEDS CLARIFICATION 并阻断进入 I2)。

门禁 / 停止(严格执行)

REQUIRED SUB-SKILL:先满足 spec-context 门禁并在对话中回显 FEATURE_DIR=...(允许 (reuse))。

立刻停止(满足其一即可):

  • 未得到 FEATURE_DIR
  • 分支/目录不确定(你发现自己想“猜 .aisdlc/specs/... 路径”)
  • requirements/solution.mdrequirements/prd.md 均缺失,导致目标/范围/验收口径无法追溯
  • 任何关键不确定性无法在输入中证据化(必须写入 plan.md/## NEEDS CLARIFICATION,并明确“阻断进入 I2”)

输入 / 输出(落盘约定)

  • 读取(渐进式披露,最少必要)
    • 项目级(必读其索引或必要片段):project/memory/*project/contracts/project/adr/
    • Spec 级(按需最少读):{FEATURE_DIR}/requirements/solution.md{FEATURE_DIR}/requirements/prd.md(至少其一)
    • 影响分析(强制,若有 solution.md):必须读取 {FEATURE_DIR}/requirements/solution.md#impact-analysis,提取受影响模块清单与需遵守的不变量,作为 I1 的约束输入(缺失则停止并回到 R1 补齐)
    • Spec 级(如存在且相关):{FEATURE_DIR}/design/design.md{FEATURE_DIR}/design/research.md
  • 写入(唯一)
    • {FEATURE_DIR}/implementation/plan.md

小块任务粒度(重用 writing-plans)

每一步是一个动作(2–5 分钟),并在 plan.md 中写到“任何人照抄即可执行”:

  • 「写失败测试」(如适用)- 一步
  • 「运行确保失败」- 一步
  • 「实现让测试通过的最少代码」- 一步
  • 「运行验证确保通过」- 一步
  • 「提交」(频繁提交)- 一步

约束:I1 只写计划,不写代码;但每个任务必须声明其最小验证方式(命令 + 期望信号)。

plan.md 头部(必须)

必须以该头部开头(模板见 ./assets/plan-template.md):

# [需求名] 实现计划(SSOT)

> **必需技能:** `spec-implementation-execute`(按批次执行本计划)
> **上下文门禁:** 必须先用 `spec-context` 定位 `{FEATURE_DIR}`,失败即停止

**目标:** [一句话描述要交付什么]
**范围:** In / Out
**架构:** [2–3 句方法说明 + 关键约束]
**验收口径:** [引用 requirements/solution.md 或 requirements/prd.md 的 AC/验收点]
**影响范围:** [引用 requirements/solution.md#impact-analysis 的受影响模块清单]
**需遵守的不变量:** [从 requirements/solution.md#impact-analysis 提取的关键 API/Data 契约不变量]

---

计划正文(必须)

  • TL;DR:一句话概括计划目标与范围
  • 范围与边界:In/Out(对齐需求与设计)
  • 影响范围与约束(必填)
    • 受影响模块清单及影响类型(引用 requirements/solution.md#impact-analysis
    • 需遵守的 API/Data 契约不变量(逐条列出,标注来源模块/锚点)
    • 跨模块影响与协调事项(基于依赖关系图/影响分析)
  • 里程碑与节奏:阶段拆分、时间预估、交付物清单
  • 依赖与资源:外部系统/团队/权限/环境/数据依赖
  • 风险与验证:风险清单、验证方式、Owner
  • 验收口径:对应 PRD/方案的关键 AC 与验收人
  • NEEDS CLARIFICATION(必须有):统一列出未消除的不确定项(未消除前不得进入 I2)

任务结构(重用 writing-plans,但加入 SSOT/审计/门禁)

plan.md 内必须包含可勾选的任务清单,作为唯一的执行清单与状态来源(- [ ]/- [x])。

每个任务必须包含:

  • 精确文件路径(创建/修改/测试)
  • 可验证验收点(可测试条件)
  • 可执行步骤(命令 + 期望输出/信号)
  • 提交点与最小审计信息(commit/pr/changed_files

任务模板(示例骨架):

## 任务清单(SSOT)

### Task T1: [任务标题]

- [ ] **状态**:未开始 / 进行中 / 完成 / 阻塞(阻塞必须写明取证路径)

**文件:**
- 创建:`exact/path/to/new.file`
- 修改:`exact/path/to/existing.file`(可选:精确到段落/函数)
- 测试:`tests/exact/path/to/test.file`(如适用)

**验收点:**
- [可验证条件 1]
- [可验证条件 2]

**步骤 1:写失败测试(如适用)**
- 修改点:`tests/...`
- Run: `[精确命令]`
- Expected: FAIL(写出期望看到的关键失败信号)

**步骤 2:写最少实现**
- 修改点:`path/to/file`

**步骤 3:运行验证**
- Run: `[精确命令]`
- Expected: PASS(写出期望看到的关键通过信号)

**步骤 4:提交(频繁提交;commit message 必须中文)**
- Commit message: `[一句话说明 why(中文)]`
- 审计信息:`commit=<TBD>``pr=<TBD>``changed_files=<TBD>`

命令书写约定:默认面向 PowerShell;同一行多命令请用 ; 分隔(不要用 &&)。

I1-DoD(门禁:缺一不可)

  • 计划范围与 {FEATURE_DIR}/requirements/*{FEATURE_DIR}/design/* 一致且可追溯
  • 里程碑明确且可验收(每一项有对应产物或可验证标准)
  • 依赖与风险已列出,并有最小验证/缓解动作(含 Owner)
  • 关键验收口径可追溯(至少引用 requirements/prd.mdrequirements/solution.md
  • 影响范围与约束已注入plan.md 包含"影响范围与约束"段落,受影响模块与需遵守的不变量已从 requirements/solution.md#impact-analysis 提取并逐条列出
  • plan.md 内存在“任务清单(SSOT)”,且每个任务包含:文件路径、验收点、最小验证方式、提交点与审计信息
  • 任何不确定项均进入 NEEDS CLARIFICATION,且未消除前不得进入 I2

牢记(高频规则速查)

  • 始终先 spec-context 拿到 FEATURE_DIR=...,失败就停止
  • 始终写精确路径精确命令期望信号
  • 不要把不确定性写成已知;统一进入 NEEDS CLARIFICATION 并阻断 I2
  • DRY、YAGNI、TDD、频繁提交(计划里也要体现提交节奏)

执行交接(写完 plan.md 之后)

保存计划后,本技能不再决定“下一步/执行方式”。统一做法:

  • 宣布:{FEATURE_DIR}/implementation/plan.md 已落盘,且是实现侧唯一 SSOT
  • 提示:立即调用 using-aisdlc 路由下一步(通常路由到 I2:spec-implementation-execute,再到 Finish:finishing-development
  • 若用户明确要求“本会话使用 subagent-driven-development 并行执行”,也应先调用 using-aisdlc 明确路由结论后再开始执行(避免出现第二个路由源)

完成后输出与自动路由(必须执行)

plan.md 落盘后,必须完成以下动作(按顺序,不可省略):

  1. 输出 ROUTER_SUMMARY(YAML 形态,供 Router 决策):
ROUTER_SUMMARY:
  stage: I1
  artifacts:
    - "{FEATURE_DIR}/implementation/plan.md"
  needs_human_review: false
  blocked: false
  block_reason: ""
  notes: "软检查点:plan.md 建议评审;如不触发硬中断 Router 可继续自动推进"
  1. 立即执行 using-aisdlc:将上述 ROUTER_SUMMARY 作为路由输入传递给 using-aisdlc,由 Router 判定下一步并自动推进(无需等待用户说「继续」)。

    • 若 Router 判定可自动续跑:在同一轮对话内继续执行下一步 worker skill(如 I2、Finish 等)
    • 若 Router 触发硬中断:停下并输出阻断原因、需要的输入、候选下一步
  2. 对话输出:在调用 using-aisdlc 前,可简短说明「本阶段产物已落盘,正在调用 using-aisdlc 路由下一步。」

Weekly Installs
47
GitHub Stars
1
First Seen
Feb 25, 2026
Installed on
claude-code47
cursor45
opencode14
github-copilot14
codex14
kimi-cli14