finishing-development

Development final confirmation (verification only, no merge/cleanup)

Overview

• Goal: Confirm that the implementation is complete, risks are under control, and all tests/checks are green.
• Output: A brief "completion confirmation report" (including the commands run and results, failure summary, or remaining items).

Core principles: Verification only → stop on failure → results reproducible → report traceable.

Scope and non-goals

Scope (will do):

• Read the command entry points agreed upon by the project (for example Makefile、Taskfile、package.json scripts、README）
• Run tests and common quality gates (lint/format/typecheck/build, etc., depending on the commands actually present in the repository)
• Summarize results and reproduction steps to ensure "how it was verified" is clearly stated

Non-goals (will not do):

• Branch merging, rebase, creating/updating pull requests
• Delete/clean up branches,git worktree Cleanup
• Release/tag/version generation

Usage (announce at the start)

Announce at the start:"I am using the finishing-development skill for development final confirmation (verification only, ensuring all tests/checks are green)."

Process

Step 1: Confirm the current change status (read-only)

The goal is to avoid continuing with a dirty state/mistakenly modified files before running tests.

git status
git diff --stat

If you find content that clearly should not be brought into verification (for example, mistakenly modified configuration, generated artifacts, credential files), in the reportname itand stop continuing (have the implementer first fix the workspace state).

Step 2: Find and select the project's standard verification commands

Prefer the unified entry points already defined by the repository; do not invent commands.

Common entry points (in descending 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 (for example unit tests, integration, end-to-end, lint, typecheck, build), use the "strictest/most complete" gate combination as the standard (projects usually explain this in the README or CI configuration).

Step 3: Run verification (all must pass)

At minimum it should cover (based on the commands actually present in the repository):

• Tests: unit/integration/end-to-end
• Static checks: lint, formatting, type checking
• Build: can build successfully (if the project has a build step)

# 下面仅为示例占位，实际以仓库命令为准
<test command>
<lint/format command>
<typecheck command>
<build command>

Step 4: Failure handling (stop condition)

If any check fails, stop and output a failure report; do not proceed to "completion confirmation".

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

[展示失败]

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

Stop. Do not continue.

Step 5: Generate the "completion confirmation report" (when all green)

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

## 完成确认报告

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

### 验证结果（全绿）
- <test command>：通过
- <lint/format command>：通过
- <typecheck command>：通过
- <build command>：通过（如适用）

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

### 遗留项（如有）
- <明确列出 remaining TODO / 已知限制 / 后续工作>

Common errors

Skipping the "most complete" gate

• Problem: Running only partial tests, causing CI/other people's environments to fail
• Fix: Use the repository's standard entry point or the gate combination in CI as the standard

Using "guessed commands" instead of the repository conventions

• Problem: Ran the wrong script, conclusions are unreliable
• Fix: First determine the command from README/CI/script entry point, then run verification

Red flags

Never:

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

Always:

• Record the commands you actually ran and their results (for reproducibility)
• Output the "completion confirmation report" only after the full gate passes

Integration

Invoked in:

• subagent-driven-development - After all tasks are complete, for final verification
• spec-execute The last step of the class of processes, for wrap-up confirmation

Output and automatic routing after completion (mandatory)

After wrap-up verification is complete (whether all green or failed),mustcomplete the following actions (in order, none may be omitted):

1. Output ROUTER_SUMMARY(in YAML form, for Router decision-making; fill in according to actual results):

When all green and passing:

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

When any verification fails and stops:

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

1. Immediately execute using-aisdlc: pass the above ROUTER_SUMMARY as routing input to using-aisdlc, and let the Router determine the next step andautomatically proceed(no need to wait for the user to say "continue").

   • If the Router determines that it can automatically continue: continue executing the next worker skill (such as MergeBack, V1, etc.) within the same conversation turn
   • If the Router triggers a hard interrupt: stop and output the blocking reason, the required input, and candidate next steps

2. Conversation output: Before calling using-aisdlc, you may briefly state "The artifacts of this stage have been written to disk; calling using-aisdlc to route the next step."