Learning path map
Detailed content
🎭 Two agents side by side in the same project
Session handoff, two terminals, shared MCP, and how to keep them from getting in each other's way.
A short, structured summary you ask the current agent for before "handing things off": current focus, files touched, decisions made, open problem, next steps. Paste it into the other agent.
Without this, you become the boss who holds a 30-minute meeting to brief a replacement. With it, one page of notes gets the other agent writing code in 30 seconds.
Fixed template (focus, files, decisions, next step), skill usage session-handoff to standardize, save it to a file (handoff.md) for tracking.
Practical setup: VS Code open in the project, two terminal panes — one running claude, another running codex. Both see the same filesystem, the same git, and the same docs.
It's the setup that unlocks parallel work: Claude refactors the frontend in one panel, Codex writes tests in the other. No need for a separate IDE.
Terminal split, editor split, synchronized workspace settings, shortcuts to switch focus, terminal profile per agent.
If both agents edit the same file at the same time, one overwrites the other. Solution: divide by area (Claude in src/api/, Codex in src/ui/) or by type (Claude implements, Codex tests).
It's the #1 way to lose work with a dual workflow. A disciplined division prevents 100% of cases. Without discipline, things get dramatic within a few hours.
Division by code area, division by phase (implement vs. review), use separate git branches per agent, manual locking via comment.
MCP servers (Slack, Gmail, GitHub, database) run as independent processes. Configured in the .mcp.json (Claude) and config.toml (Codex), both agents connect to the same server.
You don’t duplicate the server—only the declaration. The server itself is shared, which gives you consistency (the same credentials, the same tools).
Static server (stdio) vs. HTTP, declarations mirrored in both runtimes, centralized env vars (.env shared), allowlist by runtime.
Hooks are shell commands. Put the logic in scripts/check.sh in the project, and both runtimes point the hook to this script. Maintenance in one place.
Without this, you duplicate the hook regex in two different places. With it, you edit the script and both agents follow it.
Idempotent script, exit code 0/1, scripts in scripts/ from the project (shared), minimal declaration in settings/config.
Set of rules you (or your team) adopt to choose an agent by task type. Ex: "long refactor = Claude; tests = Codex; parallel debugging = both".
Without governance, choices come down to intuition (unstable). With a written rule, new team members have a standard to follow.
Rule of thumb by task category, A/B test to calibrate, “neutral model” at first (pick whichever is idle), quarterly review.
The ecosystem keeps growing. Gemini CLI, Cursor, Copilot, and JetBrains AI Assistant are on the polyskill roadmap as adapters. Your cross-runtime skill is already ready—only the adapter is missing.
To understand that the investment in writing in the portable format is future-proof. It’s not just “Claude+Codex”—it’s any runtime that comes along.
Adapter as a simple contract (parse/emit/validate), the Early AI Dopters community, contribute an adapter via PR, skill branding independent of the runtime.