# Brains Trust > Use after any non-trivial build, before commit or deploy. Convene two or more frontier models from different families and providers to review the change for Critical/High/Medium/Low findings; fix cross-validated Criticals before commit and Highs before deploy. Also when the same bug won't fix on the first attempt, or for a whole-codebase pass before a release. - Skill: `jezweb/brains-trust` (Agent Skill) - Install (CLI): `npx skillmds@latest add jezweb/brains-trust` - Raw SKILL.md: https://api.skillmd.com/api/skills/jezweb/brains-trust/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: DevOps & Infra - Author: jezweb (https://skillmd.com/u/jezweb) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/jezweb/brains-trust --- # Brains-trust: a panel of other models before you commit Your own review pass, and the model that wrote the code, share blind spots. A panel of two or more frontier models from *different families and providers* catches what a single pass confidently waves through: authz holes, race conditions, platform gotchas. The signal to trust is when reviewers independently flag the *same* thing. (Even a brand-new flagship benefits, no model escapes its own blind spots.) **Convene the panel.** Pick a current frontier model from each major family and run them via different providers, so they're genuinely independent eyes and not the same model twice: for example Anthropic Opus, OpenAI GPT-5.x, Google Gemini 3.x, and strong open models (DeepSeek, Qwen) via OpenRouter, Cloudflare Workers AI, or NVIDIA NIM. Verify the current model ids first (see `verify-current`). **Brief them.** Bundle the changed source plus the goal plus the proof-of-done (or the audit doc) into one prompt. Ask each for findings ranked Critical / High / Medium / Low, each with file-and-line evidence. **Decide by cross-validation, not vote count.** - A finding two or more reviewers independently raise is real. Fix cross-validated Criticals before commit, cross-validated Highs before deploy. - A finding only one reviewer raises is a maybe; weigh it on its evidence. - A claim with no supporting evidence is not a finding. Reject it. Panels produce noise; filtering it is part of the job. **Their findings are input to your judgement, not a to-do list.** The panel sees the diff, not the why, your constraints, the project's context, what's actually happening. So even a cross-validated finding gets checked before you act on it: verify the advice against the current docs (`verify-current`) and judge whether it's right for *this* project, not just correct in the abstract. A confident, agreed-upon suggestion can still be wrong for you. You own the call; the panel only informs it. **The one trap: reviewers can't see the live world.** A "this version/API/model doesn't exist" or "that's deprecated" finding is usually a training-cutoff artifact, and two reviewers agreeing on a stale fact is not evidence, they share the same cutoff. Version and existence claims are verify-live-only: route them to `verify-current`, never let the panel decide them. **Save the panel.** Write the findings, what you fixed, and what you rejected (with reasons) to `/.jez/audits/-brains-trust-.md`, so the rationale survives the session. **When to run it:** after any non-trivial build before commit; a whole-codebase pass before a release; a targeted pass any time the same bug won't fix on the first attempt. The failure this prevents: shipping the authz hole, the race, or the platform gotcha that a single reviewer (you, or the model that wrote it) confidently missed. The panel's independent eyes are the cheapest place to catch it. --- **Going further (optional).** This skill is the doctrine, runnable with whatever models you have. If you'd rather a built-out tool that convenes the panel for you — provider wiring, cost-aware routing, the convergence-table synthesis — [`brainstrust`](https://github.com/jezweb/brainstrust) is a public sibling that implements it. The skill stands alone; this is just where to look for the machinery.