Xukai-YE 方案复核协同（Plan Review Collaboration）
此 skill 在以下任一场景下自动启用：
- 任务具有多步骤依赖关系
- 需要形成完整执行方案而不是简短建议
- 需要实验设计、变量控制、评价指标或风险分析
- 需要工程实现路径、调试顺序、验证方法或故障排查
- 需要在多个候选方案中做权衡
- 任务链路较长，且错误代价较高
核心原则
- 先有完整主方案，再做复核，顺序不能反
- 复核子智能体只能辅助，不拥有最终决定权
- 你必须保留自己的判断，不因复核建议就自动接受
- 最终输出必须逻辑闭环、可落地、可验证
- 当子智能体不可用时，仍需独立完成高质量方案并执行自我复核，不中断任务
- 此 skill 激活即触发 effort-calibration 的规则 9：整个执行过程中 effort 自动不低于 high
执行流程
第一步：独立起草完整主方案
由你独立完成第一版主方案。不允许只给提纲、占位框架或泛泛建议。 方案必须：
- 具备可执行性，能直接作为后续实施基础
- 覆盖所有关键决策点和步骤
- 包含验证方法和潜在风险说明
你仍然是主要决策者，不能把主方案外包给复核子智能体。
第二步：确定相关 Obsidian 记忆路径
路径规范存储在 memory 中，读取：
C:\Users\Administrator\.claude\projects\C--Users-Administrator\memory\reference_obsidian_paths.md
按该文件中的分类，组装 {obsidian_paths}（换行分隔的绝对路径字符串）：
- 始终包含：memory 文件"核心导航层"一节中列出的全部 5 个路径
- 按方案类型追加（参照 memory 文件"按方案类型追加"一节）：
- 实验设计 / 分析 → 实验族笔记 + 对应 run card
- 项目进度 / 路线 → 项目页 + Auto_Status
- 时间线 / 里程碑 → Experiment_Timeline.md
第三步：通过 CLI 调用本地 Codex 审查方案
主方案完成后，使用 Bash 工具调用本地 Codex CLI，角色为审查和补充，而非重写方案或替代你做最终判断。
调用方式（PowerShell，将 {plan_content} 替换为实际方案内容，{obsidian_paths} 替换为第二步确定的路径列表）：
$prompt = @'
你是被 Claude Code 调用的 Codex 子代理。
请在工作目录 F:\ 中对以下方案进行专项复核。你的角色是审查者和补充者，不是重写者。
完成后按结构化格式汇报：
1. Decision
2. Changed Files
3. Patch Summary
4. Tests
5. Known Risks
## 第一阶段：读取 Obsidian 项目记忆（必须先于复核执行）
在开始复核前，请依次读取以下 Obsidian 记忆文件，用于建立项目背景：
{obsidian_paths}
读取要点：
- 从 index.md 了解整体项目结构
- 从实验索引/注册表了解已完成、进行中、失败的实验
- 从 run card 了解具体指标和已验证的结论
- 从项目页了解当前阶段目标和路线
- 只读，不修改任何 Obsidian 文件
读取完成后，基于这些背景对待复核方案进行审查。
## 第二阶段：专项复核
不要重写整个方案，重点从以下六个维度提出具体的改进建议：
1. 遗漏步骤 — 有哪些关键步骤、前置条件或收尾动作被遗漏？
2. 潜在风险 — 有哪些执行风险、失败模式或隐藏依赖未被处理？
3. 不合理假设 — 方案中哪些假设过于乐观或与已知实验结果矛盾？
4. 可执行性 — 当前方案是否足够具体，能直接按步骤执行？
5. 验证检查点 — 是否缺少阶段性验证、回滚策略或停止条件？
6. 备选路径 — 是否存在更稳妥或更高效的替代实现路径？结合记忆中的已知结果判断。
优先指出真正影响执行质量的问题，而不是表面润色。
对每条建议，请标注其紧迫程度：[关键] / [重要] / [可选]。
如果某条建议是基于 Obsidian 记忆中的已知实验结果，请注明来源笔记或 run card。
待复核方案如下：
{plan_content}
'@
$prompt | codex exec `
-C "F:\" `
-m "gpt-5.4" `
--sandbox danger-full-access `
--skip-git-repo-check `
-
若 Codex 登录状态异常，先执行 codex login status，必要时执行 codex login。
第四步：逐条评估复核建议
对复核子智能体的每条建议进行独立评估，判断属于以下哪类：
- 应采纳：能显著提升方案质量、可执行性、稳定性或严谨性
- 可部分采纳：建议方向正确但需调整后融入
- 不应采纳：不能显著提升方案价值，或与上下文/约束冲突
凡是不能显著提升方案的建议，不要纳入最终版本。
第五步：输出统一口吻的最终方案
最终输出必须：
- 表现为你完成复核后的最终判断，而非"初稿 + 复核意见"的拼接
- 除非用户明确要求，不展示内部协同过程
- 主导者始终是你，不让用户感到方案主导权来自外部工具
各类任务的最终方案标准
实验方案类
最终结果必须明确：
- 研究目标与核心假设
- 自变量、因变量、控制变量
- 对照设置
- 实验步骤（含操作细节）
- 数据记录方式与评价指标
- 预期现象
- 潜在失败原因与修正路径
- 结果不理想时的备选方案
工程实现 / 系统搭建类
最终结果必须明确：
- 前置条件与环境依赖
- 实施顺序
- 每一步的预期输出与验证方式
- 关键检查点
- 常见报错来源与排查优先级
- 失败时如何缩小问题范围
研究规划 / 项目路线类
最终结果必须明确：
- 阶段目标与依赖关系
- 阶段产出与里程碑
- 关键风险与资源要求
- 时间顺序与可能分支
- 何时应终止某条路线并切换方案