oh-my-ccg

oh-my-ccg

个人集成配置插件 — RPI 工作流状态机 + OMC 代理继承 + CCG 双模型路由

oh-my-ccg 是一个个人集成配置插件——把 ccg-workflow 的双模型调用模式、oh-my-claudecode 的代理系统、openspec 的约束驱动哲学，整合进一个统一的 Claude Code 插件配置中。

它不是三者的替代品，而是站在它们肩膀上的聚合层。如果你已经在用 OMC 或 CCG，oh-my-ccg 主要带来的是 RPI 阶段状态机（跨 /clear 持久化）和把三套工作流统一进一个插件的便利性。

---

✨ 特性

• RPI 工作流 — Research → Plan → Implement，状态跨 /clear 持久化
• 15 个专业代理 — 继承自 OMC 代理系统（20+ 角色的子集）
• 多模型路由建议 — 按任务域建议路由（后端→Codex，前端→Gemini）——最终路由由 Claude 判断执行
• 3 个 MCP 服务器 — oh-my-ccg-tools / oh-my-ccg-codex / oh-my-ccg-gemini
• 8 个生命周期钩子 — SessionStart / UserPromptSubmit / PreToolUse 等
• 16 个可调用技能 — autopilot / ralph / team / pipeline 等编排模式
• Team / Ralph / Autopilot — 并行团队、持久循环、全自动 RPI 周期

---

🚀 快速开始

前置要求

• Claude Code（claude-code CLI）
• Node.js >= 18
• （可选）Codex CLI：npm i -g @openai/codex
• （可选）Gemini CLI：npm 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

---

📖 核心工作流（RPI）

命令	阶段	说明
/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

---

🔀 与 OMC / CCG 的核心差异

oh-my-ccg 是三者的聚合层，主要增量是有状态的 RPI 多阶段工程流程。以下是准确的能力对比：

1. 有状态的 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 清空上下文后，下一个命令会自动从断点恢复，不会丢失任何工程进度。

---

2. 约束驱动而非任务驱动

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 阶段作为验收条件，防止实现偏离需求。

---

3. 零决策计划原则

OMC 的 planner 代理可以产出执行方向和任务列表，手动使用时也可做到详细规划；但没有在工作流层面强制要求"歧义消除后才能进入实现"。 CCG 没有专门的 plan 阶段，直接进入双模型原型生成。

oh-my-ccg 的 plan 阶段有一个强制歧义消除审计：

任务拆解完成
    ↓
歧义检查（AmbiguityAudit）：
  "认证中间件应放在哪个层？" → 必须在此阶段解答，不能留到实现时
  "token 刷新策略是什么？" → 必须在此阶段确定
    ↓
零歧义 → 生成 tasks.md（每个任务指定精确文件、函数、测试）
    ↓
进入 impl（纯机械执行，无设计决策）

计划阶段还会同步提取 PBT（属性测试）不变量，每个约束对应可自动化验证的属性。

---

4. 原型-重写分离模式

CCG 的外部模型输出（Codex/Gemini 生成的代码）需要人工判断是否采用。 OMC 的 executor 直接实现，不借助外部模型原型。

oh-my-ccg 建立了明确的两阶段代码生成流程：

外部模型（Codex/Gemini）生成原型
    ↓  （原型仅作参考，禁止直接应用）
executor 代理重写 → 生产级代码
    ↓
side-effect review（强制副作用检查）：
  - 变更是否超出任务范围？
  - 是否影响未预期的依赖？
  - 接口是否与预期一致？

外部模型的输出是有价值的设计参考，但最终代码必须由 Claude executor 按照项目约定重写，确保风格一致性和质量可控。

---

5. 交叉验证严重性升级

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 遵循指示，不是代码层面的强制约束。

---

⚠️ 局限性与不足

坦白说，这个项目还远不完美：