菜单
SuperClaw Phase 4-L2: OpenClaw 独立验收。不信任 Claude Code 的自我声明，独立跑测试和检查。 使用场景：execute 阶段完成，收到执行报告。 终态：验收通过 → invoke deliver；不通过 → 回 execute 修复。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | superclaw-verify |
| description | SuperClaw Phase 4-L2: OpenClaw 独立验收。不信任 Claude Code 的自我声明，独立跑测试和检查。 使用场景：execute 阶段完成，收到执行报告。 终态：验收通过 → invoke deliver；不通过 → 回 execute 修复。 |
Phase 4-L2 — OpenClaw 独立验收
Claude Code 说"做完了"不算数。OpenClaw 自己验，通过了才算。
宣告： "我在用 superclaw:verify 独立验收 Claude Code 的产出。不信任它的自我声明，我要自己跑测试。"
不信任 Claude Code 的执行报告。 所有验证必须独立执行，不依赖 CC 的输出声明。以下 board 操作仅在
.superclaw/board/存在时执行。没有 board 时 skill 正常运行。
| 时机 | Board 操作 | 命令 |
|---|---|---|
| 开始验收 | 读 reviewing 列任务 | 读任务文件 + spec + verify 命令 |
| 验收不通过 | 移回 executing | board-move.sh {task} reviewing executing "验收不通过: ..." |
| 验收通过 | 保持在 reviewing（等 deliver） | 更新 history |
验收开始前，先运行 SuperClaw 自身的 lint 检查：
.superclaw/lint/run-all.sh # 如果存在
lint 失败不阻塞验收，但会在报告中标记。
| 级别 | 谁做 | 做什么 | 时机 |
|---|---|---|---|
| L1 | Claude Code（已完成） | TDD + self-review + 双阶段 review | execute 阶段内 |
| L2 | OpenClaw（本 skill） | 独立测试 + spec 合规 + E2E | execute 完成后 |
| L3 | 人类（deliver skill） | 最终确认 | verify 通过后 |
收到执行报告
→ 读取 spec（验收标准）+ plan（task 列表）+ concerns
→ L2 验收：
├─ 1. 跑现有测试（单元 + 集成）
├─ 2. Spec acceptance criteria 逐条检查
├─ 3. Concerns 重点检查
├─ 4. 端到端验证（最大可能验证）
└─ 5. 代码质量抽检
→ 生成验证报告
→ 全部通过？
├─ yes → invoke deliver
└─ no → 问题分类
├─ 需求与实现不一致 → 路径 A：send + systematic-debugging → CC 修 → 完整重新 verify
└─ 需求本身有问题 → 路径 B：飞书通知用户 → 等用户判断
# 在项目目录执行测试命令
# 具体命令从 plan.md 或项目配置中获取
cd <project-dir>
# 检测项目类型并跑测试
# Node.js: npm test / yarn test / pnpm test
# Python: pytest / python -m pytest
# Go: go test ./...
# Rust: cargo test
判断：
对照 spec.md 的 Acceptance Criteria，逐条验证：
## Acceptance Criteria 验证
- [x] 标准 1 — 验证方式：跑了 xxx 测试 / 读了 xxx 代码
- [ ] 标准 2 — ❌ 未满足，原因：...
- [x] 标准 3 — 验证方式：...
方式：
Claude Code 执行报告中的 DONE_WITH_CONCERNS 和 concerns 列表，逐条检查：
## Concerns 检查
- Concern 1: "Task 3 的错误处理可能不够完善"
→ 检查结果：确实缺少 xxx 场景的处理 → 标记为需修复
- Concern 2: "Task 7 的性能可能有问题"
→ 检查结果：可接受，不影响功能 → 记录但不阻塞
| 项目类型 | 检测方式 | 验证工具 |
|---|---|---|
| Web 前端/SPA | package.json 有 react/vue/next/vite 等 | 浏览器自动化（agent-browser / Puppeteer） |
| 静态 HTML | index.html 存在，无构建步骤 | 浏览器直接打开文件 |
| API 服务 | 有 routes/endpoints 定义 | curl / HTTP 请求 |
| CLI 工具 | 有 bin 字段或可执行脚本 | 命令行调用 |
| 纯库 | 只有 src，无入口 | 跳过 E2E，但必须在报告中说明依赖 Step 1-2 |
1. 启动
- 静态文件：浏览器打开 file://<absolute-path>
- 需要构建：npm run build && npx serve dist
- 需要 dev server：npm run dev
2. 截图初始状态
- 截图保存到 /tmp/verify-screenshots/
- 用多模态模型分析截图，对照 spec 的视觉要求逐条确认
- 示例 prompt："这是一个 Mario 游戏的初始画面吗？
能看到：(1) 马里奥精灵 (2) 地面 (3) 问号砖块 (4) 管道？"
3. 模拟用户交互
- 从 spec 的功能列表推导出关键交互路径
- 每个交互：操作 → 等待 → 截图 → 多模态分析
- 示例：按右方向键 → 等 1 秒 → 截图 → "马里奥有没有向右移动？"
4. 检查控制台
- 捕获所有 console.error 和 JS 异常
- 任何未捕获异常 = 标记为问题
5. 汇总
- 所有截图路径 + 多模态分析结果 → 写入 E2E 验证报告
1. 启动服务（从 plan 或项目配置获取启动命令）
2. 对照 spec 的 API 列表，逐个端点验证：
- 正常请求 → 检查状态码 + 响应体结构
- 边界输入 → 检查错误处理
- 认证（如果有）→ 检查无 token 时拒绝
3. 停止服务
1. 对照 spec 的命令列表，逐个验证：
- 正常输入 → 检查输出 + exit code
- 无参数 / 错误参数 → 检查 help 输出和错误提示
- 边界输入 → 检查不崩溃
2. 如果 CLI 有文件输出 → 检查输出文件内容
不需要逐行审查（L1 的 code-quality-reviewer 已经做了），但抽检：
# SuperClaw 验证报告
**Feature:** [名称]
**Date:** YYYY-MM-DD HH:MM
**Verdict:** ✅ PASS / ❌ FAIL / ⚠️ PASS_WITH_NOTES
## 测试结果
- 单元测试：XX/XX 通过
- 集成测试：XX/XX 通过
- E2E 测试：XX/XX 通过（或 N/A）
## E2E 验证详情
- 项目类型：[Web 前端 / API / CLI / 纯库]
- 验证工具：[agent-browser / Puppeteer / curl / CLI]
- 截图数量：N 张（保存在 /tmp/verify-screenshots/）
### 截图验证
| # | 操作 | 截图 | 多模态分析结果 | 判定 |
|---|---|---|---|---|
| 1 | 打开初始页面 | screenshot-01.png | 看到马里奥、地面、砖块 | ✅ |
| 2 | 按右方向键 | screenshot-02.png | 马里奥向右移动了约 3 格 | ✅ |
| 3 | 按跳跃键 | screenshot-03.png | 马里奥未跳起 | ❌ |
### 控制台检查
- JS 异常：0 / N 个
- 详情：...
### 返工记录（如果有）
| 次数 | 问题 | 路径 | 结果 |
|---|---|---|---|
| 1 | 跳跃不工作 | A（CC 修） | 修复后通过 |
## Acceptance Criteria
- [x] 标准 1 — ✅
- [ ] 标准 2 — ❌ 原因：...
...
## Concerns 检查
- Concern 1 — ✅ 已确认无问题 / ❌ 需修复
...
## 代码质量
- 新增文件数：N
- 修改文件数：N
- 测试覆盖：简述
- 注意事项：...
## 问题列表（如果有）
### Critical（必须修）
- ...
### Important（应该修）
- ...
### Minor（可以后面修）
- ...
## 结论
[PASS → 进入 deliver / FAIL → 需要修复]
当 OpenClaw 能明确判断"spec 说的是 X，但实现做的是 Y"时，直接让 CC 修。
superclaw send superclaw-<feature> --prompt "
验收发现以下问题，请使用 superpowers:systematic-debugging 修复：
## 问题 1
[截图路径（如果有）]
预期：spec 说 XXX
实际：截图/测试显示 YYY
## 问题 2
...
修复后跑测试确认。
"
关键规则：
send 复用同一��� sessionsuperpowers:systematic-debugging，不让 CC 自由发挥当 OpenClaw 不确定是实现错了还是 spec 不够清晰时，不猜，找人。
通知用户（飞书）：
⚠️ SuperClaw 验收发现问题，需要你判断：
[截图（如果有）]
spec 说：'...'
实际效���：'...'
我不确定是实现错了还是需求不够清晰。
请判断：
1. 实现是对的，继续验收
2. 实现有问题，我让 CC 改
3. spec 需要补充，回 align 阶段
判断标准：
验收完成时通知：
✅ SuperClaw 验收通过
📊 测试：全部通过
📋 Acceptance Criteria：10/10
⚠️ 注意事项：2 条（非阻塞）
准备进入最终交付...
或：
❌ SuperClaw 验收未通过
📊 测试：2 个失败
📋 Acceptance Criteria：8/10
🔴 Critical 问题：1 个
需要你的决定...
superclaw:deliver❌ 信任 CC 说的"测试全过了" — 自己跑 ❌ 只检查修复的部分 — 每次 verify 都走完整流程 ❌ 把技术问题直接甩给用户 — OpenClaw 先判断能不能自动修 ❌ 验收报告含糊其辞 — 每条标准都要有明确的 ✅/❌ ❌ 看了代码觉得应该没问题就放行 — 必须实际验证（跑测试/截图/调用） ❌ 让 CC 自由发挥修 bug — 必须指定 superpowers:systematic-debugging ❌ 不确定是 spec 还是实现的问题时猜 — 找人 ❌ 返工后只检查修复的部分 — 每次都完整 verify ❌ E2E 验证时不截图 — 截图是证据，写进报告
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 1: 产品对齐。将用户模糊需求转化为结构化 spec。 使用场景：用户提出开发需求（一句话、一段描述、一个链接都行）。 唯一终态：用户 approve spec → invoke plan。 借鉴 gstack office-hours 的深度对齐方法论，包括 Forcing Questions、 Premise Challenge、Anti-Sycophancy、Spec Review Loop。