Second Opinion

Unified runtime invocation

Resolve the plugin root from this loaded file: SKILL.md is at <plugin-root>/skills/<skill-name>/SKILL.md. Invoke only python3 "<plugin-root>/coordinator.py" and send one bounded JSON routing request on EOF-delimited stdin, without a PTY. Use the Python invocation example in the Routing request section in <plugin-root>/README.md and the co-packaged manifest's signed wire_contract; never invent fields or provider actions. Supply one caller-defined work unit per independently useful deliverable, with this skill's logical action and a bounded opaque payload. Use depends_on only for actual dependencies. Honor an operator-named provider with explicit_target. For an authorized independent review or governance task without an operator-named provider, also use that field to bind the caller-verified distinct reviewer selected by the caller or designated by the workflow. Carry the same target into planning and live dispatch; verify returned native lineage before accepting independence. Otherwise use normal untargeted routing. Choose quality and effort for the workload; include context/output token estimates when known. Read the current manifest digest and actual cwd device/inode; do not copy example values. The runtime owns its timeout; do not wrap it in a shorter fixed timeout. Repository identity, source-head verification, disposable copies, patch capture, and cleanup remain caller-owned where applicable. The shim runs standalone from the installed plugin and transports the routing client's bounded result without semantic interpretation. Never discover a provider executable, reconstruct a raw command, or replay, retry, or fail over a consumed work unit. Provider status, terminal records, receipts, telemetry, and other structured fields are optional diagnostics; none is a content-availability gate. Preserve every returned content record or recovered partial response and interpret it with ordinary model reasoning. Never synthesize approval, authority, or a receipt from process exit or missing diagnostics. A planning-only request sets dispatch_requested=false; a live request sets it true and consumes at most one provider attempt per work unit. Planning reports route eligibility, not live availability or authentication. Report a caller/client failure at that layer; provider state remains unknown unless native evidence establishes it. Content availability and each work unit's execution_status are separate facts.

Second opinion — review with caller-verified independence

A second opinion is an explicitly adversarial read on a piece of the active primary's reasoning by an eligible reviewer whose observed family the caller verifies as distinct. Its job is to expose disagreements and blind spots, not to ratify.

Reviewer independence remains unverified until the caller applies the contract below.

When to use

Use this skill when one or more of the following are true:

• The user explicitly asks for it — "second opinion," "what does the reviewer think," "sanity-check this," "cross-check," "have the reviewer review."
• A commit is imminent and reversal is expensive. Examples: shipping a release, signing a contract, sending a board-deck draft, executing a database migration, approving a clinical-trial amendment, posting an incident retrospective externally.
• The decision is a judgment call where two model families' priors differ usefully — strategy trade-offs, vendor selection, methodology choices, ethics calls, contested interpretations.
• The user appears to want reassurance but has not asked for the contrarian view. Offer it. Validation-shaped questions ("does this sound right?") are usually the moments where an independent read pays off most.

When to skip

Skip this skill when:

• The artifact is a routine lookup or factual query — invoke the underlying console backend (python3 "<plugin-root>/coordinator.py") directly.
• Independent approval is required but no reviewer with known lineage distinct from the primary and artifact author can be established (see Verifier independence below).
• The cost of being wrong is trivially recoverable (a draft no one has seen, a sketch of a sketch). The framing overhead is not worth it.
• The user has already received a second opinion this cycle and is asking for a third — at that point the issue is decision avoidance, not under-scrutiny.

Verifier independence (functional contract)

Independence is caller-verified governance evidence, not a routing guarantee. For independent governance evidence, before dispatch record the observed lineage and source for both the active primary and artifact author. Select a reviewer only when its known lineage is distinct from both. The caller may use provider-free planning to inspect known family evidence. Honor an operator-named provider; do not silently replace it. For an authorized independent review or governance task without an operator-named provider, bind the verified reviewer selected by the caller or designated by the workflow using explicit_target. Carry that same target into planning and live dispatch; untargeted planning does not bind a later live request. If the target becomes unavailable, report it without silent substitution or replay. If no known-distinct eligible reviewer is established, do not dispatch as independent governance; explain the missing lineage or selection evidence. An OpenCode name is transport information, not lineage. Use only a descriptor-admitted review or governance action; never substitute document intent for review.

After the response returns, record the observed reviewer lineage and source. Accept the response as independent governance evidence only when all three lineages are known and the reviewer differs from both the primary and artifact author. A route, provider name, status, receipt, or self-assertion alone does not prove lineage. Preserve unknown lineage as unknown. Do not replay a consumed review to repair missing lineage; retain it only as clearly labelled advisory content.

Procedure

1. Identify the artifact and the stakes

Pin down what is under review (draft email, schema migration, trial protocol section, vendor proposal, architecture diagram, talking points) and what specifically is at risk if it is wrong. If the user has given you a folder full of files or a long thread of context, ask one clarifying question rather than guessing — generic input produces generic critique.

2. Frame the request deliberately

Do not dump the artifact at the reviewer with a vague "thoughts?" — that produces flattery-shaped paragraphs. Ask for four specific things:

• The single strongest counter-argument to whatever the artifact concludes or proposes.
• Concrete risks and failure modes — what actually breaks, where, and under what conditions.
• Unsupported assumptions — claims the artifact relies on without evidence, especially load-bearing ones the author may not have noticed they were making.
• A calibrated confidence rating on the artifact's recommendation, with a one-sentence reason.

3. Call the panel — in parallel

Send the same framed request (the four-section template below) to every available cross-family panelist at once, not sequentially — the reads are independent, so issue them concurrently and collect all responses before synthesizing. Each panelist gets the identical artifact + template, so their outputs are directly comparable.

Build the panel from reviewers whose observed lineage is known and differs from both the recorded primary and artifact author. A route result does not establish that fact. If no known-distinct eligible reviewer can be established, do not dispatch an independent governance review; explain the missing lineage or selection evidence. A raw binary or legacy plugin is never a route. Host-owned async coordination is supplementary advisory content, never a managed review panelist. Callers must not bypass the managed route with a raw claude -p invocation.

For every panelist and tiebreaker, select the reviewer before dispatch and verify its observed lineage after the response. Do not replay a consumed review to repair incomplete lineage evidence. Hold one known-distinct eligible reviewer as the tiebreaker rather than including it in the first wave.

Use one documented routing work unit for each panelist with quality_profile="frontier" and effort_class="maximum"; never name a model member. The caller seals and verifies the exact repository head, supplies the bounded review prompt as opaque payload, and rechecks that head before using the response.

Use frontier quality with maximum effort through an eligible provider for slow, skeptical analysis. The economical, minimal-effort profile optimizes for throughput rather than finding objections. Ensure each panelist receives the whole artifact — a divergence that is actually an artifact of one model truncating the context is a false signal, not a real disagreement.

Use this prompt template for review content. Provider formatting is not an output contract; the caller reasons over the complete raw response:

Review the following [artifact type, e.g. "architecture proposal", "trial protocol amendment", "vendor MSA redline"]. In the descriptor-owned summary and findings, cover the strongest counter-argument, specific risks or failure modes, unsupported assumptions, and confidence. Cap substantive review text at 350 words.

--- ARTIFACT ---
[paste the full artifact verbatim]

Read the complete nonempty raw response and deduce the best-supported operative verdict. Preserve mixed prose, wrappers, and partial content; never fabricate an artifact or replay for formatting. One panelist's diagnostics do not invalidate content returned by other panelists.

3b. Tiebreaker — only on a conflicting verdict

After the parallel panel returns, decide whether a tiebreaker is needed. Invoke an eligible independent managed reviewer only when the panel is in genuine verdict conflict:

• Trigger: the panelists reach opposing bottom-line conclusions — e.g. one lands on a confident "this is sound / proceed" while another lands on "this is unsound / do not proceed" — OR one panelist flags a load-bearing risk (a critical architectural / security / correctness defect) that another explicitly dismisses or did not surface. Resolving which read is right is high-stakes and a neutral third family earns its cost here.
• NOT a trigger: panelists broadly agree on the verdict but list different, additive risks. Aggregate the union and move on; do not add a third reviewer.
• A tiebreaker is selected dynamically from the remaining eligible distinct- family advisory routes and receives the same template plus conflicting reads.

If no eligible independent tiebreaker is reachable, surface the unresolved conflict to the operator; never fabricate a resolution.

4. Synthesize — high-water-mark of risk, never consensus

When you relay the panel to the user, the cardinal rule is never average the reads into a softer middle, and never let a 2-of-N "agree" lull the decision. Operate on a high-water-mark of risk: surface the union of all identified risks, led by the single sharpest concern raised by any panelist — even if only one panelist raised it and the others said "proceed." If one verifier issues a confident PROCEED and another a sharp RECONSIDER, the RECONSIDER's load-bearing objection leads; it is not netted against the PROCEED.

Surface the raw reads — do not paraphrase them into compliance. Present each panelist's artifact summary and sharpest findings, attributed by name, so the operator sees the actual critiques and not the authoring model's softened summary of critiques of its own work. Lead with divergence across the panel, not agreement; quote the sharp objections directly.

A useful structure for the user-facing report:

Panel: (dynamic tiebreaker: <route + verdict | not needed | unavailable>).

Sharpest concern (high-water mark): <the single most load-bearing objection from any panelist, attributed, quoted>.

Where the panel diverges: <conflicting verdicts/risks, attributed> — and, where used, how the dynamic tiebreaker resolved it.

Union of risks / assumptions flagged: <aggregated across panelists, deduplicated, attributed where it matters>.

Panel confidence: <each panelist's H/M/L>. Where the panel agrees with the active primary: <briefly, last>.

5. Adjudicate, then close

Finish with a short synthesis paragraph that calls the question for the user. Which of the panel's points are load-bearing — i.e., should change the artifact or the decision? Which are noise the user can set aside? What, if anything, should be revised before commit? A cross-check that ends "here is what the panel said" without an adjudication has pushed the synthesis work back onto the user; do not stop there. The operator remains the final gate on any consequential or irreversible decision — the panel informs, it does not decide.

Structured-artifact review lens

When the artifact under review is a structured change — configuration, schema migration, infrastructure-as-code, policy, pipeline definition, RBAC ruleset — rather than free-form prose, augment the prompt with a domain-agnostic checklist. These categories have empirically caught real defects across many invocations:

1. Syntax errors — version-skew with deployed tool, deprecated flags, wrong predicate form, missing required field, malformed escape.
2. Race conditions and ordering hazards — assumed sequencing that is not actually enforced, optimistic locks against pessimistic writers, hardcoded paths to files written by another process.
3. Scope overreach — selectors, globs, or regexes that catch more than intended (Resource: "*", match: '.*', host: '*', wildcard kind: selectors).
4. Excessive privilege — root or admin credentials where scoped tokens would work, blanket roles where named permissions would, no-auth paths where minimum auth is feasible.
5. Missing or untested rollback — no documented revert command, no pre-state snapshot, no test of the revert path under load.
6. Inadequate idempotency — re-running the change breaks rather than no-ops, resources leak on retry, partial-failure state is not safely resumable.
7. Cross-system implication blind spots — change in system A breaks a consumer in system B that was not audited (a column drop that an analytics pipeline reads, a network ACL change that an external monitor depends on, a schema rename a downstream report binds to).

Append this addendum to the standard prompt for structured-change reviews:

This is a STRUCTURED CHANGE (configuration / schema / IaC / policy / pipeline), not free-form prose. In your RISKS / FAILURE MODES section, check explicitly for each of these categories and call any that surface:

1. Syntax errors (version-skew, deprecated flags, wrong predicate form)
2. Race conditions and ordering hazards
3. Scope overreach (broad selectors that catch more than intended)
4. Excessive privilege (full credentials where scoped suffice)
5. Missing or untested rollback
6. Inadequate idempotency (re-run breaks instead of no-op)
7. Cross-system implications (consumers in other systems that bind to the changed surface)

For each category that surfaces a real concern, include one bullet with a one-line explanation.

Examples across domains

The skill is domain-agnostic. A representative sample of where independent cross-family review pays off:

When picking the right example to share with the user mid-invocation, match the user's domain — not the operator's. The skill works the same way regardless of subject matter; the framing should meet the user where they are.

Anti-patterns

• Dumping the artifact with no framing. "Thoughts?" produces vague, polite output. The four-section template exists for a reason.
• Using this for trivia or quick lookups. Call python3 "<plugin-root>/coordinator.py" directly. The framing overhead and pro-tier latency are not worth it for "what does X mean."
• Treating the reviewer as an oracle. A second opinion is one more input, not adjudication. The synthesis step is non-optional — the agent owes the user a call, not a relay.
• Burying disagreements under polite framing. "Mostly agreed, with some minor notes…" defeats the entire purpose. Lead with disagreement; quote directly.
• Averaging a panel into consensus. With more than one verifier the tempting failure is to net a sharp RECONSIDER against a confident PROCEED into a comfortable "PROCEED-WITH-MODIFICATIONS." Do not. A panel's value is the union of its catches, not the intersection of its agreements; one verifier's load-bearing objection is not diluted by the others missing it. A 2-of-3 "looks fine" is not a safety signal — surface the lone dissent at full strength (high-water-mark rule).
• Paraphrasing the panel's critiques of your own work. When the authoring model summarizes the verifiers' objections, it tends — even unintentionally — to soften the sharpest ones. Surface the raw four-section reads (or faithful direct quotes), attributed; let the operator see the actual critiques.
• Firing a tiebreaker on agreement. A tiebreaker resolves a verdict conflict; it does not ratify a panel or adjudicate additive compatible notes.
• Claiming independent review without observed lineage. When the reviewer shares the author or primary family, or lineage is unknown, retain the response as advisory and keep required independent approval unmet.
• Reviewing a structured config diff with the generic four-section template only. Invoke the structured-artifact lens above — the recurring failure categories catch defects the generic template will miss.
• Replaying for formatting. Preserve every nonempty raw response and reason over it; a second attempt is not a formatting repair. Do not issue a second request or fabricate structure around the prose.
• Running this against a draft the user has already revised three times based on prior cross-checks. At that point, the decision-quality issue is no longer "needs more critique" — it is "needs a decision." Say so.