/sol

name: sol
version: "1.8.1"
description: Delegate implementation (or, when explicitly requested, research) to GPT-5.6 Sol (high reasoning; xhigh on request) via Codex CLI. Claude plans, orchestrates, and reviews; Sol writes the code.
argument-hint: "[implementation task]"
disable-model-invocation: true
user-invocable: true
allowed-tools: Bash, Read, Write, Grep, Glob
homepage: https://github.com/ozankasikci/sol-skill
repository: https://github.com/ozankasikci/sol-skill
author: ozankasikci
license: MIT

/sol — Sol implements, Claude reviews

Task: $ARGUMENTS

**Role split (strict):** Claude never edits production code in this flow. Claude plans, briefs Sol, reviews the real diff, and directs corrections. GPT-5.6 Sol (via Codex CLI) makes all code changes and runs tests.

**Task routing:** Implementation tasks follow phases 1–5. If the task is research or investigation (no code changes requested), the planner model does the research itself with its own tools — do NOT invoke Sol, unless the user explicitly names Sol as the researcher ("sol research…", "have sol research", "ask sol"). In that case skip to Research mode at the bottom.

**Parallel routing:** If — and only if — the user names a worker count (`--workers N`, or "use 3 workers"), follow `references/parallel-flow.md` instead of phases 2–5. Never infer parallelism from a request that merely looks like several tasks; the trigger is the number the user typed, not a judgment about the work. `--workers 1` is the normal flow below.

| Setting | Default | Meaning | |---|---|---| | `--workers N` | — | Requested worker count for this run, capped by the ceiling below; its presence engages parallel mode | | `SOL_MAX_WORKERS` | `3` | Ceiling on worker count — caps `--workers` and is the count used when `--workers` is absent; exceeding it is refused, never clamped | | `SOL_WORKTREE_SETUP` | unset | Command run in each fresh worktree (`npm ci`, `uv sync`) | | `SOL_EFFORT` | `high` | Reasoning effort for workers. `high` verifies its own work when a compiler and tests are in the loop, and stalls are effort-correlated (openai/codex#24260, #23807) — an xhigh stall burns the whole first-event budget before anything happens. Raise to `xhigh` for algorithmically hard briefs | | `SOL_FIRST_EVENT_TIMEOUT` | `300` | Parallel mode: seconds a worker may sit with nothing but thread/turn bookkeeping in its event log before it is stall-killed | | `SOL_IDLE_TIMEOUT` | `600` | Parallel mode: seconds without any new event after real work has started before a worker is stall-killed | | `SOL_COMMAND_TIMEOUT` | `1800` | Parallel mode: seconds an in-flight command may produce nothing before the worker is stall-killed — bounds the exemption that lets long silent builds run | | `SOL_WORKER_TIMEOUT` | off | Parallel mode: optional absolute per-worker cap in seconds. Off by default — a task's duration is not predictable, so any constant kills productive workers; the budgets above bound silence instead | | `SOL_STALL_RETRIES` | `1` | Parallel mode: automatic relaunches of a stalled worker, each a fresh session one effort step lower (`xhigh → high → medium → low`) | | `SOL_SANDBOX` | `workspace-write` | Sandbox policy passed as `-s`. `danger-full-access` for a toolchain the sandbox cannot reach at all (Docker). Removes all confinement; the run warns on stderr. Cannot be set via `SOL_CODEX_CONFIG` | | `SOL_CODEX_CONFIG` | unset | Extra `-c key=value` overrides, space separated, applied to every codex invocation the launcher makes. See **Sandboxed toolchains** below. Values must not contain spaces |

**Task tracking:** If harness task tools are available, call TaskCreate at the start (short title from the request, status in_progress), TaskUpdate once per phase transition (planning → Sol implementing → reviewing → corrections), and TaskUpdate to completed in the final report — or leave it in_progress with a note if blocked. Keep updates to one line; skip entirely if the tools are unavailable.

1. Plan (brief)

Inspect only the files needed to write a competent brief. Produce a short plan: goal, likely files, conventions to follow, acceptance criteria, non-goals. Do not over-specify — Sol is a frontier model; give it intent and constraints, not line-by-line instructions. Ask the user only if the task is destructive, security-sensitive, or ambiguous at the product level.

2. Implement via Codex CLI

First checkpoint the repo: if the working tree is dirty, commit or stash so `git diff` afterward isolates exactly Sol's changes and a bad run is trivially revertible.

Write the brief to `<run-dir>/tasks/01-<slug>.md`, then launch through the script:

bash <skill-dir>/scripts/sol-parallel.sh --workers 1 --in-place "$SCRATCHPAD/sol-run"

`--in-place` runs in your working tree and leaves the changes there uncommitted, exactly as a bare `codex exec` would — but it also supervises the run. **Use it for every single-worker run.** A hung codex sits alive and silent forever, and the launcher is what notices: it kills the worker after `SOL_FIRST_EVENT_TIMEOUT` with nothing in its log, relaunches once at lower effort, records a real status in `summary.json`, and returns an exit code you can act on. Watching for that by hand is the one job that has actually been lost in practice — a run hung at `xhigh` with two lines in its event log and burned hours before anyone looked.

Read `<run-dir>/summary.json` for the outcome, and `<run-dir>/workers/<slug>/report.md` for Sol's final message. If the tool call times out before the script returns, the worker is still running — re-attach with `--wait "$SCRATCHPAD/sol-run"` until it stops returning 75.

For a visual task, list reference images in a sidecar next to the brief — `<run-dir>/tasks/01-<slug>.images`, one path per line — and each is passed to the worker as `codex exec -i`. A screenshot of the broken UI or the mockup to match beats a paragraph describing it, and a missing path fails the run at preflight rather than mid-