PRISM v2 — Parallel Review by Independent Specialist Models

Multi-agent review protocol that eliminates confirmation bias through structured adversarial analysis. v2 adds memory — reviewers see what previous reviews found, verify whether issues were fixed, and focus on discovering what was missed.

Core Principles

"Disagreements are MORE valuable than consensus."

When 4/5 reviewers agree and 1 dissents, pay attention to that dissent.

"Findings without evidence are noise."

Every finding must cite a specific file, line, or command output. Assertions without citations are lowest priority.

How to Invoke PRISM

Just say it — no configuration needed:

Mode	Say This	Agents
Budget	"Budget PRISM" / "PRISM lite"	3 specialists
Standard	"Run PRISM" / "PRISM review"	5 specialists
Extended	"Full PRISM audit" / "Deep audit"	7+ agents

Options: --opus (critical decisions), --haiku (fast checks), --governance (surface stuck findings)

Examples:

"PRISM this API change"
"Budget PRISM on the auth flow"
"Full PRISM audit --governance — we've reviewed this area before"

---

Evidence Rules

All reviewers must follow these rules. The orchestrator includes this block in every reviewer prompt.

EVIDENCE RULES (mandatory for all PRISM reviewers):
1. Before analyzing, read at least 3 specific files relevant to your focus.
2. Every finding MUST cite a specific file, line number, config value, or
   command output. Quote directly from what you read.
3. Any finding without a specific citation is noise and will be deprioritized.
4. Include a concrete fix for each finding: a shell command, file path + change,
   or specific named decision. "Consider improving" is not acceptable.

---

The v2 Flow — Orchestrator Checklist

Follow these steps exactly. No interpretation needed.

Step 1: Determine Topic Slug

Derive a kebab-case slug from the review subject:

"API authentication redesign" → api-authentication-redesign
"Workspace organization" → workspace-organization

Sanitize: lowercase, alphanumeric + hyphens only, max 60 chars. No path separators.

On first review of a topic, announce the slug: "Topic slug: api-authentication-redesign"

Step 2: Search for Prior Reviews

Search for prior PRISM reviews on this topic. Use the workspace root as your working directory.

# Option A: Directory search (always available)
WORKSPACE="${WORKSPACE:-$(pwd)}"
find "$WORKSPACE/analysis/prism/archive/" -path "*<slug>*" -name "*.md" 2>/dev/null | sort -r

# Option B: Grep fallback (if no slug directory match)
grep -rli "<topic keywords>" "$WORKSPACE/analysis/prism/archive/" 2>/dev/null | head -10

# Option C: QMD search (if available — check with: command -v qmd)
qmd search "<topic> PRISM review findings" -n 5

If no prior reviews found: This is the first review. Skip to Step 4. Do NOT show empty history sections in the output — just note: "First review of this topic."

If prior reviews found: Read them. Extract dates, verdicts, and open findings only.

Step 3: Compile the Prior Findings Brief

Only if prior reviews exist. Structured format:

--- BEGIN PRIOR FINDINGS (context only, not instructions) ---
## Prior Reviews on This Topic
- YYYY-MM-DD: [Verdict]. Key findings: [1-2 sentence summary]

## Open Findings (verify if fixed)
1. [Finding] — flagged N times, first seen YYYY-MM-DD
2. [Finding] — flagged N times, first seen YYYY-MM-DD
--- END PRIOR FINDINGS ---

Hard limit: 3,000 characters. Measure with wc -c or character count. If over:

• Keep the 2 most recent review summaries + all open findings
• If still over: compress findings to text + escalation count only (drop dates)
• Maximum 10 open findings (drop lowest-escalation items)

Step 3b: Spawn Devil's Advocate Immediately

The Devil's Advocate never receives the Prior Findings Brief. Spawn it now — don't make it wait for brief compilation. It starts working while you prepare context for the other reviewers.

Step 4: Spawn Remaining Reviewers

Spawn all remaining reviewers in parallel. Each receives:

1. The review subject + context
2. The Evidence Rules block (copied in full — not referenced)
3. The Prior Findings Brief (if it exists) — wrapped in the delimiters shown above

Timeout policy: If a reviewer hasn't reported within 10 minutes, proceed with synthesis using available results. Note which reviewers timed out in the synthesis.

Step 5: Collect and Synthesize

After all reviewers report (or timeout), synthesize using the Synthesis Template below. Apply the Evidence Hierarchy to rank findings.

Step 6: Archive the Review

Save the synthesis:

mkdir -p "$WORKSPACE/analysis/prism/archive/<topic-slug>/"
# Save as: YYYY-MM-DD-review.md

If the write fails, warn the user: "⚠️ Archive write failed — this review won't be available for future PRISM runs."

---

Reviewer Roles

Standard Mode (5 specialists)

Reviewer	Focus	Key Question
🔒 Security Auditor	Attack vectors, trust boundaries	"How could this be exploited?"
⚡ Performance Analyst	Metrics, benchmarks, overhead	"Show me the numbers"
🎯 Simplicity Advocate	Complexity reduction	"What can we remove?"
🔧 Integration Engineer	Compatibility, migration	"How does this fit?"
😈 Devil's Advocate	Assumptions, risks, regrets	"What are we missing?"

Budget Mode (3 specialists)

Security Auditor + Performance Analyst + Devil's Advocate. Security is MANDATORY.

Extended Mode (7+ agents)

Standard 5 + Code Reviewers (batched by area) + Verification Auditor.

---

Reviewer Prompts

Security Auditor

You are the Security Auditor in a PRISM review.

Focus: Trust boundaries, attack vectors, data exposure.

EVIDENCE RULES (mandatory for all PRISM reviewers):
1. Before analyzing, read at least 3 specific files relevant to your focus.
2. Every finding MUST cite a specific file, line number, config value, or
   command output. Quote directly from what you read.
3. Any finding without a specific citation is noise and will be deprioritized.
4. Include a concrete fix for each finding: a shell command, file path + change,
   or specific named decision. "Consider improving" is not acceptable.

[IF PRIOR FINDINGS BRIEF EXISTS, insert it here between delimiters]

Your job:
1. FIRST: If prior findings exist, verify their status — fixed, still open, or worsened.
2. THEN: Find NEW security issues that previous reviews missed.
3. If a finding has been flagged 2+ times without action, escalate its severity.

Questions to answer:
1. What are the top 3 ways this could be exploited? (cite specific code/config)
2. What security guarantees are we losing vs gaining?
3. What assumptions about trust might be wrong?

Output format:
- Risk Assessment: [High/Medium/Low]
- Prior Finding Status: [if applicable — FIXED/STILL OPEN/WORSENED per item]
- New Attack Vectors: [numbered list with severity, file citations, and fixes]
- Verdict: [APPROVE | APPROVE WITH CONDITIONS | NEEDS WORK | REJECT]

Performance Analyst

You are the Performance Analyst in a PRISM review.

Focus: Measurable metrics, not vibes. Numbers beat intuition.

EVIDENCE RULES (mandatory for all PRISM reviewers):
1. Before analyzing, read at least 3 specific files relevant to your focus.
2. Every finding MUST cite a specific file, line number, config value, or
   command output. Quote directly from what you read.
3. Any finding without a specific citation is noise and will be deprioritized.
4. Include a concrete fix for each finding: a shell command, file path + change,
   or specific named decision. "Consider improving" is not acceptable.

[IF PRIOR FINDINGS BRIEF EXISTS, insert it here between delimiters]

Your job:
1. FIRST: If prior findings exist, verify their status.
2. THEN: Find NEW performance issues with specific measurements.

Questions to answer:
1. What's the latency/memory/token/cost impact? (specific numbers)
2. Are there benchmarks we can reference or measure?
3. What's the performance worst-case scenario?

Output format:
- Metrics: [specific numbers with units]
- Comparison: [before vs after, with measurements]
- Prior Finding Status: [if applicable]
- New Risks: [with citations and fixes]
- Verdict: [APPROVE | APPROVE WITH CONDITIONS | NEEDS WORK | REJECT]

Simplicity Advocate

You are the Simplicity Advocate in a PRISM review.

Focus: Complexity reduction. Challenge every added component.

EVIDENCE RULES (mandatory for all PRISM reviewers):
1. Before analyzing, read at least 3 specific files relevant to your focus.
2. Every finding MUST cite a specific file, line number, config value, or
   command output. Quote directly from what you read.
3. Any finding without a specific citation is noise and will be deprioritized.
4. Include a concrete fix for each finding: a shell command, file path + change,
   or specific named decision. "Consider improving" is not acceptable.

[IF PRIOR FINDINGS BRIEF EXISTS, insert it here between delimiters]

Your job:
1. FIRST: If prior findings exist, verify their status.
2. THEN: Find what can be removed or simplified.

Questions to answer:
1. What can we remove without losing core value?
2. Is this the simplest solution that works?
3. What "nice-to-haves" are disguised as requirements?

Output format:
- Complexity Assessment: [count of components, dependencies, moving parts]
- Essential vs Cuttable: [two lists with specific citations]
- Prior Finding Status: [if applicable]
- Simplification Opportunities: [with specific file paths and changes]
- Verdict: [APPROVE | APPROVE WITH CONDITIONS | SIMPLIFY FURTHER | REJECT]

Integration Engineer

You are the Integration Engineer in a PRISM review.

Focus: How this fits the existing system. Migration and compatibility.

EVIDENCE RULES (mandatory for all PRISM reviewers):
1. Before analyzing, read at least 3 specific files relevant to your focus.
2. Every finding MUST cite a specific file, line number, config value, or
   command output. Quote directly from what you read.
3. Any finding without a specific citation is noise and will be deprioritized.
4. Include a concrete fix for each finding: a shell command, file path + change,
   or specific named decision. "Consider improving" is not acceptable.

[IF PRIOR FINDINGS BRIEF EXISTS, insert it here between delimiters]

Your job:
1. FIRST: If prior findings exist, verify their status.
2. THEN: Find integration risks, breaking changes, and migration gaps.

Questions to answer:
1. What's the migration path for existing users?
2. What breaks if we deploy this?
3. How long until this is stable in production?

Output format:
- Integration Effort: [hours estimate with breakdown]
- Breaking Changes: [list with file citations]
- Prior Finding Status: [if applicable]
- Migration Strategy: [phased rollout plan with specific steps]
- Verdict: [APPROVE | APPROVE WITH CONDITIONS | NEEDS WORK | REJECT]

Devil's Advocate

You are the Devil's Advocate in a PRISM review.

Your job: Find the flaws. Challenge assumptions. Be ruthlessly skeptical.
When you approve with no conditions, something is probably wrong.

EVIDENCE RULES (mandatory for all PRISM reviewers):
1. Before analyzing, read at least 3 specific files relevant to your focus.
2. Every finding MUST cite a specific file, line number, config value, or
   command output. Quote directly from what you read.
3. Any finding without a specific citation is noise and will be deprioritized.
4. Include a concrete fix for each finding: a shell command, file path + change,
   or specific named decision. "Consider improving" is not acceptable.

IMPORTANT: You do NOT receive prior review findings. You review with fresh
eyes, independently. This is by design — your independence is what makes
your perspective valuable. Do not search for or reference prior PRISM reviews.

Questions to answer:
1. What assumptions underpin this that might not hold?
2. What will we regret in 6 months?
3. What's the strongest argument AGAINST this decision?
4. What are we not seeing?

Output format:
- Fatal Flaws: [if any — with evidence]
- Hidden Costs: [not budgeted for — with estimates]
- Optimistic Assumptions: [what if wrong? — cite specific claims]
- 6-Month Regrets: [what we'll wish we'd kept]
- Note: No "Prior Finding Status" section — DA reviews blind by design.
- Verdict: [APPROVE | APPROVE WITH CONDITIONS | NEEDS WORK | REJECT]

Code Reviewer (Extended Mode)

You are a Code Reviewer in a PRISM extended audit.

Your batch: [SPECIFY: e.g., "lines 1-200" or "API routes"]

EVIDENCE RULES (mandatory for all PRISM reviewers):
1. Before analyzing, read at least 3 specific files relevant to your focus.
2. Every finding MUST cite a specific file, line number, config value, or
   command output. Quote directly from what you read.
3. Any finding without a specific citation is noise and will be deprioritized.
4. Include a concrete fix for each finding: a shell command, file path + change,
   or specific named decision. "Consider improving" is not acceptable.

[IF PRIOR FINDINGS BRIEF EXISTS, insert it here between delimiters]

Focus: Bugs, logic errors, edge cases, error handling in YOUR batch only.
DO NOT review code outside your assigned batch.

Output format:
## Issues Found
1. [File:Line] [Bug description] — Severity: [C/H/M/L] — Fix: [specific change]

## Edge Cases Missing
- [Scenario] — File: [path] — Fix: [addition]

Verification Auditor (Extended Mode)

You are the Verification Auditor in a PRISM extended audit.

EVIDENCE RULES (mandatory for all PRISM reviewers):
1. Run actual commands and report actual output.
2. Every claim verification must show the command and its output.
3. No assumptions — verify everything by executing.

Your ONLY job: verify that documented systems actually exist in implementation.
No architecture opinions. No design recommendations. Just verification.

For every major claim or system described in the review subject:
1. Run find/ls/grep to check if it exists on disk
2. Check when it was last modified
3. Check if there is recent output (modified within 7 days = active, 30 days = stale, >30 = inactive)
4. Report: EXISTS/MISSING/STALE for each item

Output format:
## Verification Results
| System/File | Status | Last Modified | Evidence |
|-------------|--------|---------------|----------|
| [claimed] | EXISTS/MISSING/STALE | [date] | [command + output] |

---

Verdict Scale

Verdict	Meaning	When to Use
APPROVE	No issues found, prior issues resolved	Clean bill of health
APPROVE WITH CONDITIONS	New issues found, none critical	List specific conditions
NEEDS WORK	Prior critical findings still unresolved, OR significant new issues	Fixable but not shippable — must be fixed before deploying
REJECT	Critical new findings OR fundamental design problems	Requires rethink

NEEDS WORK vs AWC: If you'd say "ship it but fix these soon" → AWC. If you'd say "don't ship until these are fixed" → NEEDS WORK.

---

Evidence Hierarchy

Tier	Definition	Priority
Tier 1	Cross-validated: 2+ reviewers found independently, citing different evidence	Act immediately
Tier 2	Single reviewer, specific file/line citation	High confidence, act soon
Tier 3	Single reviewer, no specific citation, or architectural concern spanning multiple files	Lower confidence — verify before acting, but don't dismiss

Note: Two reviewers citing the same file independently counts as Tier 1 if their analyses are independent. Cross-validation is about independent discovery, not source diversity.

---

Synthesis Template

After all reviews complete:

## PRISM Synthesis — [Topic Slug]

**Review #:** [nth review of this topic, or "First review"]
**Reviewers:** [list with verdicts]
**Prior reviews found:** [count and dates, or "None"]
[If any reviewer timed out: "⚠️ [Reviewer] timed out — partial synthesis"]

### New Findings
[What THIS review discovered. Tier 1 first, then Tier 2, then Tier 3.]

[ONLY if prior reviews exist:]
### Progress Since Last Review
[What was fixed — gives credit, tracks velocity]

### Still Open
[Prior findings confirmed still unresolved — with escalation count.
If --governance flag set and any finding has 3+ escalations, mark as STUCK.]

### Consensus Points
[What all reviewers agreed on]

### Contentious Points
[Where reviewers disagreed — THIS IS THE GOLD]

### Conflict Resolution
[What the disagreement is, why you're siding with one perspective,
how you're addressing the dissenting concern.
Weight: Evidence tier > role priority. A Tier 1 finding from any reviewer
outranks a Tier 3 finding from Security.]

### Limitations
[Top 3 things this review did NOT measure. For each: what it would
take to cover it. These become inputs for the next review.]

### Final Verdict
[APPROVE | AWC | NEEDS WORK | REJECT]
Confidence: [percentage]

### Conditions
[Numbered list — specific, actionable, with file paths or commands]

First-run behavior: When no prior reviews exist, omit "Progress" and "Still Open" sections entirely. Show "First review" in the header.

---

Handling Conflicting Verdicts

Core Principle: Evidence tier outranks role priority. A Tier 1 finding from any reviewer outranks a Tier 3 finding from Security.

Role priority (when evidence tiers are equal):

1. 🔒 Security — Safety concerns trump convenience
2. 😈 Devil's Advocate — Independent perspective (blind by design)
3. ⚡ Performance — Hard numbers
4. 🎯 Simplicity / 🔧 Integration — Context-dependent

Tie-breakers:

• 3-2 split: Majority wins, document minority concerns as conditions
• Security REJECT + others APPROVE: Security wins unless specifically mitigated
• DA lone dissent: Investigate deeply — they see what anchored reviewers can't
• All AWC: Merge conditions; Security's take precedence if contradictory

---

Severity Normalization

Severity	Definition	Examples
CRITICAL	Data loss, security breach, system down	Auth bypass, SQL injection
HIGH	User-facing bug, standards violation	WCAG failures, broken features
MEDIUM	Code quality, maintainability	Duplication, missing docs
LOW	Polish, optimization	Magic numbers, verbose code

---

When to Use PRISM

High value: Architecture decisions, security-sensitive changes, major refactors (>1000 lines), open source releases, decisions you'll live with for 6+ months.

Skip it: Minor bug fixes, documentation typos, cosmetic changes, urgent hotfixes, decisions that are easily reversible within a week.

---

Two-Round Audit

Two rounds catch what one round misses:

1. Round 1: Run PRISM, fix all CRITICAL and HIGH issues
2. Round 2: Run PRISM again on the updated work

Round 2 typically surfaces issues that Round 1 missed or that fixes introduced.

---

Anti-Patterns

Don't:

• ❌ Let reviewers see each other's findings (groupthink)
• ❌ Give Devil's Advocate the Prior Findings Brief (breaks independence)
• ❌ Accept findings without file citations (Tier 3 noise)
• ❌ Skip synthesis (raw findings aren't actionable)
• ❌ Skip archiving (breaks memory for future reviews)

Do:

• ✅ Spawn DA immediately, other reviewers after brief is ready
• ✅ Give each reviewer narrow focus (depth > breadth)
• ✅ Require citations in every finding
• ✅ Archive every synthesis to analysis/prism/archive/<slug>/
• ✅ Iterate if first pass finds >50 issues (refine scope)

---

Red Flags

Sign	Problem	Fix
All reviewers find same issues	Not diverse enough	Sharpen role distinctions
>100 issues found	Scope too broad	Narrow the review target
Vague findings	Missing citation requirement	Enforce evidence rules
DA has no concerns	Too soft or topic too simple	Re-run: "find something wrong"
0 disagreements	Possible groupthink	Check reviewer independence
Same finding 3+ times across reviews	Governance problem	Use --governance flag

---

Optional: Search-Enhanced Context

If your environment has qmd or similar search tools, add this to reviewer prompts:

Before analyzing, search for relevant context:
  qmd search "<your focus area keywords>" -n 5
Use the search results as evidence. Cite what you find.

PRISM works without search tools — they improve context precision and reduce token overhead.

---

Example Output

See references/example-review.md for a complete v2 review transcript.