Skip to content

What Is codeArbiter

codeArbiter ships four sibling plugins from one marketplace. Three are governance hosts: ca for Claude Code, ca-codex for Codex, and ca-pi for Pi. The fourth is ca-sandbox, an infrastructure plugin unrelated to gate enforcement (see ca-sandbox). All three governance hosts inject the same orchestrator responsibilities, enforce the same policy core, and use one checked-in .codearbiter/ directory for project context and audit state. See the Claude Code + Codex evidence for the verified boundary between those two, and Pi for the third host’s install and trust model. The complete ca-pi adapter is currently a Feature Forge preview: real use and feedback are welcome while broader testing continues before stable status.

codeArbiter Holds the Gates; You Hold the Decisions

Section titled “codeArbiter Holds the Gates; You Hold the Decisions”

This is the organizing principle. codeArbiter enforces process; you make the calls. It holds the gates: the test-first rule, the review chain, the secret and crypto checks, the commit and merge boundaries. Work does not pass a gate without clearing it. But the decisions those gates surface belong to you. Which design? Which trade-off? Whether to merge? Those are yours to make. When a gate finds something worth your attention, it reports the finding plainly and waits for your call. It does not resolve the question on your behalf.

  1. Command. Invoke /ca:feature in Claude Code or $ca-feature in Codex. The generated command surface differs in spelling, not ownership or policy.
  2. Route. The orchestrator hands the command to the workflow that owns that lane. /ca:fix and $ca-fix both reach the same test-first obligations.
  3. Execute the roles. The owning skill selects the author and reviewer roles the change actually demands. Claude Code dispatches plugin agents. Current Codex releases load the same charters into host-provided agent threads and retain their thread receipts; older hosts may use an inline fallback unless the workflow requires isolation. Pi launches hardened child processes through its trusted parent. The policy stays shared even though each host’s mechanism differs.
  4. Gate. Nothing advances until its gates are green. A failing test, a CRITICAL security finding, an unresolved decision: each is a real stop.
  5. Ship. Code reaches version control only through the commit gate, and the default branch only through a pull request. Never a direct write.
Lane flow: a command invocation routes to the owning skill, clears its gate, then ships to version control.
One lane, five steps: command, route, gate, ship to a PR.

Gate

A gate is not advice you can wave off. It is the only path that kind of change takes to ship. When a gate trips, codeArbiter surfaces the decision and waits for you to resolve it.

codeArbiter is built so almost nothing loads until it is needed. The only always-loaded context is one file, the orchestrator persona, injected by a SessionStart hook, and only in repositories whose project state opts in. A repo that hasn’t opted in loads nothing at all.

Everything else is paid for on demand: the routing table, the reference map, every skill body, every agent body, the design-quality reference bundle. A node loads only when an entry point reaches it. A typical /ca:fix touches the persona, the test-first skill, one author, and maybe one reviewer. It never pulls the whole payload. Read-only meta commands like /ca:status, /ca:btw, and /ca:commands route to no skill at all.

Work is organized into lanes. Each is a sanctioned path with gates scaled to its risk.

  • Implementation: /ca:feature (checkpointed), /ca:sprint (autonomous, every auto-decision SMARTS-scored), /ca:fix, /ca:refactor, /ca:debug, /ca:chore, /ca:spike.
  • Commit & ship: /ca:commit, /ca:pr, /ca:watch, /ca:checkpoint, /ca:tribunal, /ca:release, /ca:add-dep. /ca:checkpoint is the lean periodic sweep; /ca:tribunal is its rare, deep counterpart: an on-demand, resumable whole-codebase audit by eleven specialist lenses that files findings as GitHub issues on your approval and is never a required gate.
  • Decisions: /ca:adr, /ca:adr-status, /ca:reconcile, /ca:conflict, /ca:threat-model.
  • Project & meta: /ca:init, /ca:status, /ca:audit, /ca:doctor, /ca:btw, and more.

See Concepts for the ideas behind the lanes, and the Reference for the full, auto-generated catalog of commands, skills, and agents.