| name | superclaw-deliver |
| description | SuperClaw Phase 4-L3: 人类最终验收交付。把验证通过的产出交给用户做最终确认。
使用场景：verify 阶段通过。
终态：用户 approve → 完成；用户要调整 → 回 verify/execute；用户丢弃 → 结束。
|
SuperClaw: Deliver
Phase 4-L3 — 人类最终验收
验收通过了，把成果交给用户。说人话，不说技术话。
宣告： "验收通过 ✅，来看看成果。"
前置条件
- verify 阶段已 PASS / PASS_WITH_NOTES
- 验证报告已生成
Board Integration
以下 board 操作仅在 .superclaw/board/ 存在时执行。没有 board 时 skill 正常运行。
| 时机 | Board 操作 | 命令 |
|---|
| 用户 approve | 从 reviewing 移到 done | board-move.sh {task} reviewing done "用户 approved" |
| 用户要调整 | 移回 executing 或 planned | board-move.sh {task} reviewing {target} "用户要调整: ..." |
| 用户丢弃 | 从 reviewing 移到 done | board-move.sh {task} reviewing done "用户丢弃" |
流程
收到验证报告（PASS）
→ 生成交付摘要（面向用户）
→ 展示给用户
→ 用户选择：
├─ "approve" → 收尾（commit/merge/PR）
├─ "调整" → 收集反馈 → 回 execute 或 verify
└─ "丢弃" → 清理 → 结束
交付摘要
给用户看的是产品层面的总结，不是技术报告：
## ✅ [Feature Name] 完成
### 做了什么
用一两段话描述，用用户能懂的语言。
不要说"实现了 UserService 类"，要说"现在可以用邮箱注册和登录了"。
### 关键变化
- 新增了 xxx 功能
- 改进了 xxx 体验
- 修复了 xxx 问题
### 数据
- 新增 N 个文件，修改 N 个文件
- 测试：XX 个通过
- 代码变更：+XXX / -XXX 行
### 注意事项（如果有）
- ...
### 下一步建议（如果有）
- ...
用户选择
Approve → 收尾
"很好，merge 吧"
收尾流程：
- 确认所有测试通过
- 如果是 feature branch → 提示 merge 方式（merge/squash/rebase）
- 如果需要 PR → 生成 PR 描述
- 清理临时文件（.superclaw/ 状态文件）
通知飞书：
🎉 SuperClaw 交付完成
Feature: [名称]
状态：已 merge / 已创建 PR
耗时：从 align 到 deliver 共 xx 分钟
调整 → 收集反馈
"这里不太对，xxx 应该 xxx"
处理：
- 记录用户反馈
- 判断反馈类型：
- 小改动（UI 调整、文案修改）→ 直接发给 CC 修 → 重新 verify
- 功能方向问题 → 回到 plan 重新规划
- 需求变更 → 回到 align 重新对齐
- 告诉用户走哪个路径
丢弃 → 清理
"算了不要了"
处理：
- 确认："确定丢弃？代码改动会保留在分支上但不会 merge。"
- 用户确认后：
- 不删除代码（保留分支作为参考）
- 清理 .superclaw/ 状态文件
- 记录到日志
通知飞书：
🗑️ SuperClaw 任务终止
Feature: [名称]
状态：用户选择丢弃
分支保留：<branch-name>
终态
| 用户选择 | 结果 |
|---|
| Approve | 收尾（merge/PR）→ 🎉 完成 |
| 调整 | 回 execute/verify/plan/align（取决于反馈类型） |
| 丢弃 | 清理 → 结束 |
Anti-Pattern
❌ 给用户看技术报告 — 说人话
❌ 直接 merge 不问用户 — 必须用户 approve
❌ 丢弃时删代码 — 保留分支，万一后面要用
❌ 用户说"调整"就直接改 — 先判断反馈类型，走正确的路径
