finishing-development

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

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

Development Completion Confirmation (Verification Only, No Merging/Cleanup)

概述

Overview

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

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

Objective: Confirm that the implementation is complete, risks are controllable, and all tests/checks are passing (all green).
Output: A brief "Completion Confirmation Report" (including executed commands and results, failure summaries or remaining items).

Core Principles: Only perform verification → Stop immediately on failure → Results are reproducible → Reports are traceable.

范围与非目标

Scope and Non-Objectives

范围（会做）：

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

非目标（不会做）：

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

Scope (Will Do):

Read the project's agreed command entry points (e.g.,
```
Makefile
```
,
```
Taskfile
```
,
```
package.json scripts
```
,
```
README
```
)
Run tests and common quality gates (lint/format/typecheck/build, etc., depending on the actual commands present in the repository)
Summarize results and reproduction steps to clearly explain "how verification was performed"

Non-Objectives (Will Not Do):

Branch merging, Rebase, creating/updating Pull Requests
Deleting/cleaning up branches,
```
git worktree
```
cleanup
Releasing/tagging/generating versions

使用方式（开始时宣布）

Usage (Announce at Start)

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

Announce at Start: "I am using the finishing-development skill to perform development completion confirmation (verification only, ensuring all tests/checks are green)."

流程

Process

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

Step 1: Confirm Current Change Status (Read-Only)

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

bash

git status
git diff --stat

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

The goal is to avoid proceeding with "dirty states/accidental file modifications" before running tests.

bash

git status
git diff --stat

If content that clearly should not be included in verification is found (e.g., accidental configuration changes, build artifacts, credential files), explicitly mention it in the report and stop (ask the implementer to fix the workspace state first).

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

Step 2: Locate and Select the Project's Standard Verification Commands

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

常见入口（按优先级从高到低）：

```
make test
```
/
```
make check
```
```
task test
```
/
```
task check
```
```
npm test
```
/
```
pnpm test
```
/
```
yarn test
```
语言/框架默认：
```
pytest
```
、
```
go test ./...
```
、
```
cargo test
```

如仓库同时提供多套命令（例如单测、集成、端到端、lint、typecheck、build），以“最严格/最全量”的门禁组合为准（项目通常会在 README 或 CI 配置里说明）。

Prioritize using the unified entry points already defined in the repository; do not invent commands.

Common entry points (in descending order of priority):

```
make test
```
/
```
make check
```
```
task test
```
/
```
task check
```
```
npm test
```
/
```
pnpm test
```
/
```
yarn test
```
Language/framework defaults:
```
pytest
```
,
```
go test ./...
```
,
```
cargo test
```

If the repository provides multiple sets of commands (e.g., unit tests, integration tests, end-to-end tests, lint, typecheck, build), use the "strictest/most comprehensive" combination of quality gates (projects usually specify this in the README or CI configuration).

步骤 3：运行验证（必须全部通过）

Step 3: Run Verification (All Must Pass)

至少应覆盖（以仓库实际存在的命令为准）：

测试：单元/集成/端到端
静态检查：lint、格式化、类型检查
构建：能成功 build（若项目有 build 步骤）

bash

undefined

At minimum, cover (based on actual commands present in the repository):

Tests: Unit/Integration/End-to-End
Static Checks: Lint, Formatting, Type Checking
Build: Successful build (if the project has a build step)

bash

undefined

下面仅为示例占位，实际以仓库命令为准

The following are only placeholders; use actual repository commands

<test command> <lint/format command> <typecheck command> <build command> ```

步骤 4：失败处理（停止条件）

Step 4: Failure Handling (Stop Condition)

只要任一检查失败，就停止并输出失败报告；不要进入“完成确认”。

验证未通过（<N> 项失败）。完成确认前必须修复：

[展示失败]

请先修复以上失败项，然后重新执行步骤 1-3 获取全绿结果。

停止。不要继续。

Stop immediately and output a failure report if any check fails; do not proceed to "completion confirmation".

Verification failed (<N> items failed). Fixes are required before completion confirmation:

[Display failures]

Please fix the above failed items first, then re-execute Steps 1-3 to get all green results.

Stop. Do not proceed.

步骤 5：生成“完成确认报告”（全绿时）

Step 5: Generate "Completion Confirmation Report" (When All Green)

在所有验证命令均通过时，输出以下结构的报告（可直接复制到 PR/Issue/日报）。

undefined

When all verification commands pass, output a report with the following structure (can be directly copied to PR/Issue/Daily Report).

undefined

完成确认报告

Completion Confirmation Report

变更摘要

Change Summary

<1-3 条，说明做了什么与为什么（不要堆细节）>

<1-3 bullet points, explaining what was done and why (no excessive details)>

验证结果（全绿）

Verification Results (All Green)

<test command>：通过
<lint/format command>：通过
<typecheck command>：通过
<build command>：通过（如适用）

<test command>: Passed
<lint/format command>: Passed
<typecheck command>: Passed
<build command>: Passed (if applicable)

复现/验证方式

Reproduction/Verification Method

运行环境：<OS/Runtime/版本>
关键步骤：<如何复现或如何验证功能点>

Runtime Environment: <OS/Runtime/Version>
Key Steps: <How to reproduce or verify the feature>

遗留项（如有）

Remaining Items (If Any)

<明确列出 remaining TODO / 已知限制 / 后续工作>

undefined

<Clearly list remaining TODOs / known limitations / follow-up work>

undefined

常见错误

Common Mistakes

跳过“最全量”的门禁

问题：只跑局部测试，导致 CI/他人环境失败
修复：以仓库标准入口或 CI 中的门禁组合为准

用“猜的命令”替代仓库约定

问题：跑了不对应的脚本，结论不可信
修复：先从
```
README
```
/CI/脚本入口确定命令，再执行验证

Skipping the "Most Comprehensive" Quality Gates

Problem: Only running partial tests leads to failures in CI/other environments
Fix: Use the repository's standard entry points or the combination of quality gates in CI

Replacing Repository Agreements with "Guessed" Commands

Problem: Running incorrect scripts leads to untrustworthy conclusions
Fix: First determine the commands from
```
README
```
/CI/script entry points, then execute verification

红旗

Red Flags

绝不：

在任何验证失败时仍宣称“完成”
在未找到仓库标准命令的情况下给出“全绿”结论

始终：

记录你实际运行的命令与结果（便于复现）
全量门禁通过后再输出“完成确认报告”

Never:

Claim "completion" when any verification fails
Give an "all green" conclusion without finding the repository's standard commands

Always:

Record the actual commands you ran and their results (for reproducibility)
Output the "Completion Confirmation Report" only after all quality gates pass

集成

Integration

被调用于：

subagent-driven-development - 所有任务完成后，用于最终验证
spec-implementation-execute 类流程的最后一步，用于收尾确认

Called by:

subagent-driven-development - Used for final verification after all tasks are completed
Final step of spec-implementation-execute type processes, used for completion confirmation",