zixun-github/ai-dlc · Archived

finishing-development

用于确认开发已完成,并确保所有测试/检查?

First seen Jul 28, 2026

Installation

$ npx skills add zixun-github/ai-dlc --skill finishing-development

Stronger alternatives

This repository is archived — consider an actively maintained alternative.

Similar popular skills

Related neighbors and high-traction skills in the same topics — useful to compare before installing.

Also in this package

Other skills from zixun-github/ai-dlc · top by installs.

npx skills add zixun-github/ai-dlc

Browse all from zixun-github/ai-dlc

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Repository health

Stars 4
Default branch master
Open issues 1
Status Archived

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 5,958 B
  • docs SUMMARY.md 99 B

History

  1. First seen on skills.sh
  2. First recorded snapshot · 4 installs

SKILL.md

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

概述

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

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

范围与非目标

范围(会做):

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

非目标(不会做):

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

使用方式(开始时宣布)

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

流程

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

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

git status
git diff --stat

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

Task Pack(可选):若本会话已执行 spec-context 且存在非空 TASKPACKDIR,或 {FEATUREDIR}/implementation/tasks/<TASKDIR>/task.md 已声明最小验证,应在报告中显式引用该任务级验证命令与结果,再衔接仓库统一门禁(见 design/aidlctoolingtaskpack_skills.md §3)。

步骤 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-aidlc:将上述 ROUTER_SUMMARY 作为路由输入传递给 using-aidlc,由 Router 判定下一步并自动推进(无需等待用户说「继续」)。

- 若 Router 判定可自动续跑:在同一轮对话内继续执行下一步 worker skill(如 MergeBack、V1 等) - 若 Router 触发硬中断:停下并输出阻断原因、需要的输入、候选下一步

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