Dong-skills — agent collaboration workflows

At a glance

Role Sole author — workflow design, safety boundaries, review protocol, documentation

Problem

Multi-agent coding work fails when scope, privacy, review authority, and verification are implicit. A second agent is useful only if it receives a bounded packet and its claims are checked against the real repo.

Solution

I turned repeated collaboration practice into explicit skill workflows: define the work packet, constrain what the second agent can see or do, require review gates, and verify every claim against the repo before shipping.

Impact

Public skills repository · collaboration workflows across Claude Code, Codex, OpenCode, and Grok · skills aligned with the plugin contract v2

My contribution

Claude-Codex mutual-review workflow for asking one coding agent to review the other's diff without giving up final ownership
Codex-OpenCode workflow with capability checks, bounded delegation, review/adversarial-review entry points, and result verification
OpenCode collaboration guidance that keeps task text in prompts, treats files as attachments, avoids hidden runtime context, and makes Codex verify every finding
Codex-Grok collaboration workflow for using grok-plugin-codex: capability checks, bounded runs, review/rescue/adversarial review, session export, background jobs, and final Codex verification
OpenCode and Grok collaboration skills aligned with the plugin contract v2 in 2026-07 while keeping the three named workflows explicit

Technical evidence

Operational safety rules: no destructive commands, no commits or pushes by the second agent, no private runtime paths, and no acceptance of unverified agent claims
Reusable work-packet shape: goal, acceptance criteria, exact files in scope, constraints, verification commands, expected output, and risks
Review discipline: OpenCode and Grok can supply second-pass review or adversarial review, but Codex remains responsible for reading the diff, running tests, and deciding what ships

Why this repo exists

The repo turns repeated local practice into explicit operating rules. When Codex asks Claude Code, OpenCode, or Grok for help, the useful part is not simply having another model speak; it is making the collaboration bounded, inspectable, and verifiable.

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.

Second agents as reviewers, not owners

The Codex-OpenCode workflow treats OpenCode as a second reviewer or bounded helper. It starts with a capability check, 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 Grok availability, delegate one bounded task or review, inspect complete results, and keep Codex responsible for files, tests, git, and final judgment.