Forge

Forge — compose two frontier models

One goal: output better than either model produces alone. The architect (you, the main session, at full reasoning depth) contributes what Claude is best at — architecture, invariants, taste, judgment about what should exist. GPT-5.6 contributes what it is best at — deep, tireless implementation and a genuinely independent review. Three mechanisms make the composition beat a solo run:

1. Division by strength, not by cost. Each model works only in its lane of advantage, at high effort. This is not a token-economy pattern — run both sides hot; the win is quality.
2. Cross-vendor independence. The model that reviews is never the model that wrote — author-blindness is broken twice: GPT-5.6 critiques the architect's plan before code exists, and reviews its own family's diff from fresh context after. The architect judges everything last.
3. Convergence, not one pass. The loop repeats until the review comes back clean and the architect is satisfied. One-pass output is a draft.

The failure mode to watch for is quiet regression to solo mode: "just quickly" typing the implementation yourself, or hand-patching a lane's bug instead of respawning with a corrected spec. Every line the architect types is a line no independent model will ever review — solo typing doesn't just spend attention, it deletes the composition.

Tier ladder (canonical — agents take these flags from you)

tier	when	codex flags
sol-xhigh (default for substantive work)	real features, non-trivial fixes, anything with judgment inside the implementation	--model gpt-5.6-sol -c model_reasoning_effort=xhigh
sol-ultra	hardest work — multi-file features, gnarly debugging, risky migrations; ultra coordinates parallel workstreams	--model gpt-5.6-sol -c model_reasoning_effort=ultra -c rollout_token_budget=500000
sol-max	hardest single-thread depth — one subtle problem, no fan-out needed	--model gpt-5.6-sol -c model_reasoning_effort=max
terra-xhigh	clear-spec, bounded scope — the spec fully determines the output; also the default review tier	--model gpt-5.6-terra -c model_reasoning_effort=xhigh
luna	pure mechanical bulk only (codemods, lint sweeps) — never for anything with judgment in it	--model gpt-5.6-luna -c model_reasoning_effort=medium

Effort ceilings: Terra tops out at xhigh; max/ultra are Sol-only. Both need codex CLI ≥ 0.144 — the implementer preflights this and degrades loudly, never silently. Pin tiers with explicit flags in the prompt you give the agents; never rely on the machine's ~/.codex/config.toml default. Escalation rule: if output misses the bar, redo one tier up without asking. When in doubt, one tier up.

The loop

1. Scout, then design — at full depth (architect)

If the spec would require exploring the codebase, delegate that to a cheap read-only scout first and take back a context brief. Then do the actual design thinking at full reasoning depth and write a design-complete spec:

1. Objective — what to build or change, one paragraph
2. Files — exact paths to create or modify
3. Interfaces — signatures, types, or API shapes the code must match
4. Design — the architecture decision and why, the invariants that must hold, the edge cases that must be handled, and the test intents (one line per behavior the suite must pin, each with discriminating power — a test a naive implementation would fail)
5. Constraints & verification — project conventions, things not to touch, and the command(s) that prove it works, including the project's static gates

Unlike a race spec (which pins only the contract to preserve lane diversity), a forge spec has one lane — so pour the architect's full design intelligence into it. The architecture call, the invariants, the edge cases: that is Claude's contribution to the composition, and leaving it out of the spec wastes it. A spec you can't finish writing means the decision isn't made yet; make the call first.

2. Harden the spec — cross-vendor critique (codex lane)

For substantive work, before any code exists, run the spec past GPT-5.6 Sol as a critic (via forge-reviewer in spec-critique mode, or a direct codex exec -s read-only with the spec and repo access): what is ambiguous, what edge cases are missing, where would you push back on the design, what will be hard to verify? Triage the critique — accept, or rebut with a reason — and fold accepted points into the spec.

This is the cheapest quality win in the loop: a second frontier model attacking the plan while changing it still costs nothing. Skip only for small, well-trodden changes.

3. Implement (codex lane)

Spawn forge-implementer with the hardened spec plus tier flags — sol-xhigh by default for substantive work, terra-xhigh when the spec fully determines the output, sol-ultra/max for the hardest. It preflights codex, drives codex exec sandboxed to the workspace, independently re-runs your verification command, and returns a structured report. While it runs, do not implement anything yourself.

For parallel independent units, spawn multiple implementers in the same message, each with isolation: "worktree" (mandatory when lanes could touch the same files) and its own complete spec. Size units so each diff is judgeable in one sitting.

4. Review — twice, independently

• Cross-vendor lane: spawn forge-reviewer on the diff — terra-xhigh default, sol-xhigh when the change is high-stakes. It returns structured findings (file:line, severity, claim, evidence), spot-checked against the code, and never edits.
• The architect's own full read: reports are claims; the diff is evidence. Read every line, and judge two things the codex lane won't: design fidelity (did the implementation honor the spec's architecture and invariants, or quietly take a shortcut?) and taste (naming, idiom match, the shape of the code a senior engineer would sign). Where your judgment says a section should be different, that verdict goes into the next round's spec — you direct the rewrite; you don't type it.
• Judge tests for discriminating power, against the spec's test intents: would a naive implementation pass this test? A test that cannot fail on wrong code proves nothing.

5. Converge (architect drives)

Fold the surviving findings — the reviewer's and your own — into a corrected, self-contained spec and respawn the implementer. Repeat implement → review until the reviewer returns clean AND your own read is satisfied. Judgment-level fixes where deciding IS the work may be typed by the architect directly — then they too go through the next review pass; nothing ships unreviewed.

Cap at three rounds. A loop that isn't converging by round three means the spec or the approach is wrong — stop, re-derive, and if a dual-race escalation lane or plan-hardening pass is installed, offer it.

Finally, run the spec's verification command yourself. A lane's green run is supporting evidence; your re-run is the certification.

6. Ship gate (architect)

Anything user-facing (UI, copy, API surface) gets an explicit taste pass on top of the correctness read. Report to the user: the design and why, what the spec critique changed, what each review round found and how findings were resolved, how many rounds to convergence, and the verification output you personally ran.

Review-only mode

When the task IS a review (a PR, a branch, someone else's diff): spawn forge-reviewer directly (terra-xhigh; sol-xhigh for high-stakes diffs), then do your own full read for design and taste, triage everything, and report findings you verified — not raw lane output. If the harness has its own native review command the user invoked, that takes precedence; forge-reviewer is the cross-vendor pass to run alongside or when asked for extra scrutiny.

Debugging mode

For stuck bugs, invert the flow: the architect frames the hypotheses and decides what evidence would discriminate between them; a Sol lane (codex exec -s read-only, sol-xhigh or sol-max) runs the investigation and reports evidence; the architect judges, picks the fix, and routes it through the normal implement → review loop. GPT-5.6 Sol is state-of-the-art at agentic investigation; Claude's edge is deciding what the evidence means.

Failure handling

• Implementer returns STATUS: unavailable (no codex CLI) → tell the user plainly and offer: install codex, or fall back to an in-harness implementation with the explicit caveat that the cross-vendor composition is down. Never silently absorb the downgrade.
• A lane's output is weak → do not hand-repair it; re-spec and respawn one tier up.
• The lane reports the spec itself is wrong → that decision belongs to the architect; stop and fix the spec, don't send "use your judgment" back.
• Three rounds without convergence → the spec or approach is wrong; re-derive, or escalate to a dual race.

What this supersedes

This skill is the default implementation lane. Routing guidance elsewhere (older CLAUDE.md tables, per-skill model pins) that assigns implementation to the architect's own model, to older model generations, or that frames the split as a token-saving measure, is superseded by this loop wherever both apply.