@ask-llm/plugin 0.13.0

package/skills/compare/SKILL.md

@@ -0,0 +1,151 @@
+---
+name: compare
+description: This skill should be used when the user asks to "compare LLMs", "see how each provider answers", "side-by-side response", "what do Gemini, Codex, Ollama, and Antigravity think", or wants raw responses from multiple providers without synthesis. Unlike /brainstorm (which synthesizes findings) or /multi-review (which validates code reviews), /compare just shows each provider's answer side-by-side.
+---
+
+<!-- PORTABLE-CONTRACT:START -->
+## Portable contract
+
+Send the exact same bounded prompt to two to four selected providers concurrently. Preserve input order in the result, show each response verbatim without synthesis or adjudication, and show every provider failure instead of silently dropping it. Never invoke raw provider CLIs when a canonical Ask LLM bridge is available.
+<!-- PORTABLE-CONTRACT:END -->
+
+## Host adapters
+
+### Pi adapter
+
+Use one native `ask-multi` call. Put the common prompt in `prompt` and two to four unique names in `providers`; its implementation, not model-emitted sibling calls, guarantees concurrent bounded dispatch and stable ordering.
+
+<!-- HOST-ADAPTER:CLAUDE-CODE:START -->
+### Claude Code adapter
+
+The existing detailed workflow below is the Claude Code adapter. Its Agent, MCP, hook, `CLAUDE_PLUGIN_ROOT`, and `AskUserQuestion` mechanics apply only on Claude Code; they do not override the Pi adapter above.
+
+
+
+# Compare Provider Responses Side-by-Side
+
+Send the same question to multiple LLM providers and present their responses verbatim, side-by-side. No synthesis, no consensus highlighting, no validation pipeline — just raw outputs so the user can compare directly.
+
+This is the right tool when:
+- You want to see how each provider phrases the same answer (style, depth, confidence)
+- You want a sanity check before picking one provider's recommendation
+- You want to evaluate which provider best fits a specific kind of question
+- You explicitly want to AVOID Claude synthesizing or weighting the responses
+
+If you want consensus extraction → use `/brainstorm` instead.
+If you're reviewing a code diff → use `/multi-review` instead.
+
+## Instructions
+
+### Phase 1: Parse the request
+
+Extract from the user's message:
+1. **The question/prompt** to send to all providers (the meaningful payload)
+2. **Optional provider filter** — if the user says "compare gemini and codex", only those two; otherwise default to all four (gemini, codex, ollama, antigravity)
+3. **Optional context files** — if the user references files (`@path/to/file`), Read each referenced file and inline its contents into the shared provider prompt under a clearly labeled `<context_file path="...">` block. `@file` expansion is Gemini-only; passing the literal path to Codex, Ollama, or Antigravity silently drops the context. For a file too large to inline safely, include the relevant excerpts and state what was omitted.
+
+If the question is missing or ambiguous, ask the user to clarify before dispatching.
+
+### Phase 2: Dispatch in parallel via a single foreground Bash call
+
+Use the **ADR-050 dispatch pattern** (direct backgrounding + per-PID wait, NOT subshells, NOT `run_in_background: true`):
+
+```bash
+set +e
+workdir=$(mktemp -d /tmp/ask-llm-compare-XXXXXX)
+trap 'rm -rf "$workdir"' EXIT
+
+GMCPT_TIMEOUT_MS=480000 node ${CLAUDE_PLUGIN_ROOT}/dist/run.js "$PROMPT" > "$workdir/gemini.out" 2> "$workdir/gemini.err" &
+gem_pid=$!
+
+GMCPT_TIMEOUT_MS=480000 node ${CLAUDE_PLUGIN_ROOT}/dist/codex-run.js "$PROMPT" > "$workdir/codex.out" 2> "$workdir/codex.err" &
+codex_pid=$!
+
+GMCPT_TIMEOUT_MS=480000 node ${CLAUDE_PLUGIN_ROOT}/dist/ollama-run.js "$PROMPT" > "$workdir/ollama.out" 2> "$workdir/ollama.err" &
+ollama_pid=$!
+
+GMCPT_TIMEOUT_MS=480000 node ${CLAUDE_PLUGIN_ROOT}/dist/antigravity-run.js "$PROMPT" > "$workdir/antigravity.out" 2> "$workdir/antigravity.err" &
+antigravity_pid=$!
+
+gemini_rc=0; wait $gem_pid || gemini_rc=$?
+codex_rc=0; wait $codex_pid || codex_rc=$?
+ollama_rc=0; wait $ollama_pid || ollama_rc=$?
+antigravity_rc=0; wait $antigravity_pid || antigravity_rc=$?
+
+dump_provider() {
+  provider="$1"
+  rc="$2"
+  echo "===== ${provider} (rc=${rc}) ====="
+  cat "$workdir/${provider}.out" 2>/dev/null
+  if [ "$rc" -ne 0 ] || [ ! -s "$workdir/${provider}.out" ]; then
+    echo "===== ${provider} stderr ====="
+    sed -n '1,20p' "$workdir/${provider}.err" 2>/dev/null
+  fi
+}
+
+dump_provider gemini "$gemini_rc"
+dump_provider codex "$codex_rc"
+dump_provider ollama "$ollama_rc"
+dump_provider antigravity "$antigravity_rc"
+```
+
+Set the Bash tool's `timeout` parameter to **600000ms** (10 minutes, the max). Default 2-minute Bash timeouts will SIGKILL the providers mid-response — this is the same bug class that ADR-050 fixed for the brainstorm-coordinator.
+
+If the user asked for a subset of providers (e.g., "compare gemini and codex"), drop the dispatch lines for excluded providers and their corresponding wait and `dump_provider` lines.
+
+### Phase 3: Read the captured output
+
+The Bash call dumps every provider response and relevant stderr before its EXIT trap removes the unique work directory. Parse those labeled blocks directly from the Bash result. If a provider's output is empty or its exit code is non-zero, surface the captured stderr — DO NOT silently drop a provider. Never reuse fixed files under `/tmp`; overlapping sessions must remain isolated.
+
+### Phase 4: Present side-by-side
+
+Output structure:
+
+```markdown
+## Comparison: <one-line restatement of the question>
+
+### Gemini
+> <verbatim provider response, do NOT paraphrase>
+
+### Codex
+> <verbatim provider response>
+
+### Ollama
+> <verbatim provider response>
+
+### Antigravity
+> <verbatim provider response>
+
+### Where they differ
+- One bullet per substantive disagreement (1-2 sentences each)
+- If they all agree, say "All providers gave substantively the same answer."
+- Do NOT take a position on who's right — present the differences neutrally
+```
+
+If a provider failed:
+
+```markdown
+### Gemini
+**Failed** (exit 1): <first 3 lines of stderr>
+```
+
+### Output discipline
+
+- **Quote responses verbatim**: do not paraphrase, summarize, or condense. The user invoked `/compare` because they want raw output.
+- **Stay neutral in the "Where they differ" section**: surface the disagreement, do not adjudicate it. If the user wants a recommendation, they will ask follow-up questions.
+- **Keep your own commentary minimal**: a one-line question restatement at the top, the verbatim sections in the middle, the differences callout at the end. That's it.
+- **Do not call `/brainstorm` or `/multi-review` instead** — `/compare` is intentionally simpler. If the user wanted synthesis they would have asked for it.
+
+## Sub-Agent Background Job Lifecycle (must read)
+
+Sub-agents in Claude Code cannot own background processes that outlive their turn. The ADR-050 lesson applies here exactly as it did for the brainstorm-coordinator:
+
+- ❌ Do not use `run_in_background: true` on the dispatch Bash call
+- ❌ Do not use `(cmd &) && wait` — the subshell detaches the child and `wait` returns immediately
+- ❌ Do not split the dispatch across multiple Bash calls
+- ✅ Single foreground blocking Bash call with direct backgrounding (`cmd & pid=$!`) and per-PID `wait`
+- ✅ `timeout: 600000` on the Bash tool call
+
+Without these, providers that take longer than the surrounding turn will be SIGKILLed mid-response and you will silently get 0-byte outputs.
+
+<!-- HOST-ADAPTER:CLAUDE-CODE:END -->

package/skills/fable-review/SKILL.md

@@ -0,0 +1,42 @@
+---
+name: fable-review
+description: Request a review of the current code changes from the Fable model. Use when the user asks for a Fable review, says "review with Fable", wants Fable's independent perspective on a diff, or invokes /fable-review.
+---
+
+<!-- PORTABLE-CONTRACT:START -->
+## Portable contract
+
+Gather a bounded diff and context brief, run the independent Fable reviewer in a read-only isolated context, source-verify its findings, and disclose that the resolved runtime model cannot be independently inspected.
+<!-- PORTABLE-CONTRACT:END -->
+
+## Host adapters
+
+### Pi adapter
+
+Unsupported and intentionally not loaded or advertised by the Pi manifest. Do not start a nested Pi/Fable session. Independent Fable review remains a Claude Code capability.
+
+<!-- HOST-ADAPTER:CLAUDE-CODE:START -->
+### Claude Code adapter
+
+The existing detailed workflow below is the Claude Code adapter. Its Agent, MCP, hook, `CLAUDE_PLUGIN_ROOT`, and `AskUserQuestion` mechanics apply only on Claude Code; they do not override the Pi adapter above.
+
+
+
+# Fable Code Review
+
+Request a read-only, precision-first review in an isolated Fable context.
+
+## Workflow
+
+1. Use Bash to read `CLAUDE_CODE_SUBAGENT_MODEL`. If it is set to anything other than `inherit`, `fable`, or a `claude-fable-*` model ID, abort before launching: this environment variable has higher precedence than the skill's model request.
+2. Run `git status --short`, `git diff`, and `git diff --cached`.
+3. Include untracked files the user wants reviewed with `git add -N <path>` so their contents appear in the diff without staging them.
+4. If the combined diff is empty, report that there are no changes to review.
+5. Read the root and file-scoped `CLAUDE.md` files plus any ADRs cited by changed code.
+6. Launch the `fable-reviewer` agent with the per-invocation model set to `fable`, plus the diff and a compact context brief containing the changed files, applicable conventions, referenced ADRs, and the user's requested review focus.
+7. If the Agent tool reports a fallback or model-availability error, abort instead of returning its findings as a Fable review.
+8. Return the agent's validated findings without adding unverified issues. State that Fable was requested but the resolved model was not independently verified, because Claude Code does not expose the resolved subagent model to skills and an organization `availableModels` policy can silently fall back to the inherited model.
+
+The `fable-reviewer` agent's `model: fable` frontmatter and the launch-time `model: "fable"` argument both request Fable. Do not substitute another reviewer or route this skill through an external MCP provider. Never claim the runtime-selected model was verified when Claude Code did not expose it.
+
+<!-- HOST-ADAPTER:CLAUDE-CODE:END -->

package/skills/gemini-review/SKILL.md

@@ -0,0 +1,40 @@
+---
+name: gemini-review
+description: Get a second opinion from Gemini on your current code changes. Analyzes staged/unstaged diffs and returns prioritized findings. Use when user asks to "review with Gemini", "Gemini code review", or "ask Gemini to check my code".
+---
+
+<!-- PORTABLE-CONTRACT:START -->
+## Portable contract
+
+Gather the relevant staged, unstaged, and untracked code changes; build a bounded context brief; request a Gemini review; verify each reported finding against source; and return only prioritized, source-supported findings. Preserve provider fallback, timeout, and explicit failure disclosure.
+<!-- PORTABLE-CONTRACT:END -->
+
+## Host adapters
+
+### Pi adapter
+
+Call the native `ask-gemini` tool and apply only the `Portable contract` section of `../../agents/gemini-reviewer.md`; ignore that file's frontmatter and Claude Code adapter.
+
+<!-- HOST-ADAPTER:CLAUDE-CODE:START -->
+### Claude Code adapter
+
+The existing detailed workflow below is the Claude Code adapter. Its Agent, MCP, hook, `CLAUDE_PLUGIN_ROOT`, and `AskUserQuestion` mechanics apply only on Claude Code; they do not override the Pi adapter above.
+
+
+
+# Gemini Code Review
+
+Review current code changes by delegating to the `gemini-reviewer` agent.
+
+## Instructions
+
+1. Gather the diff to review:
+   - Run `git diff` to get unstaged changes
+   - Run `git diff --cached` to get staged changes
+   - Combine both into a single diff
+
+2. If the diff is empty, inform the user there are no changes to review.
+
+3. Launch the `gemini-reviewer` agent with the diff content. The agent handles the Gemini prompt structure and output formatting.
+
+<!-- HOST-ADAPTER:CLAUDE-CODE:END -->

package/skills/multi-review/SKILL.md

@@ -0,0 +1,182 @@
+---
+name: multi-review
+description: This skill should be used when the user asks to "review my code with multiple providers", "get reviews from Antigravity and Codex", "multi-provider review", "review changes", or wants independent code reviews from both Antigravity and Codex in parallel.
+---
+
+<!-- PORTABLE-CONTRACT:START -->
+## Portable contract
+
+Build one Context Brief and bounded diff, dispatch the same review contract concurrently to the selected providers, then independently verify every finding against repository source. Classify findings as VERIFIED, REJECTED, or UNVERIFIABLE; preserve size consent at 50KB/150KB; never silently drop a failed provider; and report included/excluded context.
+<!-- PORTABLE-CONTRACT:END -->
+
+## Host adapters
+
+### Pi adapter
+
+Use one native `ask-multi` call for concurrent provider dispatch, then perform source verification in the current host context. Do not use the Claude runner binaries or raw provider CLIs.
+
+<!-- HOST-ADAPTER:CLAUDE-CODE:START -->
+### Claude Code adapter
+
+The existing detailed workflow below is the Claude Code adapter. Its Agent, MCP, hook, `CLAUDE_PLUGIN_ROOT`, and `AskUserQuestion` mechanics apply only on Claude Code; they do not override the Pi adapter above.
+
+
+
+# Multi-Provider Code Review
+
+Run independent code reviews from Antigravity and Codex in parallel, **verify** each finding against the source, then present combined consensus / unique / rejected sections so the user sees what really matters and what was a false positive. (Gemini is one command away via the `gemini-reviewer` agent or `/gemini-review` if you want it in the mix.)
+
+## Why verification matters
+
+Confidence scores are not an oracle. In a real session on 2026-04-17, Gemini returned two findings at 95/100 confidence that were factually wrong (a `z.enum([])` claim that ignored an existing fallback, and an "MCP SDK doesn't support outputSchema" claim that was contradicted by the actual `.d.ts`). Both would have caused a mis-fix if accepted at face value. **Always verify before presenting.**
+
+## Two kinds of verification — pick the right skill
+
+This skill verifies **review findings** — the bugs each provider claims it found. Phase 3 reads the file at the cited line and checks whether each finding is real before presenting it.
+
+That is different from verifying **assistant claims** — the statements the assistant made in its prior turn ("I added retry logic," "I bumped the threshold to 16384"). For that, use `/codex-verify`. It dispatches the `codex-verifier` agent, decomposes the assistant's last message into atomic claims, and proves or disproves each with deterministic evidence. It returns a CONFIDENCE grade on a five-point ladder (`PERFECT | VERIFIED | PARTIAL | FEEDBACK | FAILED`) — `PARTIAL` and `FAILED` are first-class verdicts, surfacing gaps in your verification harness rather than hiding them under a confident-looking number.
+
+| Question | Skill |
+|---|---|
+| "Are there bugs in this diff?" | `/multi-review` (finds new issues, verifies each finding before presenting) |
+| "Did the assistant actually do what it claimed?" | `/codex-verify` (decomposes the assistant's claims, proves each against state) |
+
+The two skills compose. Run both when you want both questions answered; do not merge their outputs.
+
+## Instructions
+
+### Phase 1: Gather and prepare the diff
+
+1. Get the working-tree state:
+   - `git status --short` to see what's modified/added/deleted
+   - For untracked files the user wants reviewed, run `git add -N <files>` so they appear in `git diff` (intent-to-add)
+   - Combine `git diff` (unstaged) and `git diff --cached` (staged) into a single diff
+
+2. **Filter the diff** — exclude noise that providers don't need:
+   - Pathspec exclusions: `:!docs/` `:!apps/docs/` `:!*.md` `:!yarn.lock` `:!*.lock` `:!*.png` `:!*.jpg` `:!*.svg`
+   - Example: `git diff -- ':!docs/' ':!*.md' ':!yarn.lock'`
+   - The user's own ADR/docs additions are not what they want providers to review
+
+3. **Size-check the diff:**
+   - Measure: `wc -c diff.patch`
+   - **< 50KB**: send as-is
+   - **50–150KB**: warn the user "this is a large diff, providers may take 5–15 min" and continue
+   - **> 150KB**: tell the user, ask whether to truncate (head -c 150000) or split by package, do NOT silently send a giant payload
+   - **Empty**: stop and inform the user "no changes to review"
+
+4. **Create a Context Brief** — a compact manifest that makes the handoff reproducible. Put it before the diff in every reviewer prompt; do not use it as an excuse to paste more raw files by default.
+
+```markdown
+## Context Brief
+
+Intent:
+- User request:
+- Review mode: multi-review
+- Providers: <list the actual providers selected for this run>
+
+Scope:
+- Base ref:
+- Changed files:
+- Included files/docs:
+- Excluded files/docs and reason:
+- Diff bytes:
+
+Repository signals:
+- Relevant package/workspace:
+- CLAUDE.md files read:
+- ADRs/docs read:
+
+Risk focus:
+- Security:
+- Data loss:
+- Concurrency/state:
+- API/contract:
+- Tests/build:
+
+Open questions:
+- Items not verified before dispatch:
+```
+
+Keep the brief tiny for simple diffs. Escalate detail when the diff is over 50KB, spans more than 5 files, crosses package boundaries, includes untracked files, references ADRs/specs, or depends on conversation context the external providers cannot see.
+
+### Phase 2: Dispatch (with fallback)
+
+**Preferred: launch both reviewer agents in parallel** using the Agent tool in a single message:
+- `antigravity-reviewer` agent with the Context Brief + diff content
+- `codex-reviewer` agent with the Context Brief + diff content
+- Each agent performs its own multi-phase pipeline: Context → Prompt → Validation → Report
+
+> `antigravity-reviewer` requires `agy` installed + logged in and the Antigravity MCP server registered. If it's unavailable it will say so — present the codex-only result and note "antigravity skipped (agy not available)" rather than failing the whole review. To include Gemini instead/as well, also launch the `gemini-reviewer` agent.
+
+**Fallback when reviewer agents are unavailable** (e.g., plugin not installed in this Claude Code session): dispatch directly via the project's `dist/antigravity-run.js` and `dist/codex-run.js` runner binaries using the **ADR-050 dispatch pattern** (single foreground blocking Bash call, direct backgrounding, per-PID `wait`, 25-min timeout):
+
+```bash
+GMCPT_TIMEOUT_MS=1500000 node ${CLAUDE_PLUGIN_ROOT}/dist/antigravity-run.js "$REVIEW_PROMPT" < diff.patch > /tmp/mr-antigravity.out 2> /tmp/mr-antigravity.err &
+agy_pid=$!
+
+GMCPT_TIMEOUT_MS=1500000 node ${CLAUDE_PLUGIN_ROOT}/dist/codex-run.js "$REVIEW_PROMPT" < diff.patch > /tmp/mr-codex.out 2> /tmp/mr-codex.err &
+codex_pid=$!
+
+agy_rc=0; wait $agy_pid || agy_rc=$?
+codex_rc=0; wait $codex_pid || codex_rc=$?
+```
+
+Set the Bash tool's `timeout` parameter to **600000ms** (10-min max). For diffs > 50KB, expect both providers to take real wall time — this is normal.
+
+Do NOT use raw `agy -p`, `gemini -p`, or `codex exec` — those bypass the project's quota/recovery handling, Codex stdin handling (ADR-042), and PATH resolution (ADR-047). Use the runner binaries.
+
+### Phase 3: Verify each finding before presenting
+
+For every finding from either provider at confidence ≥ 80:
+
+1. Read the file at the cited line (use the Read tool)
+2. Check whether the claim is actually true:
+   - "X function doesn't exist" → verify via Grep
+   - "Y line crashes when Z" → trace the actual code path
+   - "ADR-NNN is contradicted" → read the ADR
+3. Mark each finding as one of:
+   - **VERIFIED** — claim holds against source
+   - **REJECTED** — false positive (with brief explanation of what the provider missed)
+   - **UNVERIFIABLE** — cannot confirm without runtime / external info; present as-is with a note
+
+### Phase 4: Resilient failure handling
+
+When a provider fails (timeout, capacity exhaustion, exit code ≠ 0, 0-byte output):
+- Do NOT silently drop it from the synthesis
+- Surface the failure inline: "Antigravity failed (exit 1): <first 3 lines of stderr>"
+- If both providers failed, say so explicitly and surface both stderr — don't pretend you have findings
+- A single-provider review is still useful — present what you have, note what's missing
+
+### Phase 5: Present the synthesis
+
+```markdown
+## Multi-Provider Review
+
+**Context used:**
+- Included: <files / packages>
+- Excluded: <files / patterns and reason>
+- Diff bytes: <N>
+
+**Verified by both providers (highest confidence):**
+- ⟨finding⟩ — Antigravity: 92, Codex: 88. Verified at <file>:<line>.
+
+**Verified by Antigravity only:**
+- ⟨finding⟩ — Confidence 85. Verified at <file>:<line>.
+
+**Verified by Codex only:**
+- ⟨finding⟩ — Confidence 90. Verified at <file>:<line>.
+
+**Rejected (false positives caught during verification):**
+- ⟨finding⟩ — Provider claimed X at <file>:<line>, but source shows Y. Skipped.
+
+**Unverifiable:**
+- ⟨finding⟩ — Cannot confirm without runtime; flagging for user attention.
+
+**Provider stats:**
+- Antigravity: ⟨N⟩ findings, ⟨V⟩ verified, ⟨R⟩ rejected. Status: ⟨ok | failed: ⟨reason⟩⟩
+- Codex: ⟨N⟩ findings, ⟨V⟩ verified, ⟨R⟩ rejected. Status: ⟨ok | failed: ⟨reason⟩⟩
+```
+
+If you have to truncate either provider's response or skip verification due to time pressure, **say so** in the output. Hidden compromises mislead the user.
+
+<!-- HOST-ADAPTER:CLAUDE-CODE:END -->

package/skills/ollama-review/SKILL.md

@@ -0,0 +1,40 @@
+---
+name: ollama-review
+description: Get a second opinion from a local Ollama LLM on your current code changes. Analyzes staged/unstaged diffs and returns prioritized findings. No API keys needed. Use when user asks to "review with Ollama", "local code review", or "review offline".
+---
+
+<!-- PORTABLE-CONTRACT:START -->
+## Portable contract
+
+Gather the relevant staged, unstaged, and untracked code changes; build a bounded context brief; request a local Ollama review; verify each reported finding against source; and return only prioritized, source-supported findings. Never imply external data transfer and surface unavailable local models actionably.
+<!-- PORTABLE-CONTRACT:END -->
+
+## Host adapters
+
+### Pi adapter
+
+Call the native `ask-ollama` tool and apply only the `Portable contract` section of `../../agents/ollama-reviewer.md`; ignore that file's frontmatter and Claude Code adapter.
+
+<!-- HOST-ADAPTER:CLAUDE-CODE:START -->
+### Claude Code adapter
+
+The existing detailed workflow below is the Claude Code adapter. Its Agent, MCP, hook, `CLAUDE_PLUGIN_ROOT`, and `AskUserQuestion` mechanics apply only on Claude Code; they do not override the Pi adapter above.
+
+
+
+# Ollama Code Review
+
+Review current code changes by delegating to the `ollama-reviewer` agent.
+
+## Instructions
+
+1. Gather the diff to review:
+   - Run `git diff` to get unstaged changes
+   - Run `git diff --cached` to get staged changes
+   - Combine both into a single diff
+
+2. If the diff is empty, inform the user there are no changes to review.
+
+3. Launch the `ollama-reviewer` agent with the diff content. The agent handles the Ollama prompt structure and output formatting.
+
+<!-- HOST-ADAPTER:CLAUDE-CODE:END -->

package/skills/sol-review/SKILL.md

@@ -0,0 +1,41 @@
+---
+name: sol-review
+description: Review the current code changes specifically with OpenAI GPT-5.6 Sol. Use when the user asks for a Sol review, says "review with Sol", wants a model-pinned Codex review, or invokes /sol-review.
+---
+
+<!-- PORTABLE-CONTRACT:START -->
+## Portable contract
+
+Gather a bounded diff and context brief, request a read-only Codex review explicitly pinned to `gpt-5.6-sol` with `reasoningEffort: "high"`, verify findings against source, and disclose any model or transport fallback. Do not silently substitute another provider.
+<!-- PORTABLE-CONTRACT:END -->
+
+## Host adapters
+
+### Pi adapter
+
+Call `ask-codex` with `model: "gpt-5.6-sol"`, `reasoningEffort: "high"`, and `sandbox: "read-only"`; apply only the portable contract in `../../agents/sol-reviewer.md` and disclose fallback metadata.
+
+<!-- HOST-ADAPTER:CLAUDE-CODE:START -->
+### Claude Code adapter
+
+The existing detailed workflow below is the Claude Code adapter. Its Agent, MCP, hook, `CLAUDE_PLUGIN_ROOT`, and `AskUserQuestion` mechanics apply only on Claude Code; they do not override the Pi adapter above.
+
+
+
+# Sol Code Review
+
+Run a read-only, precision-first review explicitly pinned to GPT-5.6 Sol at high reasoning effort.
+
+## Workflow
+
+1. Run `git status --short`, `git diff`, and `git diff --cached`.
+2. Include untracked files the user wants reviewed with `git add -N <path>` so their contents appear in the diff without staging them.
+3. If the combined diff is empty, report that there are no changes to review.
+4. Read the root and file-scoped `CLAUDE.md` files plus any ADRs cited by changed code.
+5. Preflight the transport: check whether an `ask-codex` MCP tool is available in the current session (the name may be plugin-namespaced, e.g. `mcp__plugin_ask-llm_codex__ask-codex`). Subagents do not always inherit the session's MCP servers, so treat availability here as advisory only. If no MCP tool resolves, confirm the `codex` CLI is on `PATH` (`command -v codex`); if neither transport exists, stop and tell the user to install one instead of launching the agent.
+6. Launch the `sol-reviewer` agent with the diff and a compact context brief containing the changed files, applicable conventions, referenced ADRs, the user's requested review focus, and the preflight result (which transport to expect).
+7. Return the agent's validated findings without adding unverified issues.
+
+The reviewer must call `ask-codex` with `model: "gpt-5.6-sol"` and `reasoningEffort: "high"`, or, when no `ask-codex` MCP tool is available in the subagent context, use the sanctioned CLI fallback defined in the agent (`codex exec -m gpt-5.6-sol -c model_reasoning_effort="high" -s read-only --ignore-user-config --ignore-rules --skip-git-repo-check`). This explicit pin distinguishes `/sol-review` from `/codex-review`, which follows the configured Codex default. Both fallback kinds must be disclosed in the report: a Terra quota fallback means the requested Sol review did not complete on Sol, and a CLI transport fallback means the review ran through `codex exec` rather than MCP.
+
+<!-- HOST-ADAPTER:CLAUDE-CODE:END -->