From second-opinion
Get an independent review of your thinking before presenting it to the user — from the strongest independent channel the session offers (a full-transcript advisor tool if available, fresh-context reviewers otherwise). Use when you need a fresh take, alternative approaches, or independent validation on a design, plan, code, or any non-trivial decision. Triggers on "second opinion", "another perspective", "ask fable", "independent review", or /second-opinion. Also trigger proactively during the design and plan review phases — before presenting options or a spec.
How this skill is triggered — by the user, by Claude, or both
Slash command
/second-opinion:second-opinionThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Before presenting non-trivial thinking to the user, get an independent review of it. A second opinion is what a second doctor does: look at the situation fresh, form an independent view, say where they agree and where they'd do differently. The output is for *you* — the user sees the result of your improved reasoning, not the raw review.
Before presenting non-trivial thinking to the user, get an independent review of it. A second opinion is what a second doctor does: look at the situation fresh, form an independent view, say where they agree and where they'd do differently. The output is for you — the user sees the result of your improved reasoning, not the raw review.
Bind to the strongest channel available in this session that satisfies all three properties. The properties are fixed; the mechanism is whatever best provides them.
In rough order of preference:
Let the stakes drive depth — a quick sanity check versus a full adversarial pass — not a fixed reviewer count.
If the channel takes the full transcript, let it. If you must distill, include: what's being decided and why it matters; the approach or options on the table; constraints, prior decisions, rejected alternatives; supporting material (code, data, drafts). Don't curate away the parts you're least sure of — those are exactly what a reviewer is for.
However you invoke the reviewer, convey these — verbatim when the channel is a subagent prompt, as framing otherwise:
- You are an independent reviewer, not the decision-maker. Form your own assessment as if coming to it fresh. Agree where you agree, disagree where you disagree — let it emerge from your analysis, not a prescribed adversarial stance.
- Apply clean/correct/elegant: no quick fixes or hacks; ideal-first (what's the right answer with no constraints?); depth over breadth; every alternative strong and elegant for its declared scope.
- Be direct when you disagree — don't hedge or soften genuine pushback. But don't manufacture disagreement either.
- Ground in evidence. Open referenced files, fetch primary sources, web-search current practice and known failure modes. The value of a second opinion is bringing in what the author didn't — not re-processing what they gave you.
When multiple reviewers converge, absorb the confidence. When they fundamentally disagree, that's the most valuable outcome — the decision has tradeoffs you may not have mapped, so dig into the why before deciding. When every reviewer flags the same concern, take it seriously even if you initially dismissed it.
Apply Hold the Line: re-articulate your prior position and the goal it served, then check whether the review refutes the core on the same goal — or merely operates on a different axis. The specific failure mode: a reviewer's "fresh take" silently replaces the problem you were solving rather than critiquing your answer, and you absorb the reframe because it arrived wrapped in confidence. Reframes deserve a harder pass, not a softer one. If the full procedural check would help, run /steel-man-own-position.
Guides collaborative design exploration before implementation: explores context, asks clarifying questions, proposes approaches, and writes a design doc for user approval.
Creates structured, bite-sized implementation plans from specs or requirements before writing code. Useful for breaking down multi-step tasks into testable steps with file structure and task boundaries.
Resolves in-progress git merge or rebase conflicts by analyzing history, understanding intent, and preserving both changes where possible. Runs automated checks after resolution.
npx claudepluginhub pandysp/claude-plugins --plugin second-opinion