Unified Claude Code plugin — OMC agent orchestration + CCG multi-model collaboration + gudaspec RPI philosophy
npx claudepluginhub 1molchuan/oh-my-ccg统一 Claude Code 插件 — OMC 编排 + CCG 多模型协作 + gudaspec RPI 工作流哲学
1molchuan
个人集成配置插件 — RPI 工作流状态机 + OMC 代理继承 + CCG 双模型路由
oh-my-ccg 是一个个人集成配置插件——把 ccg-workflow 的双模型调用模式、oh-my-claudecode 的代理系统、openspec 的约束驱动哲学，整合进一个统一的 Claude Code 插件配置中。
它不是三者的替代品，而是站在它们肩膀上的聚合层。如果你已经在用 OMC 或 CCG，oh-my-ccg 主要带来的是 RPI 阶段状态机（跨 /clear 持久化）和把三套工作流统一进一个插件的便利性。
/clear 持久化npm i -g @openai/codexnpm i -g @google/gemini-cli# 克隆仓库
git clone https://github.com/1molchuan/oh-my-ccg.git
cd oh-my-ccg
# 安装依赖
npm install
# 编译
npm run build
在你的项目中配置 .mcp.json，引用 oh-my-ccg 的三个 MCP 服务器：
{
"mcpServers": {
"oh-my-ccg-tools": { "command": "node", "args": ["/path/to/oh-my-ccg/bridge/mcp-server.cjs"] },
"oh-my-ccg-codex": { "command": "node", "args": ["/path/to/oh-my-ccg/bridge/codex-server.cjs"] },
"oh-my-ccg-gemini": { "command": "node", "args": ["/path/to/oh-my-ccg/bridge/gemini-server.cjs"] }
}
}
/oh-my-ccg:init
| 命令 | 阶段 | 说明 |
|---|---|---|
/oh-my-ccg:research "需求描述" | Research | 需求 → 可验证约束集 |
/oh-my-ccg:plan | Plan | 约束 → 零决策可执行计划 |
/oh-my-ccg:impl | Implement | 按计划机械执行 |
/oh-my-ccg:review | Review | 双模型交叉验证（随时可用） |
状态持久化：每个阶段的输出存储在
.oh-my-ccg/state/rpi-state.json，/clear后可自动恢复。
/oh-my-ccg:research "添加用户认证功能"
/clear
/oh-my-ccg:plan
/clear
/oh-my-ccg:impl
/oh-my-ccg:review
oh-my-ccg 是三者的聚合层，主要增量是有状态的 RPI 多阶段工程流程。以下是准确的能力对比：
OMC 拥有完整的代理系统（notepad 会话记忆、project-memory 跨会话记忆、原生 MCP ask_codex/ask_gemini），可以完成几乎所有任务——但它没有强制 Research→Plan→Implement 的顺序约束，也没有跨 /clear 的工程级阶段进度记录。
CCG 以 bash 包装器形式提供双模型调用，同样没有多阶段工作流状态。
oh-my-ccg 引入了形式化的阶段状态机：
init → research → plan → impl → review
每个阶段强制完成后才能进入下一阶段，状态持久化在 .oh-my-ccg/state/rpi-state.json。执行 /clear 清空上下文后，下一个命令会自动从断点恢复，不会丢失任何工程进度。
OMC 和 CCG 都是"给我做 X"式的任务驱动模型——你描述目标，模型直接实现。OMC 的各代理可以手动组织约束提取流程，但没有在工作流层面强制要求。
oh-my-ccg 在任务开始前强制经过一个约束提取阶段：
需求描述
↓ (research phase)
约束集（Hard / Soft）
├── C001 [Hard] 认证 token 必须在 30 分钟后过期
│ 验证标准：单元测试 auth/token.test.ts
├── C002 [Hard] 密码必须通过 bcrypt 哈希存储
│ 验证标准：代码审查无明文存储
└── C003 [Soft] 支持第三方 OAuth 登录（优先级低）
每个约束都有分类（Hard/Soft）和可验证标准。这些约束在整个 plan 和 impl 阶段作为验收条件，防止实现偏离需求。
OMC 的 planner 代理可以产出执行方向和任务列表，手动使用时也可做到详细规划；但没有在工作流层面强制要求"歧义消除后才能进入实现"。 CCG 没有专门的 plan 阶段，直接进入双模型原型生成。
oh-my-ccg 的 plan 阶段有一个强制歧义消除审计：
任务拆解完成
↓
歧义检查（AmbiguityAudit）：
"认证中间件应放在哪个层？" → 必须在此阶段解答，不能留到实现时
"token 刷新策略是什么？" → 必须在此阶段确定
↓
零歧义 → 生成 tasks.md（每个任务指定精确文件、函数、测试）
↓
进入 impl（纯机械执行，无设计决策）
计划阶段还会同步提取 PBT（属性测试）不变量，每个约束对应可自动化验证的属性。
CCG 的外部模型输出（Codex/Gemini 生成的代码）需要人工判断是否采用。 OMC 的 executor 直接实现，不借助外部模型原型。
oh-my-ccg 建立了明确的两阶段代码生成流程：
外部模型（Codex/Gemini）生成原型
↓ （原型仅作参考，禁止直接应用）
executor 代理重写 → 生产级代码
↓
side-effect review（强制副作用检查）：
- 变更是否超出任务范围？
- 是否影响未预期的依赖？
- 接口是否与预期一致？
外部模型的输出是有价值的设计参考，但最终代码必须由 Claude executor 按照项目约定重写，确保风格一致性和质量可控。
CCG 的双模型审查结果是两份独立报告，合并方式由用户自行判断。
oh-my-ccg 的 review 阶段有一条自动升级规则：
Codex 发现: [Warning] 缺少输入验证 at auth/login.ts:42
Gemini 发现: [Warning] 缺少输入验证 at auth/login.ts:42
↓
合并后自动升级: [Critical] 缺少输入验证（双模型交叉确认）
被两个模型同时报告的问题自动升级为 Critical 级别，反映了该问题具有更高的客观置信度。
| 能力 | OMC | CCG | oh-my-ccg |
|---|---|---|---|
| 多代理编排 | ✅ 完整（20+ 角色） | ❌ | ✅ 继承 OMC（15 角色子集） |
| 双模型并行调用 | ✅ 原生 MCP | ✅ bash 包装 | ✅ 原生 MCP（同 OMC） |
| RPI 阶段状态机 | ❌ | ❌ | ✅ 新增 |
| 约束集提取（Markdown 工作流约定） | ❌（可手动） | ❌ | ✅ 新增 |
| 零决策计划强制（Markdown 工作流约定） | ❌（可手动） | ❌ | ✅ 新增 |
| 原型-重写分离 | ❌ | ⚠️ 建议 | ✅ 强制（Markdown 约定） |
| PBT 属性追踪 | ❌ | ❌ | ✅ 新增（Markdown 约定） |
| 交叉验证严重性升级 | ❌ | ❌ | ✅ 新增（Markdown 约定） |
/clear 后阶段恢复 | ❌ | ❌ | ✅ 新增 |
| 无外部模型降级运行 | ✅ | ❌ | ✅ 继承 |
注：标注"Markdown 工作流约定"的能力是通过 CLAUDE.md 提示词约定实现的，依赖 Claude 遵循指示，不是代码层面的强制约束。
坦白说，这个项目还远不完美：