/sol

name: sol
version: "1.11.1"
description: Delegate implementation (or, when explicitly requested, research) to GPT-6.1 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, Monitor
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-6.1 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 | |---|---|---| | `SOL_MODEL` | Codex default, else `gpt-6.1-sol` | Model passed as `-m`. Unset, the launcher follows the Codex config's own default model when that is a Sol model, and falls back to `gpt-6.1-sol` otherwise. Recorded per run, so a relaunch or resume never switches model | | `--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` | Seconds a worker may sit with nothing but thread/turn bookkeeping in its event log before it is stall-killed | | `SOL_IDLE_TIMEOUT` | `600` | Seconds without any new event after real work has started before a worker is stall-killed | | `SOL_COMMAND_TIMEOUT` | `1800` | 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 | 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` | Automatic relaunches of a stalled worker, each a fresh session one effort step lower (`xhigh → high → medium → low`) | | `SOL_WAIT_TIMEOUT` | `540` | Seconds `--wait` blocks before returning 75 with workers still live; `0` blocks until done | | `SOL_REPORT_SCHEMA` | bundled `references/report-schema.json` | JSON Schema Sol's final message must satisfy (`--output-schema`). Set it empty for a free-text report | | `SOL_RESEARCH_EFFORT` | `xhigh` | Reasoning effort for `--research`, deliberately independent of `SOL_EFFORT` | | `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.

**Carry over the rules Sol cannot see.** Codex reads `AGENTS.md`. It never reads `CLAUDE.md`, your memory, or anything the user said in this conversation. A standing instruction that constrains the work — "never wipe a database", "virtualenv only, nothing installed system-wide", a commit convention, a directory that must not be touched — reaches Sol only if you put it in the brief. Copy the ones that bear on this task into `<action_safety>`, verbatim. A rule you leave out is a rule Sol breaks in good faith.

2. Implement via Codex CLI

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

Write the brief to `<run-dir>/tasks/01-<slug>.md` — `<run-dir>` is a fresh scratch directory per task, e.g. `$SCRATCHPAD/sol-run` — then launch through the script:

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