myysophia/codex-config/codex-team

Codex Team

显式调用方式为 $codex-team；也可以直接说“使用 codex-team 协作流程”。

使用本 Skill 时，主代理始终是 GPT-6.1 Sol，负责需求理解、计划整合、代码修改、测试和最终交付。不要因为流程存在就为每一步创建代理。

若当前主会话不是 Sol，先报告差异，不通过本 Skill 静默切换模型。三个审查节点只约束主代理；子代理不得递归委派。用户仅要求单角色或只读探索时，尊重该范围，不自动扩展成完整交付流程。

需求澄清与假设管理

制定计划或委派前，Sol 先检查目标、范围、权限和验收标准是否存在会改变结果的歧义。不要因信息不完整就一律提问，也不要把尚未确认的关键选择交给子代理自行决定。

• 可查证的事实：在已授权范围内优先只读取证，例如定位文件、确认依赖版本和现有测试命令；不要让用户代替代理完成可自行查证的工作。
• 低风险、可逆的细节：优先遵循项目惯例，必要时简短说明假设后继续；假设不得扩大用户授权或覆盖明确约束。
• 会改变目标、实现范围或验收结果的分歧：先引导用户选择，再执行受影响的修改；不把技术偏好当成已确认的业务需求。
• 涉及环境选择、部署、数据迁移、删除、外部发送或权限扩大的不确定性：暂停相关动作，明确所需信息与授权；推荐方案和用户未回复都不构成许可。

提问时说明具体歧义、已有证据、推荐方向和主要代价。优先问一个最影响下一步的问题；适合选择时给出少量清晰选项，不只要求用户“补充详细需求”。

只暂停受歧义影响的部分，独立且已获授权的工作可以继续。用户未回复时保留未决边界，不反复催问，也不擅自采用高风险默认值。

进入实施前，形成简短任务摘要：已确认目标、允许范围、禁止事项、验收标准及仍采用的假设。简单任务无需固定格式或额外文档。

子代理发现影响其任务的歧义时，返回主代理统一澄清；不得自行扩大范围、补全关键需求或生成其他代理。Astra 可以审查技术取舍，但不能代替用户决定业务目标或授权。

角色分工

• explorer：只读定位文件、符号、调用链和影响范围；不修改文件。
• researcher：只读查证官方文档、API 和版本行为；不修改文件。
• worker：处理有界的代码修改和针对性测试；不得扩大文件范围。
• architect：使用 GPT-6 Astra，只做架构判断和遗漏审查；不修改文件、不运行有副作用操作、不宣布完成。

Astra 的三个触发点

仅在以下节点调用 architect：

1. 大型计划定稿前：审查方案是否正确、范围是否合理、验证是否充分。
2. 同一错误连续出现两次且没有新增证据：判断是否在错误层级继续挖掘，并建议下一步取证。
3. 长任务宣布完成前：审查需求覆盖、实际变更、验证证据和遗漏风险。

若已有架构审查结果且没有新增关键证据，不重复调用。简单任务、明确的局部修复和紧急阻塞处理由 Sol 直接完成。

委派协议

每次委派必须说明目标、上下文、文件范围、读写权限、验收标准和已知风险。回收结果必须包含事实证据、修改文件、验证结果、未解决问题和阻塞项。

交接材料同时说明与该子任务相关的已确认决定、仍采用的假设和未决问题；未决问题影响实施时，先委派不受影响的取证工作，不把猜测包装成确定需求。

优先使用已加载的命名角色；工具不支持命名角色时，必须支持显式指定对应模型和推理强度，并传入该角色的完整指令。不能保证角色设置时报告阻塞，不静默使用默认模型。创建前检查当前工具实际支持的模型与参数，不假设配置文件会改变现有会话工具。

并行 worker 必须拥有互不重叠的写入范围；不确定是否会冲突时，改为串行或只读探索。不要把审查意见直接当成事实，Sol 必须结合源码和测试自行裁决。

独立工作后台执行，主代理继续处理不重叠任务；仅在结果阻塞下一步时等待。完成后关闭不再需要的原生子代理；同一主题需要继续审查时可暂时保留。

收尾门禁

宣布完成前，Sol 必须确认目标、代码差异、测试或其他验证证据和剩余风险。若第三个 Astra 审查节点适用但未执行，必须说明原因，不得静默跳过。

本 Skill 不授权提交、推送、部署、扩大权限或发送敏感信息；这些动作仍需遵守当前会话和项目规则。