finishing-development

用于确认开发已完成,并确保所有测试/检查全部通过

Safety Notice

This listing is imported from skills.sh public index metadata. Review upstream SKILL.md and repository scripts before running.

Copy this and send it to your AI assistant to learn

Install skill "finishing-development" with this command: npx skills add zixun-github/aisdlc/zixun-github-aisdlc-finishing-development

开发收尾确认(仅验证,不做合并/清理)

概述

  • 目标:确认实现已完整、风险可控,并确保所有测试/检查全绿。
  • 产出:一份简短的“完成确认报告”(包含运行的命令与结果、失败摘要或遗留项)。

核心原则: 只做验证 → 失败即停止 → 结果可复现 → 报告可追溯。

范围与非目标

范围(会做):

  • 读取项目约定的命令入口(例如 MakefileTaskfilepackage.json scriptsREADME
  • 运行测试与常见质量门禁(lint/format/typecheck/build 等,取决于仓库实际存在的命令)
  • 汇总结果与复现步骤,确保“怎么验证的”说得清楚

非目标(不会做):

  • 分支合并、Rebase、创建/更新 Pull Request
  • 删除/清理分支、git worktree 清理
  • 发布/打标签/生成版本

使用方式(开始时宣布)

开始时宣布:「我正在使用 finishing-development 技能做开发收尾确认(仅验证,确保测试/检查全绿)。」

流程

步骤 1:确认当前变更状态(只读)

目标是避免在跑测试前就“带着脏状态/误改文件”继续推进。

git status
git diff --stat

若发现明显不应被带入验证的内容(例如误改配置、生成物、凭据文件),在报告中点名并停止继续(让实现方先修正工作区状态)。

步骤 2:找到并选择项目的标准验证命令

优先使用仓库已经定义的统一入口;不要臆造命令。

常见入口(按优先级从高到低):

  • make test / make check
  • task test / task check
  • npm test / pnpm test / yarn test
  • 语言/框架默认:pytestgo 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 类流程的最后一步,用于收尾确认

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

收尾验证完成后(无论全绿或失败),必须完成以下动作(按顺序,不可省略):

  1. 输出 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: "未通过收尾验证,需先修复失败项再重跑"
  1. 立即执行 using-aisdlc:将上述 ROUTER_SUMMARY 作为路由输入传递给 using-aisdlc,由 Router 判定下一步并自动推进(无需等待用户说「继续」)。

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

Source Transparency

This detail page is rendered from real SKILL.md content. Trust labels are metadata-based hints, not a safety guarantee.

Related Skills

Related by shared tags or category signals.

Coding

spec-product-prd

No summary provided by upstream source.

Repository SourceNeeds Review
Coding

spec-product-demo

No summary provided by upstream source.

Repository SourceNeeds Review
Coding

spec-product-prototype

No summary provided by upstream source.

Repository SourceNeeds Review
Coding

subagent-driven-development

No summary provided by upstream source.

Repository SourceNeeds Review