amirfish1/claude-command-center/second-opinion

Second-opinion spawns a single fresh CCC session with no shared context to solve the same task you're about to answer, independently, and then diffs the two answers. Where you and the fresh session agree, the answer is probably solid; where you disagree, you've found a blind spot to investigate before you commit. It builds on the spawn/report_to mechanics in the ccc-orchestration skill — read that first for the full Spawn/Inject/Ask API.

Cost

1 spawned session. Each spawn is a real billed session on the user's kanban — tell the user the count before spawning. Do not use this for trivial questions (just answer them) or one-shot factual lookups (use the built-in Task tool — it's a subagent, not a billed kanban session).

Setup

CCC_URL="$(cat ~/.claude/command-center/port.txt 2>/dev/null || echo "${CCC_URL:-http://127.0.0.1:8090}")"
curl -sf --max-time 2 "$CCC_URL/api/version" >/dev/null 2>&1 || CCC_URL="http://127.0.0.1:8090"
curl -sf --max-time 2 "$CCC_URL/api/version" >/dev/null 2>&1 || CCC_DOWN=1

• (a) Run every CCC curl with the network sandbox disabled — the Bash

sandbox blocks loopback and fails spuriously even when CCC is up.

• (b) URL-encode `repo_path` in query strings (+ → %2B, space → %20).
• (c) Resolve your own session id: $CLAUDE_SESSION_ID, else the newest

*.jsonl under ~/.claude/projects/<slugified-cwd>/ (see ccc-orchestration).

The one rule: the prompt must be anchor-free

Write the task statement WITHOUT your own conclusion, hypothesis, or preferred approach. The whole value of a second opinion is that it's independent — leak your answer into the prompt and you get an echo, not a check. State the task and what "good" looks like; say nothing about what you think the answer is.

# BAD — anchored (leaks your conclusion, guarantees an echo)
"I think the slow endpoint is the per-row ps fork in _discover_live_session_ids.
 Confirm that's the bottleneck and that caching it fixes the latency."
 
# GOOD — neutral (states task + what good looks like, no answer)
"The /api/sessions list is slow on repos with 1000+ transcripts. Find what makes
 it slow and what would make it fast. 'Good' = a specific code path with evidence,
 not a guess."

Spawning

Resolve your session id, then POST one spawn with the neutral task baked in:

curl -s -X POST "$CCC_URL/api/sessions/spawn" -H "Content-Type: application/json" -d @- <<'JSON'
{
  "prompt": "You are giving an independent second opinion. Task: <neutral task statement, with the relevant file paths and what 'good' looks like — NO hint of what the answer might be>. Investigate from scratch in the repo at /abs/path/to/repo. Do not ask questions; make reasonable assumptions and state them. Report back in this shape: ANSWER (your conclusion), KEY EVIDENCE (files/lines you relied on), CONFIDENCE (high/medium/low), ASSUMPTIONS (anything you had to guess).",
  "repo_path": "/abs/path/to/repo",
  "report_to": "<your-session-id>"
}
JSON

Omit "model" and "reasoning_effort": the server spawn defaults (Settings → Spawn defaults) apply. Pass either explicitly to keep cost down, with "engine" alongside it, since both are validated per engine (see ccc-orchestration § 2 for the per-engine effort ladders). CCC appends the return-address footer for you (report_to), so the fresh session injects its report back to you automatically when it finishes.

Waiting for the report

After spawning, end your turn. Tell the user a second opinion is running and its session id. The report arrives by injection (report_to) — do not poll or sleep-loop. If a report never arrives, check GET /api/sessions/spawned to see whether the child is still alive before assuming it finished silently.

When the report arrives: three-way diff

Do not just pick your own answer. Produce a comparison for the user:

• Where both agree — likely solid; proceed with more confidence.
• Where you disagree — a blind spot. Investigate the disagreement before

acting; the fresh session had no context to bias it, so its dissent is worth real weight.

• What each side saw that the other missed — evidence, files, or edge

cases one of you didn't consider.

Dry run

If the arguments contain dry-run, print the exact payload — session count (1), the full spawn prompt with the neutral task filled in, and the target repo — and POST nothing.

When CCC is down

If CCC_DOWN=1 or the spawn curl returns connection refused (exit 7), fall back to the built-in Task tool (general-purpose agent) with the same neutral, anchor-free prompt. Fresh context is preserved — you lose only kanban visibility. Never pretend the CCC spawn ran.

What this is not

• Not /critique (wt critique spawns two cross-family critics that score a

thing you already made). This is one fresh same-family solve of the same task, diffed against yours — the artifact is the disagreement, not a score.

• Not /code-review — that reads your diff. This re-solves the problem cold.