Model or dataset
fengshao1227/ccg-workflow avatar
fengshao1227/ccg-workflow

ccg-workflow: a multi-model workflow engine for Claude Code

多模型协作工作流引擎 — /ccg:go 一个命令,AI 自动分析意图、选择策略、编排 Codex + Gemini + Claude 协作执行

5,916 stars451 forksGoMIT

At a glance

What is it?
CCG turns Claude Code into an orchestrator that dispatches work to Codex, Gemini, Grok and Kimi through a compiled Go bridge. Here is what the repository documents, what it leaves open, and when a single model is the better call.
Who is it for?
Adopt ccg-workflow if you already drive Claude Code daily and want a second and third model reviewing and implementing alongside it without writing your own glue. Skip it if you need a single deterministic pipeline, if your team cannot hold API keys for OpenAI, xAI and Moonshot, or if you want a stable command surface rather than one that moves with releases.
Can I use it commercially?
Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
Is it still maintained?
Yes. The repository last received commits 15 days ago.
What is it written in?
Mainly Go, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on September 30, 2026, and from our analysis. They are not legal advice.

Editorial analysis

The problem ccg-workflow solves, and for whom

Claude Code works well as a single agent, but it is one model with one set of habits. When a task spans backend logic, a frontend surface and a risk review, the same model writes the plan, the code and the approval of its own work. CCG targets that gap. It keeps Claude Code as the lead and sends specific jobs to Codex (OpenAI), Gemini, Grok (xAI), Kimi Code (Moonshot) and Antigravity through a Go binary bridge called codeagent-wrapper. The README describes the intended audience plainly: people who already run Claude Code and want several models in the loop without assembling the plumbing themselves. If you do not use Claude Code, this project has nothing to attach to. The npm package name is ccg-workflow and the binary it exposes is ccg.

How the engine classifies intent and picks a strategy

The README walks through one command end to end. You type a request such as `/ccg:go add JWT authentication to this API`. The engine then reads project context (git status, tech stack, file structure), classifies the request by type, complexity and risk, and selects a strategy. In the documented example the classification is feature, L complexity, backend, high risk, and the chosen strategy is full-collaborate. From there it writes a task file at `.ccg/tasks/add-jwt-auth/task.json`, launches Codex and Gemini in parallel for analysis, produces a plan and stops for your approval before any implementation runs. After approval it spawns Agent Teams builders for parallel implementation.

Two mechanisms deserve attention. The first is the Hook Engine, which the README says injects state every turn so Claude does not lose context, including after compaction. The second is the hard stop between plan and build. That stop is the design decision that makes the tool usable on real repositories: parallel analysis is cheap to discard, while parallel code writing is not. Note what the workflow depends on. The classification step is a model judgement, not a rules file, so the strategy it picks for a given request is not guaranteed to be stable across runs.

Installing ccg-workflow and running /ccg:go for the first time

The README gives a single install command and states it takes about 60 seconds. Node.js 20 or newer is required, per the engines field in package.json.

bash
npx ccg-workflow

The installer is interactive. The README shows it prompting for an API provider at Step 1, and it lists APIMart as one option that exposes an Anthropic-compatible endpoint. You paste a key at that prompt. The installer also offers a choice of profile, with `D. DeepSeek Harness` listed as one option alongside the Claude Code path.

Once installed, the workflow runs from inside Claude Code as a slash command. The README's example is the whole first use:

bash
/ccg:go add JWT authentication to this API

What you should see is a plan, not code. The engine creates `.ccg/tasks/<task-name>/task.json`, runs its parallel analysis, and then halts for approval. Nothing is written to your source tree until you approve the plan. If the plan is wrong, you have lost model time and nothing else.

There is a second install path for the DeepSeek Harness variant, which the README says ships inside the same package:

bash
npx ccg-workflow dsh install
npx ccg-workflow dsh list

The first command installs the role matrix into every profile it finds, or into one profile if you pass `--profile <name>`. The second lists which profiles have it. The README does not document an uninstall command for either path.

The DeepSeek Harness side is a different product

The dsh-ccg component is not a wrapper around the Claude Code flow. It runs the same role matrix natively inside DeepSeek Harness, and the README is explicit that it uses no external CLI and no binary bridge: every hop is a provider API request. Two features exist only on that side. Model panels let one role carry several models, all answering the same brief independently and rendering side by side in the conversation, with no voting and no averaging, so disagreement is the output. Live teammates let `ccg_team` hire a role as a colleague that persists across turns and owns its own files, and a hire that would collide with an existing owner is refused rather than warned about. Every hire requires your approval first. If you are evaluating CCG for the Claude Code path, read the dsh-ccg directory separately; its constraints and its failure modes are not the same, and its source lives under `dsh-ccg/`.

Where ccg-workflow is the wrong tool

The dependency surface is the first real cost. Parallel analysis across Codex and Gemini means credentials for multiple providers, and the README's install flow asks you to pick a provider and paste a key before you reach the first task. A team that can only approve one vendor's API terms cannot use the core feature. The second cost is unpredictability. Strategy selection is described as an analysis step, so the same request can be classified differently on a second run, and a workflow that changes shape between invocations is hard to put behind a CI gate. Third, the project is young and moving. The package version in the repository is 3.6.4, and the most recent release is a preset of pre-built binaries for codeagent-wrapper dated 2026-09-03. A compiled bridge that ships as a downloaded binary is a platform question: if your environment cannot fetch or execute that artifact, the Claude Code path does not start. The README does not document an offline install or a rollback procedure, so treat the installer as a one-way operation until you have verified otherwise. For a solo developer running one model on a small script, the orchestration layer adds prompts, a task directory and an approval gate in exchange for a second opinion that a single strong model often supplies anyway.

How it compares with the Claude Code Workflow Studio approach

The closest thing in the same space is the Claude Code Workflow Studio pattern, which stays inside Claude Code and composes skills, hooks and subagents from one model family. The difference is where the second opinion comes from. Studio-style setups vary the prompt, the persona and the tool access while the underlying model stays the same, so a blind spot in that model persists across every subagent. CCG varies the model itself: Codex, Gemini, Grok and Kimi each answer through codeagent-wrapper, and the README frames the value as parallel analysis and review by different providers. That is a genuine difference in approach, not a configuration detail. It also means CCG inherits the latency, rate limits and pricing of every provider it calls, while a single-family setup inherits one. If your reason for wanting multiple agents is context isolation rather than model diversity, the single-family route is cheaper and simpler. If your reason is that you do not trust one model's review of its own plan, CCG is aimed directly at that.

Licence, maintenance and upgrade cost

The project is MIT licensed, both in the repository and in the package.json license field, which permits commercial use and modification provided the copyright notice and permission notice are retained. That is the extent of what the repository supports; questions about your organisation's policy on model provider terms are separate from the code licence and are not answered here. On maintenance, the last push to the default branch was on 2026-09-03, and the repository is not archived. The release history contains one entry, the codeagent-wrapper binary preset from the same date. Upgrade cost concentrates in two places. The npm package follows semantic versioning at 3.6.4, so the CLI and templates move with releases, and the templates directory ships prompts for Codex, Gemini, Claude, Antigravity, Grok, Kimi and OpenCode, which means a provider prompt change is a package upgrade rather than a local edit. The codeagent-wrapper binary is versioned separately as a preset release, so a wrapper update and a workflow update are two events, not one.

Editorial conclusion

Adopt ccg-workflow if you already drive Claude Code daily and want a second and third model reviewing and implementing alongside it without writing your own glue. Skip it if you need a single deterministic pipeline, if your team cannot hold API keys for OpenAI, xAI and Moonshot, or if you want a stable command surface rather than one that moves with releases. Before committing, verify three things in your own checkout: that Node.js 20 or newer is available, that the codeagent-wrapper binary for your platform downloads and runs, and that the Claude Code plugin installs from .claude-plugin/ into your configuration. The README documents the install path and the /ccg:go loop, but it does not document rollback, so test the install in a throwaway project directory first.

Frequently asked questions

What are the 5 steps of workflow in ccg-workflow?

The README's worked example shows the engine reading project context, classifying the request by type, complexity and risk, selecting a strategy, writing a task file under .ccg/tasks/, and launching parallel analysis before a hard stop for your approval. Implementation by Agent Teams builders follows only after that approval.

What are GitHub workflows used for in this project?

The repository shows a CI workflow badge pointing at .github/workflows/ci.yml, so GitHub Actions is used for continuous integration of the project itself. The multi-model collaboration that CCG provides runs locally through Claude Code, not as a GitHub Actions workflow.

Who can run GitHub workflows for ccg-workflow?

The repository does not document its Actions permissions or who is allowed to trigger its CI workflow. The workflow that CCG itself provides is a local Claude Code slash command, /ccg:go, which any user who installed the package can run.

Official sources

  1. fengshao1227/ccg-workflow on GitHub
  2. License: MIT
  3. Project website
  4. README
  5. Releases
Add this badge to your README

If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.

Add this badge to your README

markdown
[![Hysen Labs](https://hysenlabs.com/badge/fengshao1227-ccg-workflow.svg)](https://hysenlabs.com/projects/fengshao1227-ccg-workflow)