Advisor

Advisor

A second opinion from the same model family — even a fresh context — tends to agree with the first opinion more often than a genuinely independent reasoning process would. This skill gets an actual second opinion: a different model provider, asked a precise question, with no obligation to follow its answer.

This is the lightweight, on-demand cousin of codex-judge: codex-judge is a formal, rubric-scored gate for a post-review completion decision; advisor is for anything else — a plan, a hard call, an open question — where you want a genuine outside view but nothing should be auto-approved or auto-rejected.

When to use this

• Before committing to a plan that's expensive or hard to reverse.
• You're stuck between two approaches and want a reasoning process that isn't anchored on the same assumptions you already have.
• The user explicitly asks for "a second opinion" or "what would another model say."
• Not for routine decisions — reserve it for calls where being wrong is costly enough that the extra step earns its keep.

Instructions

1. Write a precise, self-contained brief. The advisor gets nothing from this conversation except what you give it. Include: the goal, the relevant constraints, the actual plan/diff/question, and a specific question — "what am I missing", "is there a simpler approach", "what would break under load" — not a vague "thoughts?". A vague brief gets a vague, unhelpful answer back. See references/brief-template.md.

2. Check what's available. Look for a different-provider CLI (which codex, which gemini, or similar). It must be a genuinely different model family than whatever produced the plan/diff being reviewed — a second instance of the same model isn't independent, however fresh its context.

3. If nothing is available, degrade honestly — don't skip silently. Say plainly that no second-provider access exists. Do one of:

   • a deliberate cold review yourself (see verify-before-done's references/independent-review.md for the cold-read protocol), or
   • hand the user the brief you wrote and let them paste it into another tool themselves.

4. Invoke it and read the response critically. Don't adopt the advisor's opinion uncritically, and don't dismiss it because it's inconvenient. If it disagrees with the current plan, that disagreement is the useful part — surface it explicitly to the user rather than quietly picking a side.

5. Report the opinion and the reconciliation, not just "got a second opinion." State what the advisor said, where it agrees or disagrees with the current approach, and what you're doing as a result (adopting its suggestion, keeping the original approach with a stated reason, or flagging the disagreement for the user to decide).

Edge cases

• The advisor's answer is generic or unhelpful. The brief probably wasn't specific enough — tighten the question and try again rather than reporting a non-answer as "consulted, no issues found."
• The advisor and the reviewer/judge disagree with each other, not just with you. Don't average the opinions — report the actual disagreement; it's signal, not noise.
• This is a routine, low-stakes decision. Don't reach for this — advisor exists for calls where being wrong is expensive, not as a rubber stamp for every plan.

Reference files

• references/brief-template.md — a fill-in-the-blanks template for writing a precise, self-contained brief for the advisor.