DingCode Orchestrator

DingCode (dingcode) is a Rust-based terminal orchestrator for Claude Code, Codex, and Gemini CLI. It now behaves like a Claude-style chat session: the user talks to one terminal, and DingCode coordinates the three tools through a Superpower workflow instead of treating every request as a one-shot software generator.

The product combines two proven open-source ideas:

• Kim Orchestrator: staged Claude/Codex/Gemini CLI handoffs.
• Superpowers: disciplined planning, task ledgers, tests, review, verification, and completion evidence.

Product Shape

dingcode
  -> open a persistent dingcode> chat in the current directory
  -> auto-detect Codex, Claude Code, and Gemini CLI
  -> keep all three readiness states visible
  -> accept normal terminal messages from the user
  -> answer normal messages through the selected default chat CLI
  -> only start implementation when the user enters /goal <project goal>
  -> for each /goal turn, ask Claude to align requirements, frontend design, options, acceptance, and tasks
  -> let the user answer the alignment questions in the terminal
  -> hand Codex only the implementation/demo/test tasks based on Claude's design brief
  -> ask Gemini to review against Claude's design, the plan, task ledger, demo URL, and acceptance contract
  -> run self-check and QA, then return to dingcode> for the next human correction

The goal is not to build a full IDE. The goal is a closed-loop local workbench that makes AI coding less vague: requirements get narrowed, tasks get quantified, agents work in their own lanes, and humans can intervene between turns.

Upstream References

These projects are design references, not vendored runtime code:

• Kim Orchestrator: staged Claude/Codex/Gemini CLI orchestration patterns.
• Superpowers: planning, TDD, review, and verification workflow patterns.

These repositories are references, not code we copy wholesale into the harness.

Main Command

dingcode
dingcode "<chat message>"
dingcode --project PATH
dingcode --project PATH "/goal <project goal>"
dingcode --continue PATH
dingcode --once --project PATH "<single-run task>"

Supported options:

--project PATH    choose a chat workspace; default is current directory
--continue PATH   continue an existing workspace in chat
--chat            force the interactive orchestrator
--once            run one Superpower turn and exit
--name NAME       optional run label; does not choose the project path
--plain           disable rich terminal UI
--workflow MODE   default superpower; use single for one-agent mode
--agent AGENT     builder for single mode; supports auto, codex, claude, gemini, noop
--model MODEL     pass a concrete model name to the selected CLI
--no-test         skip self_check.sh execution
--review          run Gemini review in single mode
--qa              run frontend QA in single mode; superpower does this automatically
--agent-terminals open per-agent Terminal log windows; default on macOS
--no-agent-terminals disable per-agent Terminal log windows
--no-interactive exit immediately after writing the summary
--fix-rounds N    repair rounds, default 1
-v, --version     show DingCode version
--help            show help

Run Locally

From this repository:

./bin/dingcode --help
./bin/dingcode
./bin/dingcode --project ./work/stopwatch-demo
./bin/dingcode --project ./work/stopwatch-demo "/goal 先做一个智能闹钟 demo"
./bin/dingcode --once --project ./work/stopwatch-demo --agent noop --no-interactive "smoke test"

bin/dingcode runs the Rust implementation. If target/debug/dingcode is missing or older than src/main.rs, it compiles the binary with rustc first.

Install And CLI Detection

DingCode is a single Rust binary and is intended to run on macOS, Linux, and Windows. The recommended distribution layer is npm because it gives every platform the same CLI entry:

npm install -g dingcode
dingcode

The npm package exposes dingcode through a small Node launcher. In source installs it compiles src/main.rs with rustc on first run and then reuses the platform binary under target/npm/. Release packages can later swap this for prebuilt per-platform binaries. For local repo development, ./bin/dingcode still works on Unix-like systems.

Requirements for source npm installs:

• Node.js 18+
• Rust toolchain with rustc
• At least one AI CLI on PATH for normal work: codex, claude, or gemini

At startup DingCode clearly displays local install and login readiness for all three AI CLIs before creating a project:

Codex CLI     installed / login status
Claude Code   installed / login status
Gemini CLI    installed / availability status

At least one of them must be installed and locally usable unless --agent noop is used for smoke tests. If none are available, DingCode stops before creating the project and asks the user to install or log in first. Full Superpower orchestration runs when both Claude Code and Codex are ready; Gemini review is used when Gemini is ready. If only one AI CLI is ready, DingCode automatically uses that one tool as Planner, Builder, and Reviewer.

By default this runs the best available flow: Claude+Codex enable the staged Superpower workflow, Gemini adds review, and a single available CLI can still build a runnable project. Use --continue to keep iterating an existing project instead of starting from a blank workspace.

For a fast harness-only smoke test that does not call Codex:

./bin/dingcode --once --agent noop --project ./work/smoke "make a smoke test project"

Verify

rustc --edition=2021 src/main.rs -o target/debug/dingcode
./bin/dingcode --once --workflow single --agent noop --project ./work/smoke "make a smoke test project"
./bin/dingcode --once --workflow single --agent noop --no-agent-terminals --continue ./work/smoke "add one small improvement"

The active implementation is Rust-only. Legacy Python package code and compatibility tests were removed so there is one runtime to reason about.

Continue A Project

DingCode workspaces are meant to be living conversations. Normal text is just chat and will not implement a project. Type /goal <目标> when you want the Superpower workflow to start or continue implementation. If the result is not good enough, continue the same directory and start another goal turn:

./bin/dingcode --continue ./work/smoke

Each goal turn keeps the existing project files, writes run-specific prompt/summary/review files, reuses HARNESS_TASKS.tsv as the current iteration ledger, and produces a fresh log under logs/. Claude plans the delta and owns frontend design, Codex modifies the existing code to implement that design, Gemini reviews the new result, and Harness verifies again.

The chat prompt stays open until /exit. Use /model to view or change the default chat CLI for normal conversation, for example /model claude, /model codex, /model gemini, or /model auto. Use --once --no-interactive for scripts and smoke tests.

Live Output

Long-running agent commands stream useful progress to the terminal while preserving full raw output in logs/.

The default terminal view is a pinned orchestration map, not a flat grid of agents:

• Harness is shown first as the Rust runtime that owns workspace setup, prompts, handoffs, verification, interrupt reports, and repair loops.
• The work is then shown as a vertical pipeline: 1 PLAN / Claude Code -> 2 BUILD / Codex -> 3 REVIEW / Gemini CLI -> 4 VERIFY / Harness.
• Each stage shows role, state, input artifact, output artifact, current activity, elapsed time, and recent trace.
• Codex, Claude Code, and Gemini CLI readiness is detected at startup and remains pinned on the main control deck for the whole run, including installed/missing and logged-in/ready state.
• Handoffs are displayed as a trail under the pipeline so the execution order stays clear.
• A quantified task ledger is displayed under the pipeline. Claude writes HARNESS_TASKS.tsv with fine-grained tasks, owners, statuses, titles, and acceptance evidence; agents update the board by printing CLAIM TASK <id> and DONE TASK <id>.

The main terminal is a pinned control deck. It refreshes in place, shows the hierarchy, current owner, task progress bars, handoffs, and the pixel puppy location, but it does not scroll raw worker logs. Claude and Codex are also prompted to emit structured progress lines such as PROGRESS: PLAN, PROGRESS: CODE, PROGRESS: TEST, and PROGRESS: FIX; worker terminals render these with distinct symbols so planning, coding, testing, and repair work are easy to scan. Execution is task-ledger driven by default: Claude must write HARNESS_TASKS.tsv, Harness normalizes owners, sends Codex only the codex implementation queue, sends Gemini the gemini review queue, and keeps harness verification tasks for self-check/QA/summary. Codex claims and completes quantified tasks one by one, which keeps the build anchored to small verifiable units instead of a single vague request. Execution is also acceptance-first by default: Claude must write HARNESS_ACCEPTANCE.md with Given/When/Then scenarios, automated checks, manual QA checks, edge cases, and regressions. Codex is instructed to encode tests and self_check.sh before or alongside feature code, and Gemini reviews the result against that acceptance contract. Execution is demo-first in chat turns: Claude writes HARNESS_QUESTIONNAIRE.md, HARNESS_QUESTIONNAIRE.tsv, HARNESS_STYLE_OPTIONS.md, and HARNESS_DEMO_PLAN.md; when Claude Code has a frontend/design plugin available, the workflow expects Claude to use it for the design brief, layout, component states, responsive behavior, and style directions. Harness renders questionnaire, visual style choice, and demo confirmation before Codex continues. Style options are turned into HARNESS_STYLE_OPTIONS_FORM.html with visual cards/previews so the user is not choosing from prose alone. Every demo must be a visible web experience with a working local or LAN URL through HARNESS_DEMO_URL.md; screenshots, source files, terminal output, or prose alone are not enough.

Codex is expected to implement Claude's frontend design rather than invent a competing visual system. Gemini checks this explicitly during review. When output is captured by Codex, CI, or a redirected file, the same board events are printed as compact [dingcode] status lines so the terminal stays readable.

By default on macOS, Harness opens one worker Terminal per active agent. These windows tail files such as logs/<run>.claude.log, logs/<run>.codex.log, logs/<run>.gemini.log, and logs/<run>.harness.log; each worker log is formatted with a colored title, table-like rows, progress bars, heartbeats, task markers, and an end summary. The pixel puppy appears in the active worker terminal and disappears after that worker finishes. Use --no-agent-terminals for quiet runs.

Press Ctrl+C to interrupt. Partial files are kept, and Harness writes an INTERRUPTED summary with the project and log paths.

Frontend QA And Repair Loop

For frontend projects, --qa writes HARNESS_QA.md and checks common generated-app failures:

• missing or broken local asset references
• unlabeled buttons and form controls
• JavaScript syntax errors when node is available
• missing event-handler wiring
• missing responsive CSS signals
• obvious mobile overflow fixed widths
• missing run instructions in README

Use --fix-rounds 1 or higher to let Codex repair failures and then rerun self_check.sh, QA, and review.

Generated Project Contract

Each generated project should include:

README.md
HARNESS_PROMPT.md
HARNESS_QUESTIONNAIRE.md
HARNESS_QUESTIONNAIRE.tsv
HARNESS_STYLE_OPTIONS.md
HARNESS_STYLE_OPTIONS_FORM.html
HARNESS_DEMO_PLAN.md
HARNESS_DEMO_URL.md
HARNESS_ACCEPTANCE.md
HARNESS_SUMMARY.md
HARNESS_RUN.json
self_check.sh
source files
dependency files when needed

Repository Layout

bin/
  dingcode
Cargo.toml
src/
  main.rs
  board.rs
  tasks.rs
templates/
  build_prompt.md
docs/

Current Planning Document

See docs/IMPLEMENTATION_PLAN.md for the first implementation plan.