# Finishing Development

> Finishing Development

- Skill: `zixun-github/finishing-development` (Agent Skill)
- Install (CLI): `npx skillmds@latest add zixun-github/finishing-development`
- Raw SKILL.md: https://api.skillmd.com/api/skills/zixun-github/finishing-development/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: zixun-github (https://skillmd.com/u/zixun-github)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/zixun-github/finishing-development

---


# 开发收尾确认（仅验证，不做合并/清理）

## 概述

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

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

## 范围与非目标

**范围（会做）：**
- 读取项目约定的命令入口（例如 `Makefile`、`Taskfile`、`package.json scripts`、`README`）
- 运行测试与常见质量门禁（lint/format/typecheck/build 等，取决于仓库实际存在的命令）
- 汇总结果与复现步骤，确保“怎么验证的”说得清楚

**非目标（不会做）：**
- 分支合并、Rebase、创建/更新 Pull Request
- 删除/清理分支、`git worktree` 清理
- 发布/打标签/生成版本

## 使用方式（开始时宣布）

**开始时宣布：**「我正在使用 finishing-development 技能做开发收尾确认（仅验证，确保测试/检查全绿）。」

## 流程

### 步骤 1：确认当前变更状态（只读）

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

```bash
git status
git diff --stat
```

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

**Task Pack（可选）**：若本会话已执行 `spec-context` 且存在非空 `TASK_PACK_DIR`，或 `{FEATURE_DIR}/implementation/tasks/<TASK_DIR>/task.md` 已声明**最小验证**，应在报告中**显式引用**该任务级验证命令与结果，再衔接仓库统一门禁（见 `design/aidlc_tooling_taskpack_skills.md` §3）。

### 步骤 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
# 下面仅为示例占位，实际以仓库命令为准
<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 决策；按实际结果填写）：

**全绿通过时：**

```yaml
ROUTER_SUMMARY:
  stage: Finish
  artifacts: []
  needs_human_review: false
  blocked: false
  block_reason: ""
  notes: "完成确认已输出（全绿）"
```

**任一验证失败并停止时：**

```yaml
ROUTER_SUMMARY:
  stage: Finish
  artifacts: []
  needs_human_review: true
  blocked: true
  block_reason: "<填写失败项与最小复现命令>"
  notes: "未通过收尾验证，需先修复失败项再重跑"
```

2. **立即执行 `using-aidlc`**：将上述 `ROUTER_SUMMARY` 作为路由输入传递给 using-aidlc，由 Router 判定下一步并**自动推进**（无需等待用户说「继续」）。  
   - 若 Router 判定可自动续跑：在同一轮对话内继续执行下一步 worker skill（如 MergeBack、V1 等）
   - 若 Router 触发硬中断：停下并输出阻断原因、需要的输入、候选下一步

3. **对话输出**：在调用 using-aidlc 前，可简短说明「本阶段产物已落盘，正在调用 using-aidlc 路由下一步。」