| 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
- 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.
- Scope the question: One primary question (for example: "Are error paths and idempotency claims in the API contract actually implemented?").
- Run the second pass: Different model or human or same model with explicit instruction: "Do not trust the prior summary; verify from files."
- Record outcome: If anything changes, log it with
forge-brain-persist (what was missed, what you fixed).
Checklist (reviewer)
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.