second-opinion-review

name	second-opinion-review
description	WHEN: Implementation or a plan is done and you want a structured second pass from another model or reviewer before merge — same repo, no new automation required.
type	flexible
requires	["forge-trust-code"]
version	1.0.0
preamble-tier	3
triggers	["second opinion","another model review","dual review"]
allowed-tools	["Bash","Read"]

second-opinion-review

Use this after your primary implementation pass and after you would normally invoke forge-trust-code. It does not replace spec review; it adds an explicit independent reasoning pass so obvious gaps are not missed because one session anchored on the same assumptions.

Review Skill Roles at a Glance

Skill	Mandatory?	When to invoke	Output
forge-trust-code	YES	After implementation, before eval — reviewer reads actual diff	Spec compliance verdict (PASS/FAIL)
second-opinion-review	No (recommended for high-stakes)	After forge-trust-code passes, when a second perspective is valuable	Independent reasoning pass — confirms or flags concerns
review-readiness	YES	Immediately before PR creation	All gates passed checklist (eval GREEN, tests passing, no open TODOs)

When to use this skill (second-opinion-review): When forge-trust-code has passed but the change is high-risk (security-sensitive, cross-service contract, performance-critical). A second reviewer reads the same diff independently, without seeing the first reviewer's conclusions.

Anti-Pattern Preamble

Rationalization	Why it fails
"I'll just ask the same model again"	Same context window, same biases. A second pass only helps if the prompt or reviewer changes materially.
"Second opinion = slower, skip it"	Cheaper than a revert. Scope it: one file, one risk area, or one contract slice.
"I'll merge and fix if reviewers complain"	Post-merge fixes cost more than a 10-minute focused second read on hot paths.

Workflow

1. Freeze inputs: Point the reviewer at exact commit SHA, diff or file list, and the locked PRD path (prd-locked.md) plus any shared-dev-spec excerpt that matters.
2. Scope the question: One primary question (for example: "Are error paths and idempotency claims in the API contract actually implemented?").
3. Run the second pass: Different model or human or same model with explicit instruction: "Do not trust the prior summary; verify from files."
4. Record outcome: If anything changes, log it with forge-brain-persist (what was missed, what you fixed).

Checklist (reviewer)

• Claims in PR description match files touched.
• Security-sensitive paths (auth, input validation, secrets) double-checked.
• Contracts (API, events, DB) aligned with council-locked spec, not just "works locally."

Escalate vs proceed

After the checklist, apply this decision table — do not leave it to judgment call alone:

Condition	Action
All checklist items Pass	Proceed to merge.
Any Gap in auth, authz, or contract alignment	Block merge. Open a NEEDS_COORDINATION item per forge-glossary and resolve before merge.
Any Gap in non-critical paths (logging, copy, non-auth error messages)	Log with forge-brain-persist (what was missed, follow-up task id). Proceed with the tracked item.
≥ 2 Gaps of any kind	Block merge regardless of individual severity — multiple small gaps compound at runtime.

Relationship to conductor

conductor-orchestrate still owns phase order. This skill is an optional adjunct before merge when stakes or ambiguity are high.

Cross-References

• conductor-orchestrate: Orchestrates the pipeline phases; second-opinion-review is an optional adjunct invoked before merge when stakes or ambiguity are high.
• spec-reviewer: First-pass code review; second-opinion-review provides an independent perspective after spec-reviewer has passed.
• code-quality-reviewer: Code quality audit; second-opinion-review can serve as a final check when code-quality-reviewer surfaced concerns.
• forge-eval-gate: Eval gate before merge; second-opinion-review is a peer review safeguard complementary to eval.