Codex as Coworker Skill

Codex as Coworker

Codex is a capable senior engineer you can delegate to. Think of it as having a coworker who can:

Draft specs while you think through architecture
Implement code based on patterns you've identified
Review your work for bugs and edge cases
Write tests for code you've written
Brainstorm approaches to a problem

Your tokens are expensive and limited. Codex tokens are cheap. Delegate aggressively.

Invocation

Preferred: Moonbridge MCP (unified interface)

mcp__moonbridge__spawn_agent({
  "prompt": "Implement X following the pattern in Y. Run pnpm typecheck after.",
  "adapter": "codex",
  "reasoning_effort": "high"
})

Parallel tasks (multiple agents at once):

mcp__moonbridge__spawn_agents_parallel({
  "agents": [
    {"prompt": "Implement feature A", "adapter": "codex", "reasoning_effort": "high"},
    {"prompt": "Write tests for A", "adapter": "codex", "reasoning_effort": "medium"},
    {"prompt": "Review for bugs", "adapter": "codex", "reasoning_effort": "high"}
  ]
})

Fallback: CLI (when MCP unavailable)

codex exec --full-auto "Implement X" --output-last-message /tmp/codex-out.md 2>/dev/null
# Then validate via: git diff --stat, pnpm test, or read summary only if needed

Interactive session for complex problems:

codex "Let's design the data model for this feature"

Token Economics

Your output tokens cost 5x your input tokens. Codex tokens are separate.

Codex generates 1000 tokens of code → costs Codex, not you
You read Codex's output → input tokens (cheap)
You generate same code yourself → output tokens (expensive)

Net savings: ~80% on code generation by delegating to Codex.

To maximize savings:

Have Codex write to files directly
Validate by running tests or checking git diff --stat
Only read full output when debugging failures

Reasoning Effort

Vary reasoning effort based on task complexity:

| Task | Effort | When | |------|--------|------| | Simple edits, boilerplate | medium | Getters, CRUD, obvious changes | | Most implementation (default) | high | Features, refactors, tests | | Complex debugging, architecture | xhigh | Race conditions, security, hard bugs |

Via Moonbridge MCP:

mcp__moonbridge__spawn_agent({
  "prompt": "Debug this race condition",
  "adapter": "codex",
  "reasoning_effort": "xhigh"
})

Via CLI (fallback):

codex exec --full-auto -c model_reasoning_effort=xhigh "Debug this race condition"

Default to high. Drop to medium for trivial work. Escalate to xhigh for genuinely hard problems.

When to Delegate

Good candidates:

Implementation from a clear spec or pattern
Writing tests for existing code
Code review and analysis
Drafting specs for you to refine
Exploring multiple approaches in parallel
Boilerplate and CRUD operations
Refactoring with clear before/after

Keep for yourself:

Novel architecture decisions
Deep codebase reasoning you've already done
Integration across unfamiliar systems
Anything requiring context you already have loaded
Quick one-liners where overhead isn't worth it

Parallel Work

You can think while Codex works:

Have Codex draft code while you design the architecture
Have Codex write tests while you implement
Get Codex's review while you plan the next step

Trust but Verify

Always review Codex output before committing. Run tests. Check it fits codebase patterns. Codex is good but not infallible.

Context Passing

Give Codex enough context to succeed:

Reference specific files or patterns to follow
Include relevant constraints
Be specific about what you want

Bad: "Write a user service" Good: "Implement a UserService class following the pattern in src/services/AuthService.ts. Include CRUD operations for users with proper error handling."

Pre-Delegation Checklist

Before delegating, ask yourself:

Does this file have existing tests? → Add to prompt: "Don't break existing tests in [test file]"
Should Codex ADD or REPLACE? → Be explicit: "ADD to this file" vs "REPLACE this file" → Default to ADD unless rewrite is intentional
What quality gates should Codex run? → Include: "Run pnpm typecheck && pnpm lint after changes"
What patterns should Codex follow? → Include: "Follow the pattern in [reference file]"

Prompt Templates

Adding to existing file (safest):

ADD a new [function/component] to [file].
Follow the pattern used in [reference].
Don't modify existing functions.
Run pnpm typecheck after.

Replacing/rewriting (use cautiously):

REPLACE [file] with [new implementation].
Note: This file has tests in [test file] - ensure they still pass.
Run pnpm typecheck && pnpm lint after.

New file from scratch:

Create [file] implementing [spec].
Follow patterns from [reference].
Run pnpm typecheck after.

With quality gates (recommended):

codex exec "ADD [function] to [file]. Follow pattern in [ref]. \
  Don't break tests in [test file]. Run pnpm typecheck after." \
  --output-last-message /tmp/codex-out.md 2>/dev/null

Post-Delegation Validation

After Codex completes:

Check what changed:
```
git diff --stat
```
Run quality gates:
```
pnpm typecheck && pnpm lint
```
Run tests:
```
pnpm test
```
If tests broke:
- Check if Codex deleted/renamed functions tests depend on
- Look for wholesale file replacement when ADD was intended
- Review imports that may have been removed
Review integration points:
- You handle complex integration across files
- Check redirects, configs, and cross-file dependencies

Why Moonbridge MCP

Use Moonbridge for all Codex delegation:

| Method | When | |--------|------| | mcp__moonbridge__spawn_agent | Primary method — unified interface | | codex exec CLI | Fallback when MCP unavailable |

Key benefits:

Mixed parallel: Run Codex + Kimi in same spawn_agents_parallel call
Consistent params: Same interface for both adapters
Better control: reasoning_effort for Codex, thinking for Kimi

See /delegate for full orchestration patterns.

Agent Skills: Codex as Coworker

Install this agent skill to your local

Skill Files