Dong-skills — agent collaboration workflows
- Codex
- Claude Code
- OpenCode
- Grok CLI
- Agent Workflows
- Code Review
- Verification
A public personal skills repository that turns repeated multi-agent coding practice into explicit operating rules. Four named workflows cover the pairings actually in use — Claude-Codex mutual review, Codex-OpenCode, Codex-Grok, and Codex-Antigravity — and each fixes the same questions: what gets delegated, what stays private, who owns git, and which checks must pass before a second agent's opinion becomes an accepted change. Two of the three run inside the Codex CLI on plugins from my own six-plugin matrix; the third runs inside Claude Code on a third-party plugin.
Project overview
Role Sole author — workflow design, safety boundaries, review protocol, documentation, and the field-tested failure notes
Scenario
Multi-agent coding work fails when scope, privacy, review authority, and verification are implicit. A second agent is useful only if its remit is bounded and its claims are checked against the real repo. And the failures that actually cost time are rarely reasoning failures — they are runtime ones: a config value that kills the second agent at startup with no useful error, a long job that returns only an id, a flag the wrapper silently drops.
Product strategy
I wrote the recurring practice down as skills: bound what the second agent can see or do, require review gates, and verify every claim against the repo before shipping — as a work packet where the second agent is a delegate, and as a reviewed spec and plan where it is a peer. Each runtime failure is recorded with its symptom, its actual cause, and the exact recovery, so the next session recognises it instead of rediscovering it.
Outcome and current stage
Public skills repository · four named workflows in two shapes — one peer mutual review, three bounded delegations · a field-tested failure log grown across 2026-07 and 2026-08 · the three delegation skills defer to the installed plugin's current contract instead of pinning a version
My contribution
- Claude-Codex mutual review in two phases: the design is reviewed in fresh threads until it comes back GO before any code is written, then Codex implements task by task while Claude runs the tests Codex's sandbox cannot and commits only after green plus a review round. Green tests alone do not count as done, and every recheck starts a fresh thread because a resumed review thread drifts and invents bugs that are not there.
- Codex-OpenCode bounded delegation: a capability check whenever availability is uncertain, one role per call from an explicit tool table, completion judged only by the run's own completion flag, then every cited file re-read and every relevant command re-run on the Codex side.
- Codex-Grok bounded delegation with four roles — bounded implementation, independent review, adversarial review, and rescue diagnosis — plus an acceptance ledger that marks every Grok claim accepted, rejected, or narrowed.
- A field-tested failure log inside the Claude-Codex skill, grown across 2026-07 and 2026-08 — nine operational gotchas sitting alongside six red lines and five anti-patterns: the startup config value that kills the second agent with no useful error, long jobs that come back as a bare id and must be polled rather than treated as failures, model and effort flags the wrapper does not reliably forward and that must be read back from the session record, and a CLI upgrade that never reaches an already-running shared runtime.
- Acceptance gates written so a wrong implementation cannot pass them, after three consecutive review rounds attacked the gates themselves rather than the code: required copy is bound to the exact field and language that renders it, because a keyword found anywhere in the file is not a gate.
Technical evidence
- The hard boundaries the three bounded-delegation workflows share: no destructive commands, no commits or pushes by the delegate, no private runtime paths, one writer per working tree, and no unverified claim accepted as a finding.
- A reusable work-packet shape for the three bounded-delegation workflows: goal, binary acceptance, a scope of one to five files or a single narrow directory, widened to one explicit diff in the Grok variant, read and write authority, prohibited actions, verification commands, required return shape, and risks. The peer workflow does not use it — there the unit is a spec and a plan, not a packet.
- A handoff record that those same three workflows require after every delegation: the role, the job or session id, the exact scope, the terminal state, whether the run actually reported completion, the second agent's claims, the verification done, the claims rejected, the commands actually run, and the remaining risks.
- In those three workflows the installed plugin decides tool behaviour, not the skill: the skill never reconstructs a missing tool or parameter from its own text, and pins no contract version — which is what let the sibling plugins keep shipping without invalidating a workflow that has not been edited since 2026-07.
Why this repo exists
The repo turns repeated local practice into operating rules for bounded, inspectable, and verifiable collaboration between Claude Code, Codex, OpenCode, and Grok. The skills define what gets delegated, what stays private, who owns git, and which checks must pass before a second-agent opinion becomes an accepted change.
Written down, the rules outlast the session that produced them. Much of what the repo gained across 2026-07 and 2026-08 is not new theory but recorded failure — the symptom, what actually caused it, and the exact recovery — because those are the details a fresh session has no way to rediscover cheaply.
Second agents in review roles
The Codex-OpenCode workflow treats OpenCode as a second reviewer or bounded helper. It runs a capability check whenever availability is uncertain, sends an explicit work packet, forbids commits and destructive commands, then requires Codex to verify findings against real files and test output.
The Codex-Grok workflow applies the same rule to grok-plugin-codex: check capability when availability or version compatibility is uncertain, delegate one bounded task or review, inspect complete results, and keep Codex responsible for files, tests, git, and final judgment. Every returned claim is then marked accepted, rejected, or narrowed — a partial log or a confident assertion is a lead, not a conclusion.
The Claude-Codex workflow is deliberately not that shape. It is bidirectional: each side reviews the other until both models and the test suite agree, the roles are fixed so they cannot invert, and the design phase is gated before implementation starts. Bounded delegation catches a bad diff; only a design reviewed to GO in fresh threads catches the plan that should never have been implemented at all.
What the workflows run on
The workflows are host-specific and provider-specific because the plugins are. One skill runs inside Claude Code; the two that run inside the Codex CLI ship an agent registration for it. Six sibling plugins of mine broker three second agents into two hosts — opencode-plugin-cc, grok-plugin-cc, and agy-plugin-cc inside Claude Code, and opencode-plugin-codex, grok-plugin-codex, and agy-plugin-codex inside the Codex CLI. The three workflows attach to that matrix unevenly: the Codex-Grok one names grok-plugin-codex directly, the Codex-OpenCode one is written against the opencode_* tool surface rather than a named plugin, and the Claude-Codex one depends on a third-party plugin that is not mine at all.
Coverage is narrower than the matrix, and narrower than the matrix makes it look. The four named workflows cover the Claude-Codex pairing plus the whole Codex-CLI side of the matrix — OpenCode, Grok, and Antigravity. The Claude Code side — opencode-plugin-cc, grok-plugin-cc, and agy-plugin-cc — still has no named workflow of its own. A pairing gets written up once I have used it enough for its failure modes to be worth recording; the repo is meant to be a record of what actually broke, not a map of what could be connected.