--- name: finishing-development description: 用于确认开发已完成,并确保所有测试/检查全部通过 --- # 开发收尾确认(仅验证,不做合并/清理) ## 概述 - **目标**:确认实现已完整、风险可控,并确保所有测试/检查全绿。 - **产出**:一份简短的“完成确认报告”(包含运行的命令与结果、失败摘要或遗留项)。 **核心原则:** 只做验证 → 失败即停止 → 结果可复现 → 报告可追溯。 ## 范围与非目标 **范围(会做):** - 读取项目约定的命令入口(例如 `Makefile`、`Taskfile`、`package.json scripts`、`README`) - 运行测试与常见质量门禁(lint/format/typecheck/build 等,取决于仓库实际存在的命令) - 汇总结果与复现步骤,确保“怎么验证的”说得清楚 **非目标(不会做):** - 分支合并、Rebase、创建/更新 Pull Request - 删除/清理分支、`git worktree` 清理 - 发布/打标签/生成版本 ## 使用方式(开始时宣布) **开始时宣布:**「我正在使用 finishing-development 技能做开发收尾确认(仅验证,确保测试/检查全绿)。」 ## 流程 ### 步骤 1:确认当前变更状态(只读) 目标是避免在跑测试前就“带着脏状态/误改文件”继续推进。 ```bash git status git diff --stat ``` 若发现明显不应被带入验证的内容(例如误改配置、生成物、凭据文件),在报告中**点名**并停止继续(让实现方先修正工作区状态)。 ### 步骤 2:找到并选择项目的标准验证命令 优先使用仓库已经定义的统一入口;不要臆造命令。 常见入口(按优先级从高到低): - `make test` / `make check` - `task test` / `task check` - `npm test` / `pnpm test` / `yarn test` - 语言/框架默认:`pytest`、`go test ./...`、`cargo test` 如仓库同时提供多套命令(例如单测、集成、端到端、lint、typecheck、build),以“最严格/最全量”的门禁组合为准(项目通常会在 README 或 CI 配置里说明)。 ### 步骤 3:运行验证(必须全部通过) 至少应覆盖(以仓库实际存在的命令为准): - **测试**:单元/集成/端到端 - **静态检查**:lint、格式化、类型检查 - **构建**:能成功 build(若项目有 build 步骤) ```bash # 下面仅为示例占位,实际以仓库命令为准 ``` ### 步骤 4:失败处理(停止条件) 只要任一检查失败,就停止并输出失败报告;不要进入“完成确认”。 ``` 验证未通过( 项失败)。完成确认前必须修复: [展示失败] 请先修复以上失败项,然后重新执行步骤 1-3 获取全绿结果。 ``` 停止。不要继续。 ### 步骤 5:生成“完成确认报告”(全绿时) 在所有验证命令均通过时,输出以下结构的报告(可直接复制到 PR/Issue/日报)。 ``` ## 完成确认报告 ### 变更摘要 - <1-3 条,说明做了什么与为什么(不要堆细节)> ### 验证结果(全绿) - :通过 - :通过 - :通过 - :通过(如适用) ### 复现/验证方式 - 运行环境: - 关键步骤:<如何复现或如何验证功能点> ### 遗留项(如有) - <明确列出 remaining TODO / 已知限制 / 后续工作> ``` ## 常见错误 **跳过“最全量”的门禁** - **问题**:只跑局部测试,导致 CI/他人环境失败 - **修复**:以仓库标准入口或 CI 中的门禁组合为准 **用“猜的命令”替代仓库约定** - **问题**:跑了不对应的脚本,结论不可信 - **修复**:先从 `README`/CI/脚本入口确定命令,再执行验证 ## 红旗 **绝不:** - 在任何验证失败时仍宣称“完成” - 在未找到仓库标准命令的情况下给出“全绿”结论 **始终:** - 记录你实际运行的命令与结果(便于复现) - 全量门禁通过后再输出“完成确认报告” ## 集成 **被调用于:** - **subagent-driven-development** - 所有任务完成后,用于最终验证 - **spec-implementation-execute** 类流程的最后一步,用于收尾确认