finishing-development
开发收尾确认(仅验证,不做合并/清理)
概述
- 目标:确认实现已完整、风险可控,并确保所有测试/检查全绿。
- 产出:一份简短的“完成确认报告”(包含运行的命令与结果、失败摘要或遗留项)。
核心原则: 只做验证 → 失败即停止 → 结果可复现 → 报告可追溯。
范围与非目标
范围(会做):
- 读取项目约定的命令入口(例如
Makefile、Taskfile、package.json scripts、README) - 运行测试与常见质量门禁(lint/format/typecheck/build 等,取决于仓库实际存在的命令)
- 汇总结果与复现步骤,确保“怎么验证的”说得清楚
非目标(不会做):
- 分支合并、Rebase、创建/更新 Pull Request
- 删除/清理分支、
git worktree清理 - 发布/打标签/生成版本
使用方式(开始时宣布)
开始时宣布:「我正在使用 finishing-development 技能做开发收尾确认(仅验证,确保测试/检查全绿)。」
流程
步骤 1:确认当前变更状态(只读)
目标是避免在跑测试前就“带着脏状态/误改文件”继续推进。
git status
git diff --stat
若发现明显不应被带入验证的内容(例如误改配置、生成物、凭据文件),在报告中点名并停止继续(让实现方先修正工作区状态)。
步骤 2:找到并选择项目的标准验证命令
优先使用仓库已经定义的统一入口;不要臆造命令。
常见入口(按优先级从高到低):
make test/make checktask test/task checknpm test/pnpm test/yarn test- 语言/框架默认:
pytest、go test ./...、cargo test
如仓库同时提供多套命令(例如单测、集成、端到端、lint、typecheck、build),以“最严格/最全量”的门禁组合为准(项目通常会在 README 或 CI 配置里说明)。
步骤 3:运行验证(必须全部通过)
至少应覆盖(以仓库实际存在的命令为准):
- 测试:单元/集成/端到端
- 静态检查:lint、格式化、类型检查
- 构建:能成功 build(若项目有 build 步骤)
# 下面仅为示例占位,实际以仓库命令为准
<test command>
<lint/format command>
<typecheck command>
<build command>
步骤 4:失败处理(停止条件)
只要任一检查失败,就停止并输出失败报告;不要进入“完成确认”。
验证未通过(<N> 项失败)。完成确认前必须修复:
[展示失败]
请先修复以上失败项,然后重新执行步骤 1-3 获取全绿结果。
停止。不要继续。
步骤 5:生成“完成确认报告”(全绿时)
在所有验证命令均通过时,输出以下结构的报告(可直接复制到 PR/Issue/日报)。
## 完成确认报告
### 变更摘要
- <1-3 条,说明做了什么与为什么(不要堆细节)>
### 验证结果(全绿)
- <test command>:通过
- <lint/format command>:通过
- <typecheck command>:通过
- <build command>:通过(如适用)
### 复现/验证方式
- 运行环境:<OS/Runtime/版本>
- 关键步骤:<如何复现或如何验证功能点>
### 遗留项(如有)
- <明确列出 remaining TODO / 已知限制 / 后续工作>
常见错误
跳过“最全量”的门禁
- 问题:只跑局部测试,导致 CI/他人环境失败
- 修复:以仓库标准入口或 CI 中的门禁组合为准
用“猜的命令”替代仓库约定
- 问题:跑了不对应的脚本,结论不可信
- 修复:先从
README/CI/脚本入口确定命令,再执行验证
红旗
绝不:
- 在任何验证失败时仍宣称“完成”
- 在未找到仓库标准命令的情况下给出“全绿”结论
始终:
- 记录你实际运行的命令与结果(便于复现)
- 全量门禁通过后再输出“完成确认报告”
集成
被调用于:
- subagent-driven-development - 所有任务完成后,用于最终验证
- spec-execute 类流程的最后一步,用于收尾确认
完成后输出与自动路由(必须执行)
收尾验证完成后(无论全绿或失败),必须完成以下动作(按顺序,不可省略):
- 输出 ROUTER_SUMMARY(YAML 形态,供 Router 决策;按实际结果填写):
全绿通过时:
ROUTER_SUMMARY:
stage: Finish
artifacts: []
needs_human_review: false
blocked: false
block_reason: ""
notes: "完成确认已输出(全绿)"
任一验证失败并停止时:
ROUTER_SUMMARY:
stage: Finish
artifacts: []
needs_human_review: true
blocked: true
block_reason: "<填写失败项与最小复现命令>"
notes: "未通过收尾验证,需先修复失败项再重跑"
-
立即执行
using-aisdlc:将上述ROUTER_SUMMARY作为路由输入传递给 using-aisdlc,由 Router 判定下一步并自动推进(无需等待用户说「继续」)。- 若 Router 判定可自动续跑:在同一轮对话内继续执行下一步 worker skill(如 MergeBack、V1 等)
- 若 Router 触发硬中断:停下并输出阻断原因、需要的输入、候选下一步
-
对话输出:在调用 using-aisdlc 前,可简短说明「本阶段产物已落盘,正在调用 using-aisdlc 路由下一步。」
More from zixun-github/aisdlc
spec-product-prd
Use when 需要在 sdlc-dev 的产品需求 Spec 流程执行 R2,将 requirements/solution.md 转写为可交付、可验收、可测试的 requirements/prd.md,且需要避免猜路径、在缺少 solution.md 时仍继续生成、或用“待确认问题/Open Questions”替代验证清单。
126spec-product-prototype
Use when 需要在 sdlc-dev 的产品需求 Spec 流程执行 R3(原型生成),基于 requirements/prd.md 产出 requirements/prototype.md(任务流+页面结构+ASCII线框+AC映射+走查脚本),并避免缺少上下文/缺少 PRD 仍继续生成、用 Open Questions 代替验证清单、或用非 ASCII 方式导致原型不可追溯与不可评审。
121subagent-driven-development
Use when executing implementation plans with independent tasks in the current session
109spec-product-demo
Use when 需要在 sdlc-dev 的产品需求 Spec 流程执行 R4(基于 requirements/prototype.md 生成可交互 Demo 工程),并需要避免跳过 spec-context、在缺少 prototype.md 或缺少可运行 Demo 工程根目录时仍继续、或自创页面/目录导致不可追溯与无法回流闭环。
109spec-receiving-code-review
Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation
108using-aisdlc
Use when 需要在 sdlc-dev 仓库执行 AI SDLC(Spec Pack)流程、选择/串联需求侧(raw/solution/prd/prototype/demo)与实现侧(plan/execute/finishing)技能,并用门禁避免上下文漂移、写错目录或在压力下跳过关键步骤。
107