Dong-skills — 智能体协作工作流
- Codex
- OpenCode
- Grok CLI
- Claude Code
- Agent Workflows
- Code Review
- Verification
一个公开的个人 skills 仓库，为 Claude Code、Codex、OpenCode 与 Grok 整理智能体协作纪律，包含受控范围、审查关卡与明确验证。它保留 Claude-Codex 互评、Codex-OpenCode 与 Codex-Grok 工作流作为已命名的可复用操作规则。
一眼看懂
角色 独立作者 — 工作流设计、安全边界、审查协议与文档
问题
多智能体 coding work 如果范围、隐私、审查权限和验证责任不明确，很容易失控。第二个 agent 只有在拿到受控任务包，且其结论被真实 repo 验证时才有价值。
解法
我把反复使用中的协作实践整理成明确 skill workflow：先定义任务包，限制第二个 agent 能看什么、做什么，设置审查关卡，并在交付前逐条对照 repo 验证。
成果
公开 skills 仓库 · 覆盖 Claude Code、Codex、OpenCode 与 Grok 的协作工作流 · skills 已对齐 plugin contract v2
我的工作
- Claude-Codex 互评工作流：让一个 coding agent 审查另一个 agent 的 diff，但不转移最终责任
- Codex-OpenCode 工作流：包含能力检查、受控委派、review / adversarial-review 入口和结果验证
- OpenCode collaboration guidance：任务文本放在 prompt、文件作为附件、避开隐藏 runtime context，并要求 Codex 验证每个发现
- Codex-Grok 协作工作流：使用 grok-plugin-codex 做能力检查、受控 run、review / rescue / adversarial review、session export、background jobs，并保留 Codex 最终验证
- OpenCode 与 Grok collaboration skills 于 2026-07 对齐 plugin contract v2，同时保留三条已命名工作流
技术证据
- 操作安全规则：第二 agent 不执行破坏性命令、不 commit / push、不读 private runtime paths，也不直接采信未验证结论
- 可复用任务包结构：目标、验收标准、精确 scope、约束、验证命令、期望输出和风险
- 审查纪律：OpenCode 与 Grok 可以提供第二轮 review 或 adversarial review，但 Codex 仍负责读 diff、跑测试并决定是否交付
为什么做这个仓库
这个仓库把反复使用中的本地实践整理成明确操作规则。Codex 请 Claude Code、OpenCode 或 Grok 协助时，真正有价值的不是让另一个模型多说几句，而是让协作有边界、可检查、可验证。
这些 skills 定义了什么能委派、什么保持私有、谁负责 git，以及第二 agent 的意见在被采纳前必须通过哪些检查。
第二 agents 是 reviewers，不是 owners
Codex-OpenCode 工作流把 OpenCode 定位为第二 reviewer 或受控 helper。流程先做能力检查，再发送明确任务包，禁止 commit 和破坏性命令，最后要求 Codex 对照真实文件与测试输出验证每个发现。
Codex-Grok 工作流把同一规则套到 grok-plugin-codex：先检查 Grok 是否可用，只委派一个受控任务或 review，检查完整结果，并让 Codex 继续负责文件、测试、git 与最终判断。