菜单
SuperClaw Phase 4-L3: 人类最终验收交付。把验证通过的产出交给用户做最终确认。 使用场景：verify 阶段通过。 终态：用户 approve → 完成；用户要调整 → 回 verify/execute；用户丢弃 → 结束。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Delegate coding tasks to Claude Code via ACPX from OpenClaw. Runs Claude Code as root with IS_SANDBOX=1 bypass, full file-write permissions, Opus model support, and persistent named sessions. Use when: (1) The user asks to write, review, or refactor code in a project directory (2) The user wants a persistent coding session ("start a session", "continue working on X") (3) Multi-file code generation or editing is needed (4) The user says "use Claude Code", "code this", "write code for", "build", "implement" (5) Complex coding tasks that benefit from Claude Code's tool-use (file read/write/edit, terminal) Not for: simple one-line edits (use the edit tool directly), reading files (use read tool), non-coding tasks, or tasks that don't need file system access.
SuperClaw AutoDream: 记忆整理持久 agent。定期整理 OpenClaw 记忆文件。 触发条件：距上次 >= 24 小时 AND >= 5 个 session。 由 agent-check.sh 自动触发，也可用户手动 invoke。
SuperClaw Phase 3: 执行。通过 superclaw 让 Claude Code 自治执行 plan。 使用场景：plan 已 approve，选定了执行方式。 终态：执行完成 → 自动触发 verify（通过 hook 或轮询）。
SuperClaw Phase 2: 技术对齐。OpenClaw 与 Claude Code 协商，把 spec 变成可执行的 plan。 使用场景：align 阶段完成、spec 已 approve。 终态：plan approved → invoke execute。
Meta-skill that teaches OpenClaw its role and boundaries in the SuperClaw system. Use at the start of any conversation that might involve coding tasks. Establishes: what you are, what you're not, when to activate the workflow, and how to interact with Claude Code through the superclaw bridge.
SuperClaw Phase 4-L2: OpenClaw 独立验收。不信任 Claude Code 的自我声明，独立跑测试和检查。 使用场景：execute 阶段完成，收到执行报告。 终态：验收通过 → invoke deliver；不通过 → 回 execute 修复。
| name | superclaw-deliver |
| description | SuperClaw Phase 4-L3: 人类最终验收交付。把验证通过的产出交给用户做最终确认。 使用场景：verify 阶段通过。 终态：用户 approve → 完成；用户要调整 → 回 verify/execute；用户丢弃 → 结束。 |
Phase 4-L3 — 人类最终验收
验收通过了，把成果交给用户。说人话，不说技术话。
宣告： "验收通过 ✅，来看看成果。"
以下 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 行
### 注意事项（如果有）
- ...
### 下一步建议（如果有）
- ...
"很好，merge 吧"
收尾流程：
通知飞书：
🎉 SuperClaw 交付完成
Feature: [名称]
状态：已 merge / 已创建 PR
耗时：从 align 到 deliver 共 xx 分钟
"这里不太对，xxx 应该 xxx"
处理：
"算了不要了"
处理：
通知飞书：
🗑️ SuperClaw 任务终止
Feature: [名称]
状态：用户选择丢弃
分支保留：<branch-name>
| 用户选择 | 结果 |
|---|---|
| Approve | 收尾（merge/PR）→ 🎉 完成 |
| 调整 | 回 execute/verify/plan/align（取决于反馈类型） |
| 丢弃 | 清理 → 结束 |
❌ 给用户看技术报告 — 说人话 ❌ 直接 merge 不问用户 — 必须用户 approve ❌ 丢弃时删代码 — 保留分支，万一后面要用 ❌ 用户说"调整"就直接改 — 先判断反馈类型，走正确的路径