codex-collaborator

name	codex-collaborator
description	Codex MCP 协作流程。触发场景：(1) 新功能开发 (2) 重构 (3) 复杂业务逻辑 (4) 代码审查。提供三阶段协作：需求分析→原型获取→审查，强调批判性思考与只读安全。

Codex Collaborator

与 Codex MCP 协作的三阶段流程，确保分析全面、原型安全、审查到位。

核心原则

1. 只读安全：所有调用 sandbox="read-only"，原型只要 unified diff
2. 批判性思考：必须质疑 Codex 回答，尽信书则不如无书
3. SESSION_ID 复用：首次调用后全程复用同一会话

三阶段流程

阶段 1：需求分析

初步分析后，调用 Codex 完善需求：

mcp__codex__codex(
    PROMPT="""
## 需求
[用户需求描述]

## 初步思路
[你的初步分析]

## 请求
1. 完善需求分析，指出遗漏场景
2. 优化实施计划
3. 识别风险
""",
    cd="{{PROJECT_PATH}}",
    sandbox="read-only"
)

→ 记录返回的 SESSION_ID，后续调用复用

阶段 2：原型获取

编码前必须获取原型（严禁实际修改）：

mcp__codex__codex(
    PROMPT="""
基于需求分析，生成代码实现原型。

要求：
- **仅输出 unified diff patch**
- **不要实际创建或修改文件**
- 为关键设计提供说明
""",
    cd="{{PROJECT_PATH}}",
    SESSION_ID="{{SESSION_ID}}",
    sandbox="read-only"
)

→ 以原型为逻辑参考，重写生产级代码

阶段 3：代码审查

编码完成后立即调用审查：

mcp__codex__codex(
    PROMPT="""
## 审查请求
审查代码改动和需求完成度。

## 变更
[git diff 或文件列表]

## 需求
[原始需求]

## 审查维度
1. 功能正确性
2. 需求覆盖
3. 代码质量
4. 潜在风险
""",
    cd="{{PROJECT_PATH}}",
    SESSION_ID="{{SESSION_ID}}",
    sandbox="read-only"
)

→ 质疑审查结论，验证建议可行性

批判性质询

每阶段至少提出 1 个具体质疑：

阶段	质询重点
需求分析	是否遗漏边界场景？技术方案是否可行？
原型获取	设计是否完整？是否有安全漏洞？
代码审查	审查是否深入？建议是否实际可行？

质询技巧：

• 具体而非抽象："网络切换时会如何表现？" 而非 "有问题吗？"
• 挑战假设："你说够了，但是否考虑了 [场景]？"
• 追问细节："性能问题在什么数据量级下出现？"

参考文档

• 工具调用规范：references/api.md