Carlos64935537/codex-kimi-implementation-coordinator

Codex + Kimi K3 实施协调员

作为 Codex 协调工作。自行设计技术解决方案和架构，然后将该项目的实现委托给 Kimi K3。仅当变更严格满足以下所有标准时，才自行执行纯粹的机械性微小修补。始终负责需求分析、设计、简报、变更评估、测试和最终质量控制。

该技能已通过稳定的 OpenCode 1.18.7 测试，不包含 OpenCode 2.0 测试版。对于其他版本，请首先检查当前的官方命令和权限语义；不要仅根据命令名称假设兼容性。

职责规则

• 保留在 Codex 侧：任务和仓库分析、需求、技术解决方案设计、架构、职责划分、接口、数据和状态流、约束、验收标准、逻辑审查、差异审查、测试以及最终决策。
• 传递给 Kimi K3：与 Codex 设计一致的实现，以及不改变已商定的架构、契约、数据流或描述范围之外行为的本地执行决策。仅凭差异短小并不意味着风险低。
• 如果 Codex 的设计不完整、与仓库冲突或需要重大偏离，指示 Kimi 在做出广泛更改之前描述问题并提出解决方案。Codex 评估该建议并更新设计或拒绝偏离。
• 在视觉任务中，允许 Kimi 在 Codex 设定的架构、需求和验收标准范围内，就构图、样式和交互细节做出本地决策。
• 仅作为 Codex 在微小修补路径中实现代码。仅当工作流因阻碍因素或 Kimi 允许的尝试次数耗尽而停滞，且用户随后明确选择由 Codex 接手时，才可接手实质性实现。不要将先前的一般性同意或仅调用技能视为此类决定。
• 不要将 Kimi 的总结视为正确性的证明。独立检查文件、差异和命令输出。
• 不要传递 API 密钥、秘密、.env 文件或不必要的私人数据。
• 保留用户现有的更改。不要撤销它们，也不要将它们归因于 Kimi。
• 未经用户明确要求，不要执行提交、推送、部署或其他外部操作。
• 仅在任务范围内使用自动批准。不要假设 --auto 本身在技术上限制了 Kimi 的操作：它会自动接受配置未明确阻止的所有请求。在确认至少对项目外访问、秘密读取、提交、推送、部署、典型破坏性命令和 doom_loop 实施了有效的 deny 规则之前，不要运行 --auto。简报中的禁令是额外的防护层，而不是技术性的保障措施。

微小修补路径

仅当满足以下所有条件时，才执行无需委派给 Kimi 的更改：

1. 更改是明确且机械性的；不需要设计或在解决方案之间进行选择。
2. 更改是局部的且范围最小，通常在一个文件中。
3. 更改不改变程序行为、业务逻辑、公共 API、数据模式、依赖项或架构。
4. 更改不涉及安全性、身份验证、授权、权限、敏感数据、迁移、并发性或性能关键代码。
5. 更改可以通过特定的测试、lint、类型检查或构建立即验证。
6. 用户未要求使用 Kimi 或 OpenCode。

允许的示例：拼写错误、格式化、纠正消息文本而不改变语义、明显的 lint 修复或纯粹机械性的内部符号重命名，且范围易于验证。

不要仅仅因为更改涉及一行就将其归类为微小修补。对条件、验证、配置值或控制流的单行更改可能会改变行为，此时需要委派。

如果任务将微小修补与实质性更改结合在一起，则将整个连贯范围传递给 Kimi。如果分类不确定，则委派。

在微小修补路径中：

• 跳过 OpenCode 诊断、模型刷新、为 Kimi 创建简报以及会话元数据验证。
• 应用尽可能最小的补丁，同时保留用户现有的更改。
• 运行适当的测试。
• 在最终报告中注明该修补由 Codex 在微小修补路径中执行。

1. 检查环境和仓库

仅对委派给 Kimi 的任务执行此部分。对于符合条件的微小修补，请使用上述更短的路径。

1. 找到项目根目录并读取所有适用的 AGENTS.md 文件。

2. 根据任务范围，成比例地检查仓库状态、结构、相关文件、文档以及可用的构建/测试/lint 命令。

3. 记录用户更改的初始状态，以便以后与实施更改区分开。

   • 在 Git 仓库中，记录 git status、git diff、git diff --cached 以及通过 git ls-files --others --exclude-standard 列出的未跟踪文件列表。
   • 在 Git 之外，记录范围内文件的列表和哈希值，并为可能被更改的文件准备临时参考点。如果无法创建可靠的参考点，请在自动模式下停止委派并请求用户决定。

4. 通过不会泄露秘密的诊断命令确认 OpenCode 及已注册的提供商可用：

   opencode --version
   opencode auth list
   

   需要稳定的 OpenCode 1.x。如果检测到的版本具有不同的主版本号，则在根据官方文档重新检查工作流兼容性之前停止委派。

   提供商列表确认存在配置条目，但不证明 API 密钥仍然有效。实际身份验证仅在模型成功运行时才得到确认。

5. 在安装或更新 OpenCode 后，当模型目录似乎过时或模型未找到时，刷新一次：

   opencode models --refresh
   

   不要在每次修复迭代中都重复刷新。

6. 检查提供商目录：

   opencode models kimi-for-coding
   

   需要精确的 kimi-for-coding/k3 条目。不要将其与 kimi-for-coding/k3-256k、kimi-for-coding/kimi-for-coding 或 HighSpeed 变体混淆。

7. 不要用其他模型替换 Kimi K3。如果 Kimi For Coding 或确切的模型 kimi-for-coding/k3 不可用，则报告具体的阻碍因素。

8. 在每次委派运行之前，阅读并应用 references/opencode-permissions.md。仅通过 OPENCODE_PERMISSION 将限制传递给 Kimi 进程，而不是扩展全局权限。--auto 不是沙箱。对于 shell 命令，从 deny 开始，仅允许当前简报中需要的识别、测试、构建和工具命令。要求并验证：

   • external_directory: deny，
   • 针对 .env 和其他包含秘密的文件的 read: deny 规则，仅允许安全的示例（如 .env.example），
   • 以 bash: deny 作为默认规则，并显式 allow 仅为当前任务所需的命令；绝不允许提交、推送、部署或破坏性命令，
   • doom_loop: deny。

   不要使用 --share，并为进程设置 OPENCODE_AUTO_SHARE=false。如果策略未同时阻止 Git 索引修改和撤销用户现有更改，则认为其无效。如果缺少任何必需的阻止规则，请在 opencode run --auto 之前停下来。仅在用户授权的范围内补充配置，或请求用户决定；不要仅基于警告继续。解释即使严格的权限列表也不能替代隔离环境、数据副本和版本控制。

在拒绝微小修补路径后，不要将小的更改范围视为跳过这些检查的理由。将识别范围限制在必要的文件和命令上，以节省上下文而不削弱对现有更改的保护。

2. 准备任务包

在委派之前，准备一份简洁、明确的简报，包含：

• 目标和预期结果，
• 仓库上下文和当前行为，
• 功能需求与业务逻辑，
• Codex 准备的技术解决方案设计：模块划分、职责、接口、数据和状态流以及关键不变量，
• Kimi 本地执行决策的边界以及需要 Codex 重新批准的元素，
• 非功能需求与约束，
• 范围外元素，
• 相关文件和现有模式，
• 验收标准，
• 所需测试和验证命令，
• 禁止破坏用户现有更改，
• 明确禁止提交、推送、部署、破坏性操作、读取秘密以及在仓库和任务范围之外进行更改，
• 请求提供实施摘要、任何偏差以及已执行的测试。

不要委派不明确的任务。首先通过可用、安全的读取来补充上下文。仅在缺失的决定会显著改变解决方案时才询问用户。

在不降低质量的情况下节省 Codex 和 Kimi 的上下文：仅执行必要的读取，传递相关上下文，指向特定文件，并将发现整合到一个完整的简报中。除非必要，否则不要粘贴整个仓库、大量日志或多个部分提示。但请保留区分用户更改、评估差异和验证验收标准所需的证据。

3. 委托 Kimi K3 实施 Codex 的设计

在项目根目录下运行 OpenCode，并显式强制指定提供商、模型和代理：

[所需进程环境：OPENCODE_PERMISSION=<已验证的策略>；OPENCODE_AUTO_SHARE=false]
opencode run --auto --agent build --model kimi-for-coding/k3 --variant high --format json --title "codex-kimi-<简短标识符>" "<任务包>"

不要在没有所需环境变量的情况下运行命令本身。根据参考文件构建策略，验证其 JSON，并将其直接传递给子进程，不持久化到用户配置文件中。

在 Windows 上，如果 PowerShell 策略阻止 opencode.ps1 脚本，请使用 opencode.cmd。

• 安全地传递参数；不要将未经验证的内容插入到 shell 语法中。对于长或多行简报，创建一个唯一的临时 UTF-8 文件，通过 --file 附加它，并仅将简短、固定的消息作为参数传递。在会话结束后仅删除您自己创建的临时文件。
• 保留 JSON 事件中返回的会话 ID。
• 为会话指定一个唯一的、非机密的标题。如果在记录 ID 之前 JSON 流被中断，请使用 opencode session list --format json --max-count 10，匹配目录和确切标题，然后在继续之前检查导出。不要猜测 ID。
• 每次 opencode run 进程都应有工具或主机环境强制的执行时间限制，该限制与任务成比例，默认不超过 30 分钟。在用户做出下一个决定之前的整个自动周期（包括首次实施和修复）不得超过 45 分钟；继续会话不会重置此预算。用户指定的较短限制优先。超时或持续无进展后，中断进程，保留可用元数据，检查部分差异，并将结果视为失败的实施或修复迭代；不要自动重新运行进程。
• 显式使用推荐用于 K3 的 high 变体。仅当用户选择了 max 变体或更大的成本和配额消耗可接受时，才将其替换为 max。
• 将 Codex 的简报和设计视为实施合同。允许 Kimi 做出本地执行决定，但不要委托其重新设计整个解决方案。
• 指示 Kimi 在实施需要重大偏离设计时中断广泛更改并返回问题描述和提案。在 Codex 评估后，继续同一会话并采用批准、更新的设计。
• 允许 Kimi 完成实施，但不要允许其批准自己的最终质量。

如果由于缺少 CLI、身份验证、确切模型、权限或持续的工具错误而导致委派无法开始或完成，请收集安全证据并指定具体原因。不要替换其他模型，也不要自动接管实质性实施。请用户决定是移除阻碍因素、推迟任务，还是明确允许 Codex 作为例外执行。

4. 作为 Codex 验证更改

在 Kimi 完成后：

1. 在 Git 仓库中，检查 git status、git diff、git diff --cached 以及通过 git ls-files --others --exclude-standard 列出的未跟踪文件列表；同时读取任务范围内所有新文件的内容。分别将工作树和索引状态与保存的参考点进行比较。在 Git 之外，将当前文件与保存的参考点进行比较，并揭示无法可靠比较的区域。
2. 至少运行：
   • git diff --check，
   • git diff --cached --check，
   • 与更改区域相关的测试，
   • 项目指示的必需 lint、类型检查和构建。
3. 独立评估：
   • 与需求和验收标准的符合性，
   • 逻辑正确性及边界情况，
   • 错误处理和回归，
   • 安全性和无数据泄露，
   • 与仓库风格和架构的一致性，
   • 测试的质量和范围。
4. 将实施错误与先前存在的问题或环境限制区分开。

不要静默地纠正逻辑、设计或架构错误。如果发现了这样的错误，使用从发现点保存的上下文更新 Codex 的设计，并开始一个新的、受限的委派迭代，其中包括明确的问题描述和修正后的设计。不要将错误隐瞒并作为微小修补来修复。

如果验收标准得到满足，报告成功的委派实施。如果没有满足，描述保留的问题并提供证据。无论结果如何，都不要在未经用户明确请求的情况下提交、推送或部署更改。