Sol Prep

sol-prep — one coordinator, two frontier families, zero day-one fumbling

The one idea

On July 9, 2026 you have TWO frontier models at once: Claude (Fable 5 until July 12, then Opus 4.8) and OpenAI's GPT-5.6 Sol inside Codex. The mistake everyone will make tomorrow is treating it as a versus. It's a pairing:

• Claude = the coordinator. It plans, splits work into parallel lanes, writes the

briefs, judges the results. Planning quality is what makes parallel agents work at all.

• Codex-Sol = the worker fleet. Sol is built for long-horizon agentic coding, and

Sol Ultra literally runs cooperating subagents. Feed it execution-ready briefs and it runs lanes in parallel.

• Cross-model peer review = the multiplier. Two model FAMILIES don't share blind

spots. Claude reviews every Sol diff; Sol reviews Claude's plan before work starts. A bug that survives two independent frontier families is rare.

The unit of value is parallel lanes × review both ways. And none of the prep needs Sol — which is why you run this skill TODAY, on the models you already have.

One adaptive loop, two modes

detect sol availability
 ├─ NOT YET → PREP-MODE  (split backlog → worker briefs → wire config → dry-run fleet)
 └─ LIVE    → SWAP-MODE  (flip model string → verify → dispatch waves → peer review)

Availability detection (in priority order)

1. Sentinel file ~/.claude/.sol-live exists and contains live → SWAP-MODE.

(Flip it the moment Sol answers: echo live > ~/.claude/.sol-live.)

1. Config override mode: "prep" | "swap" in config.json forces a mode.
2. Probe fallback: codex exec --model gpt-5.6-sol "reply with the word ready" —

a model-not-found/auth error → PREP-MODE. Never assume LIVE without a positive reply.

Default when ambiguous = PREP-MODE. Prep is +EV even if the drop slips: the same briefs run on today's Codex model, just with fewer lanes.

Generic core vs adapter (this is the public lead magnet)

The CORE is repo-agnostic. Per-machine specifics live in config.json (gitignored); ship config.example.json. Keys:

• coordinator_model (default claude — whatever your claude CLI runs, Fable/Opus)
• worker_model_today (default gpt-5.5) and worker_model_target (default gpt-5.6-sol)
• worker_effort (default high; reserve max/Ultra for the hardest lane — subagent

runs bill 2-4x, so Ultra is a scalpel, not the default)

• lanes[] — the parallel work streams {name, repo_path, brief_path}. If empty,

PREP-MODE builds them from your backlog/board.

• orchestrator — "orca" | "terminals" | "agent-tool". Auto-detected: orca status

succeeds → orca; else plain terminals or the Claude Code Agent tool.

• hard_constraints[], quality_gates{} — copied into every worker brief.

A stranger installs this on a laptop with just claude + codex and no Orca, and it still works — they get sequential lanes instead of a parallel fleet. Orca is the upgrade that turns it into mission control.

---

PREP-MODE algorithm (run this TODAY)

Goal: when Sol answers its first prompt, the ONLY thing left to do is swap one model string. Everything else — selection, splitting, briefs, config, plumbing — is done.

1. Split the backlog into parallel lanes

Have the coordinator sweep your backlog (board, TODOs, open PRDs, fable-prep queue if you run it) and group work into independent lanes — streams that touch disjoint files so workers never collide. Rules:

• 2-6 lanes. More lanes than you can review is fake parallelism.
• A lane = coherent, independently shippable, one repo (or one subtree).
• Anything requiring taste-level frontend or architecture judgment stays in the

coordinator's own lane — don't delegate your highest-ceiling work to a day-one model you haven't calibrated yet.

2. Write one worker brief per lane (the packet)

Every brief must be executable with zero clarifying questions. Schema — write to sol-queue/lane-.md:

# Lane: 
working_directory: /abs/path
files_in_scope: [...]          # the collision boundary — workers stay inside it
operation: 
acceptance: 
machine_check: 
expect: 
review_gate: coordinator diff-review REQUIRED before commit
constraints: 

3. Wire the swap so it's one line

~/.codex/config.toml:

model = "gpt-5.5"                    # ← the only line you change tomorrow
model_reasoning_effort = "high"      # per-run override: codex -c model_reasoning_effort="max" "..."

Tomorrow: model = "gpt-5.6-sol". That's the whole migration. (Per-lane override without touching config: codex -c model="gpt-5.6-sol" ....)

4. Dry-run the fleet TODAY on the current model

This is the step everyone skips and regrets. Spawn the actual fan-out with worker_model_today, send each lane's brief, collect one small result per lane, and fix the plumbing failures NOW:

• Agent CLIs boot with dialogs (update / trust-directory / hooks). A brief sent into a

dialog is EATEN. Always wait for idle, read the screen, answer dialogs, THEN send.

• Verify each worker writes its result artifact — agents reliably report and

unreliably write files. The artifact is the source of truth, not the prose.

• Verify your review loop: coordinator reads each worker diff and produces a

PASS/FAIL with evidence. If review is manual eyeballing, it won't survive 4 lanes.

PREP-MODE output = sol-queue/ (lane briefs + SWAP-CHECKLIST.md) — the one-screen artifact for you and the reel.

---

SWAP-MODE algorithm (drop day)

1. Verify, don't celebrate: codex exec --model gpt-5.6-sol "reply ready" must

answer. Then echo live > ~/.claude/.sol-live.

1. Flip model = "gpt-5.6-sol" in ~/.codex/config.toml.
2. Plan review, Sol's direction: before dispatching, hand Sol the wave plan —

codex exec "adversarially review this plan for missing deps and collisions: ". Fold real findings in. (Peer review runs BOTH ways, starting now.)

1. Dispatch the wave — one worker per lane via your orchestrator:

• Orca: orca worktree create --name lane- --agent codex --prompt "",

wait event-driven (orca terminal wait --for tui-idle / orca orchestration check --wait), never poll. One worktree per lane = free collision isolation.

• Plain terminals: one codex per terminal, briefs pasted, results to files.
• Agent tool: sequential fallback — still 2 frontier families, just no parallelism.

1. Peer review, Claude's direction: per finished lane, coordinator reviews the

diff against the brief's acceptance + runs machine_check; output must equal expect. FAIL → one fix round with the failure pasted verbatim; second FAIL → lane back to the coordinator, don't loop.

1. Gate, then commit per your repo's rules. Cross-model review is your second

pair of eyes, not a substitute for tests.

1. Wave close: stop worker processes/terminals, harvest branches, remove dead

worktrees. A zombie fleet burns RAM and confuses the next wave.

Calibration discipline (day one of any model)

• Start Sol on the MEDIUM-hard lanes. Watch 2-3 lanes before trusting it with the

hardest one. Benchmarks are vendor-reported; your repo is the real eval.

• Keep effort at high; escalate one lane to max/Ultra only when a lane earns it —

Ultra's subagents multiply output tokens 2-4x.

• Log lane outcomes (one line each) — by wave 3 you'll know Sol's real lane fit.

Hard rails (always on, both modes — copied into every brief)

• Never touch live/production-critical paths you've flagged in hard_constraints

(for the author's machine: trading paths + killswitch are absolute no-go).

• Archive, never delete. Workers don't rm; they move to _archive/.
• Verify, don't assert: every "done" carries its machine_check output.
• Collision boundary is law: a worker that needs a file outside files_in_scope

stops and escalates — it does not improvise.

---

Field notes (from real two-frontier waves — encode these, they were paid for)

• Wait on events, never poll. Polling a file once burned 7 hours watching a dead

process — a dead process and a stalled agent look identical to a file-existence check. Use your orchestrator's event wait (orca orchestration check --wait / terminal wait --for tui-idle); watchdog on log GROWTH, not file existence.

• Anchor a coordinator mailbox. If the coordinator isn't itself a terminal in the

orchestrator, create one (orca terminal create --title coordinator) and use its handle for every dispatch/check — replies need a stable inbox.

• Dispatch as a tracked task, not a pasted prompt. `orca orchestration task-create

--spec '' then dispatch --to --from --inject` — inject delivers the brief plus the worker protocol (done/heartbeat/ask), so results come back as messages instead of TUI scraping.

• One worktree per lane, branched off main, coordinator closes each lane:

verify git log main.. shows the commits, then remove the checkout — the branch survives, the zombie fleet doesn't.

• Cross-model review one-liner (Claude→Codex direction): pipe stdin closed or it

hangs on a TTY — codex exec -m -s read-only "review this plan: ..." < /dev/null.

• A worker's "done" is a claim. Close a lane with a verdict + pasted evidence

(test counts, commit range, diff stats), never with the worker's summary alone.

Run it

• Skill(sol-prep) with no args → detect mode and proceed.
• "prep" → force PREP-MODE (build/refresh lanes + briefs + dry-run).
• "swap" / "sol is live" → force SWAP-MODE (requires the sentinel or a live probe).
• "status" → print SWAP-CHECKLIST.md + which lanes are queued/reviewed.

First run: PREP-MODE writes a starter config.json from what it detects (claude? codex? orca?), then builds your first sol-queue/. That queue + the one-line swap is the whole demo.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: Dallionking
• Source: Dallionking/sol-prep
• License: MIT

Install and usage instructions live in the source repository linked above.