/claude：让 Claude 出方案、审阅、给建议或执行

用户是主持人：找谁、问什么、采纳什么，都由用户决定。你（Antigravity）的工作是：准备材料 → 调用 Claude → 核实 → 汇报 → 停下等用户决定。

调用工具（下文简称 peer）：

peer 或 ~/.peer-review/bin/peer

1. 判断任务类型

显式子命令优先：

• /claude exec <指令> -> exec（修改执行，可写）
• /claude review <指令> -> review（只读审阅）
• /claude plan <指令> -> plan（出方案，只读）
• /claude advice <指令> -> advice（结论与建议，只读）

没有显式子命令时，不要自己按关键词判断：先按第 2 节写好任务说明，再运行

peer route --request <任务说明路径>

按它输出的 kind 发起调用（它只看任务说明里的“# 任务”小节，即用户原话）。/codex、/claude 三端都用这同一套规则，否定和只读要求优先，审阅类动词（审阅、检查、看看……）优先于修改类词。

规则：

• 判为 review 但用户其实要修改（route 会提示“已按只读处理”）时，不要自行升级为 exec：告诉用户以 /claude exec ... 开头重新下达，并去掉相冲突的只读或禁止修改要求。
• 判为 image 时：Claude 不能生成图片，告诉用户改用 /codex，或由你（Antigravity）直接生成；如果用户只要示意图或图表，可以用 exec 让 Claude 写 SVG 或绘图代码。
• 拿不准时默认按只读处理。
• “写方案文档”不需要可写模式：Claude 用文字给出方案，由你保存。
• 涉及删除文件、修改系统权限、对外发布、新增付费等高危操作，须在执行前获得用户明确确认。

2. 准备任务说明

用你的文件写入工具新建 <项目目录>/.peer-review/requests/<YYYYMMDD-HHMMSS>-claude.md（类型由第 1 节确定，不必写进文件名）。项目目录就是当前工作区的根目录。内容：

# 任务
（用户原话，原样引用）

## 目标
（一两句话）

## 原始需求与证据
（必须列出用户首轮原话、transcript 路径及行号、底层产物路径或 git diff；缺失或无法访问的材料须逐项注明证据缺口，不得编造引用或以主代理摘要代替原始证据）

## 需要阅读的文件
（按“原始需求与证据 → 待审方案”的顺序列出路径，让对方先核实关键前提，再读方案与推断；不要把大段内容粘贴进来）

## 背景与约束
（每条必须标注【用户原话】/【已核实事实】/【主代理推断/方案假设】之一，一条只写一项事实，禁止多项打包；【已核实事实】必须附证据（“文件:行号”或“命令与输出结果”），未附证据的一律降级标注为【主代理推断/方案假设】；写明相关决定、限制、当前方案文档路径，严禁将假设当事实；没有就省略）

## 交付要求
（审阅重点；图片的保存目录和文件名，例如 images/海报_v001.png；没有就省略）

“背景与约束”示例：【已核实事实】登录接口超时为 30 秒（证据：src/api.py:42）、【已核实事实】测试全部通过（证据：运行 pytest -q，输出“12 passed”）。“已备份且测试通过”这类多项事实要拆成多条，分别附证据。

审阅“刚才的改动”时，按情况把原始改动材料列入“原始需求与证据”，并在“需要阅读的文件”中优先列出：

• 改动是通过 peer 可写调用完成的：写那次调用记录目录里的 changes.md 和 changes.diff。
• 有冻结版：先运行 peer since-freeze <冻结版文件>，写它输出的两个文件路径。
• 其他情况：列出改过的文件；git 项目可以运行 git status --porcelain 和 git diff HEAD --no-ext-diff --no-textconv，并注明哪些是未跟踪的新文件。

上述明确指定的 changes.md、changes.diff 属于底层证据，可读取；不得借此读取该 runs 目录中的历史回复或中间审阅结论。

需要读工作区以外的文件夹时，调用时加 --add-dir <目录>，精确到实际用到的文件夹（可以加多个），不要直接加整个上层大目录。

3. 调用

只读（plan / review / advice）：

peer ask claude <类型> --request <任务说明路径> --cwd <项目目录>

可写（exec）必须带上用户授权的原话：

peer ask claude exec --request <任务说明路径> --cwd <项目目录> --quote "<用户原话>"

然后等待结果：

peer wait <运行编号> --cwd <项目目录>

模型和强度：

• 用户没指定时不要加参数，peer 会自动跟随用户在 Claude 里的设置。
• 用户写了“超高”或“超高强度”作为强度要求（通常在任务开头或结尾，如 /claude 超高 审一下 README）时，加 --effort xhigh，只对这一次生效。这几个字明显是任务内容时不加，拿不准先问用户。
• 用户写了“高”或“高强度”作为强度要求时，加 --effort high（与默认一致），只对这一次生效。
• 用户指定了其他模型或强度（例如“用 opus”“最高强度”“低强度看一下”），加 --model <模型> 和/或 --effort <强度>，只对这一次生效。“快速”“正常”是 Codex 的速度说法，不用来调 Claude 的强度。强度对应：

规则：

• 只通过 peer 调用 Claude，不要直接运行 claude 命令。
• 只读调用默认允许 Claude 联网查资料。用户说“不联网”，或审阅的是外部、不可信的代码时，加 --no-web。
• wait 提示“还在运行”时，再运行一次 wait；不要重新 ask。
• 失败、超时、状态未知、登录方式不一致：如实告诉用户，不要自动重试，由用户决定。
• 若提示触发安全熔断停机锁（退出码 3 或 STOP 提示）：只如实向用户汇报，严禁 Agent 自动删除 STOP 锁文件或尝试绕过，必须由用户本人人工排查确认安全后手动删除恢复。
• 如果刚启动就变成“状态未知”：可用 peer status／peer wait <运行编号> 查看本地状态并检查记录目录，但本地“未知”或进程结束都不能证明原请求未被 Claude 受理；确认未受理后告诉用户，用户同意才加 --foreground 重新发起，否则不重发。
• 一个项目同一时间只能有一个可写调用。

4. 核实与汇报

先读结果文件 response.md（wait 会打印内容和路径）。

• plan：把方案整理进方案文档（见第 5 节），汇报要点和文档路径。
• review / advice：逐条核实，到文件里确认每个问题是否真实存在，标注“已确认 / 存疑 / 不成立（理由）”，不要原样转述未经核实的内容。按严重程度排序汇报。
• exec：汇报改了哪些文件（response.md 里的改动清单）；需要时运行测试验证；指出与任务不符的地方。

每次汇报的第一行写：Claude · <类型> · <只读/可写> · <状态> · 模型 <模型> · 强度 <强度> · 今天第 N 次调用，第二行写：本次用量：<照抄 response.md 里的“本次用量”>。模型、强度和用量都照抄 response.md 开头的写法（包括括号里的来源，例如“跟随 Claude 设置”“本次指定”）；强度把英文换成中文：xhigh 写“超高”，high 写“高”，max 写“最高”，medium 写“中”，low 写“低”（例如 强度 高（跟随 Claude 设置）、强度 超高（本次指定））。服务提供方不是“官方”时也要写出来。 response.md 里有 ⚠️ 提醒（比如实际模型不是官方模型、有权限请求被拒）时，要转告用户。

汇报后停下，等用户决定。不要自己接着修改。

5. 方案流程：出方案 → 审阅 → 汇总 → 勾选 → 修订 → 终审 → 冻结 → 执行

方案文档建议存放在项目下的 docs/ 或 .peer-review/plans/（如 docs/YYYY-MM-DD-<主题>-实施任务.md），同一件事持续更新同一份。“当前方案”指本次对话正在讨论的方案文档。

方案流程包含轻量独立路径与进阶治理路径：

• 轻量独立路径：一方出具方案文档后，用户确认即可直接运行 peer freeze <方案文档> --cwd <项目目录> 计算 SHA-256 内容指纹并生成交接语，安全闭环；
• 进阶治理路径：若另行安装了审阅单技能，勾选和终审两道关口可配合审阅单执行，接收用户真实提交并落档回执。审阅单只在用户提交后生效，草稿、默认选项和代理的转述都不算决定。
• 没有审阅单技能时，第 4、6 步改为在对话里逐条列出，由用户逐条明确答复；把用户答复原话记入方案文档的修订记录，冻结时不带 --review-receipt（独立指纹模式）。

1. 出方案：/codex 或 /claude 给出方案后，写进方案文档，记为 v001。
2. 审阅：用户再用 /codex 或 /claude 审阅当前方案（可以多方、多轮）。审阅方必须先独立核查原始需求、证据与底层产物，核实关键前提，再阅读待审方案与推断；除任务说明明确列出的原始证据文件（如代码文件、changes.diff）外，严禁主动检索、读取任何工作区或全局 .peer-review/runs/ 下的历史回复、过程输出或中间审阅结论（包括同批次其他代理的未定稿 runs）。每次按第 4 节核实后把意见编号列给用户。这一步不改方案。
3. 汇总：用户说“汇总”（或要求勾选、拍板）时，把本轮各方意见合并去重，统一编号 S01、S02……，每条写明来源（如 Codex#3、Claude#1）和核实结论（已确认／存疑／不成立及理由）。各来源须标明意见是“独立得出”还是“引用他方”；引用须注明原始来源，不计入交叉共识，无法确认独立性的意见也不得计为独立共识。汇总前逐份核对审阅回复末尾的“独立性自述”：凡自述引用了他方结论、缺少自述，或该次调用记录 stdout.log 里的工具调用读取过他方 runs 的，该来源的意见一律标注“无法确认独立性”，不计入交叉共识。核实为“不成立”的也列出，由用户决定，不替用户删。
4. 勾选（审阅单①）：用审阅单技能（没有时按上面的对话方式）把 S 条目做成审阅单：默认待决定、不预选；用户逐条选“采纳／PASS（本轮不采纳）／修改”。回执落档后再进入下一步。
5. 修订：只按回执里“采纳”的条目修订方案。在文档末尾的“修订记录”里写明：第几版、审阅单编号（review_id）、采纳了哪几条（S 编号及来源）、改了哪里。“修改”的条目按用户意见改写后，只把改动的条目再走一次第 4 步。还有待决定或修改未定稿的条目时，不进入终审。
6. 终审（审阅单②）：所有条目都已“采纳”或“PASS”、修订完成后，再用审阅单技能（没有时在对话里）发一张终审单，只有一条：修订后方案文档的路径、版本、全文 SHA-256，以及采纳清单和 PASS 清单。终审条目正文必须写出方案全文 SHA-256（64 位），peer 冻结时靠它核对版本。用户提交“终审通过”后才能冻结；终审选“修改”就回到第 5 步。终审只固定方案（decision_only），不等于授权执行。勾选和终审必须分两步：用户在第 4 步说“直接冻结”也不跳过终审，告诉用户还差终审。
7. 冻结：终审回执落档后，先计算方案文档的 SHA-256，必须和终审单里的一致；不一致说明终审后文档又被改过，停下并重新终审。一致后运行：

   peer freeze <方案文档> --cwd <项目目录> [--review-receipt <终审回执事务目录>] [--quote "<用户终审原话>"]

   （注：若配合审阅单工作流，可指定 --review-receipt 核验终审回执；未配置时直接以独立指纹固化模式运行）。通过后它会生成冻结版副本、内容指纹、项目快照和交接语。
8. 解冻：用户说“解冻”或要求修改已冻结的方案时，修改原方案文档；改完回到第 6 步重新终审，再冻结（生成下一版冻结版）。新增或改变的建议走第 3、4 步。
9. 执行：用户说“按冻结版执行”时，先运行 peer verify <冻结版文件>，不一致就停下告诉用户。
   • 默认由你（Antigravity）执行。
   • 用户说“让 Codex 执行”或“让 Claude 执行”：用对应的 peer ask <codex|claude> exec ... --quote "<用户原话>"，任务说明里写明冻结版路径和内容指纹。
   • 用户要自己到 Codex 或 Claude 程序里执行：把交接语给用户。
   • 执行中必须偏离冻结版时，停下问用户。执行范围以冻结版为限；冻结版里没写的删除、发布、付费操作不做。
10. 执行后：把执行记录（改了哪些文件、做了哪些验证、遗留问题）追加到原方案文档末尾。用户要审阅时，用 peer since-freeze <冻结版文件> 生成改动清单，再回到第 2 步。

6. 其他

• 遵守宿主环境的全局规则与项目规则。
• 不要把密钥、令牌、账号信息写进任务说明。
• 自检：peer doctor。登录方式变了并且用户确认后：peer doctor --approve。
• 查看调用记录：peer status --cwd <项目目录>；今天的调用次数和用量合计：peer stats。