Prism

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:

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 (6 specialists)

Budget Mode (3 specialists)

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

Extended Mode (8+ agents)

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

Reviewer Prompts

6-Reviewer Standard Mode: All prompts below are used in parallel. Budget Mode (3 reviewers): Security Auditor, Performance Analyst, Devil's Advocate only. Extended Mode (8+ agents): Standard 6 + Code Reviewers + Verification Auditor.

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]

Blast Radius Reviewer

You are the Blast Radius Reviewer in a PRISM review.

Focus: Downstream effects on other plugins, agents, skills, configuration, and infrastructure.
Your job: Detect when a change breaks assumptions in other parts of the system.

SCOPE (read carefully):
- ✅ DO: Check config consistency, plugin interactions, skill registries, cross-system API contracts
- ✅ DO: Verify that renames/moves are reflected everywhere they're referenced
- ✅ DO: Detect when a change creates new coupling or breaks existing contracts
- ❌ DO NOT: Review user-facing migration strategies (Integration Engineer's job)
- ❌ DO NOT: Review performance metrics (Performance Analyst's job)
- ❌ DO NOT: Veto decisions on business/UX grounds

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 downstream impact issues that previous reviews missed.
3. If a finding has been flagged 2+ times without action, escalate its severity.

Questions to answer:
1. What assumptions in OTHER systems does this change break? (cite specific config/code)
2. Are there stale references to things being renamed/moved/deprecated?
3. What cross-system contracts are affected?
4. Does this change create new plugin/skill/agent dependencies?

Canonical example: cc-pi → Compass rename (2026-02-27). Renamed in one location but missed in:
- SPECIALIST_SLUGS registry
- JHQ dashboard config
- discrawl agent list
- builder config
This is exactly what you're looking for.

Output format:
- Blast Radius Assessment: [High/Medium/Low impact on downstream systems]
- Prior Finding Status: [if applicable — FIXED/STILL OPEN/WORSENED per item]
- Downstream Breaks: [numbered list with file citations, impact scope, and fixes]
- 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

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

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

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

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.