taichu-acceptance-brief · git:20260627.14df11f · 2026-06-27 · sha256 85c2e18f67d3f391
taichu-acceptance-brief git:20260627.14df11fA
Immutable. This exact content is served forever at /api/v1/blob/85c2e18f67d3f391.
---
name: taichu-acceptance-brief
description: 为太初任务包生成中文验收摘要。Use when 用户要求总结本次任务、整理给 GPT Pro 的验收材料、说明实现了哪些功能、说明网页怎么验证、生成手动验收步骤或复盘执行结果。
---
# 太初验收摘要
## 核心定位
在任务包执行完成后,生成一份给用户和 GPT Pro 使用的中文验收摘要。它关注“实现了什么、怎么验证、验收时看哪里”,不重新讨论需求,不继续改代码。
## 触发方式
- 用户说“总结一下”“生成验收摘要”“给 GPT Pro 的验收材料”“网页怎么验证”“手动触发总结”。
- 任务包已执行完,用户准备把结果复制给 GPT Pro。
- Git 已推送后,需要告诉 GPT Pro 应该从哪个分支、哪些页面、哪些功能点验收。
## 收集信息
生成摘要前,应尽量读取或检查:
- 最近的任务包目标和验收标准。
- `git diff --stat` 或最近一次 commit 的变更范围。
- 已运行的测试、构建、启动和网页验证结果。
- 前端页面、API 端点、配置项、数据流或交互路径。
不得编造未验证结果。若网页未验证,明确写“未完成浏览器验证”,并给出人工验证步骤。
## 任务包理解确认
生成验收摘要前,必须先确认自己理解的是哪一个任务包:
- 优先调用项目内弹窗脚本 `.agents/skills/taichu-acceptance-brief/scripts/confirm-task-package.ps1`。
- 弹窗必须展示任务包名称或编号、核心目标、主要验收标准、关联 commit/branch。
- 用户点击 `Confirm` 后继续生成验收摘要。
- 用户点击 `Needs revision` 后停止生成摘要,并等待用户补充或改正任务包范围。
- 若脚本无法显示窗口,再尝试当前环境提供的 `request_user_input` 或等效弹窗/选项工具。
- 若所有弹窗能力都不可用,改用正文确认块并等待用户回复。
脚本调用示例:
```powershell
powershell -NoProfile -ExecutionPolicy Bypass -File .agents\skills\taichu-acceptance-brief\scripts\confirm-task-package.ps1 `
-TaskPackage "任务包名称或编号" `
-Goal "核心目标" `
-Acceptance "主要验收标准" `
-CodeRef "branch / commit / changed files"
```
脚本会在 stdout 输出 JSON:
```json
{"result":"confirm","taskPackage":"...","goal":"...","acceptance":"...","codeRef":"..."}
```
正文降级格式:
```markdown
我理解你要验收的任务包是:
- 任务包:...
- 目标:...
- 验收标准:...
- 关联代码:...
请确认:回复“确认”后我再生成验收摘要;如果不对,请直接贴正确任务包或修正范围。
```
## 摘要格式
默认输出:
```markdown
# 太初任务验收摘要
更新日期:YYYY-MM-DD
## 本次任务目标
...
## 已实现功能
- ...
## 关键变更文件
- path:说明
## 验证结果
- 自动化验证:...
- 启动验证:...
- 网页验证:...
## 网页手动验收路径
1. 启动项目:...
2. 打开页面:...
3. 操作步骤:...
4. 预期结果:...
## GPT Pro 验收重点
- ...
## 已知风险或未完成项
- ...
```
如果用户只需要聊天回复,不要创建文件;如果用户明确要求生成文件,再按项目文档规则创建。
## 网页验收规则
- 若涉及前端 UI,必须说明入口页面、点击路径、输入数据、预期状态和异常状态。
- 若使用本地服务,说明前端地址和后端地址。
- 若验证依赖环境变量、模型密钥、外部服务或数据库状态,必须列出前置条件。
- 若修改了启动关键文件,说明是否已验证 `start.bat`。
## 禁止事项
- 不要把“代码已改”当成“功能已验收”。
- 不要省略失败命令或未验证项。
- 不要生成新的长期文档,除非用户明确要求。
- 不要在验收摘要阶段继续追加代码改动。
- 不要在未确认任务包范围前生成最终验收摘要。