name: codex-coworker
description: "Invoke Codex CLI as a coworker for implementation, brainstorming, specs, and reviews. Use when you want parallel thinking, cheap execution, or a second opinion. Codex tokens are cheaper than yours — delegate aggressively. Keywords: codex, delegate, implement, draft, review, brainstorm, write tests, code review."

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: File output (minimizes your token consumption)

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

Quick tasks (output comes back to you):

codex exec --full-auto "Implement X following the pattern in Y"

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:
1. Have Codex write to files directly
2. Validate by running tests or checking git diff --stat
3. Only read full output when debugging failures

Reasoning Effort

Always use gpt-5.2-codex. Vary reasoning effort based on task complexity:

Examples:

# Standard (most tasks) - high effort
codex exec --full-auto "Implement auth middleware"

# Simple task - dial down to medium
codex exec --full-auto -c model_reasoning_effort=medium "Add getter/setter methods"

# Hard problem - dial up to xhigh
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:

1. Does this file have existing tests?
   → Add to prompt: "Don't break existing tests in [test file]"

2. Should Codex ADD or REPLACE?
   → Be explicit: "ADD to this file" vs "REPLACE this file"
   → Default to ADD unless rewrite is intentional

3. What quality gates should Codex run?
   → Include: "Run pnpm typecheck && pnpm lint after changes"

4. 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:

1. Check what changed:
   bash git diff --stat

2. Run quality gates:
   bash pnpm typecheck && pnpm lint

3. Run tests:
   bash pnpm test

4. If tests broke:

5. Check if Codex deleted/renamed functions tests depend on
6. Look for wholesale file replacement when ADD was intended

7. Review imports that may have been removed

8. Review integration points:

9. You handle complex integration across files
10. Check redirects, configs, and cross-file dependencies