named-persona-adversarial-review

---
name: named-persona-adversarial-review
description: Use when automated review findings feel generic, a PR has architectural or UX impact, or the author wants pre-submit hardening via named, sourced engineering philosophies.
category: Engineering
version: 1.0.0
tools: []
---

# Named-Persona Adversarial Review

Abstract-role review ("act as a saboteur") finds abstract problems because the model imagines what a reviewer *might* say. Named engineers with documented, sourced philosophies find problems worth actually fixing — as long as the real principle is cited and no quote is invented.

## Example Output

```
CRITICAL [Torvalds]: Special-case error handling at auth.ts:47 duplicates the
  happy path. Torvalds' documented "good taste" principle: restructure so the
  special case disappears rather than adding a branch. (confidence: high — TED 2016)
WARNING  [Thompson]: parseConfig() does three unrelated things; the Unix
  "do one thing well" principle argues to split it. (confidence: high)
NOTE     [Jobs]: Error "EACCES:13" leaks an errno at the user surface; "start
  from the customer experience" argues for a human message. (confidence: high — WWDC 1997)
Verdict: CONCERNS — fix CRITICAL before merge.
```

## Attribution Discipline (load-bearing rule)

Putting named, real people's principles to work is also a failure mode: language models hallucinate quotes. Stay honest:

1. **Cite the principle, not a fabricated verbatim quote.** Prefer paraphrasing a documented position (e.g. Thompson's *Reflections on Trusting Trust* arguing you can't trust code you didn't fully create) over inventing quotation marks around words the person may never have said.
2. **Attach a confidence level to every attribution** — `high` (documented, sourced), `moderate` (widely attributed, source not pinned), `low`/`unknown` (inferred).
3. **If a persona's lens can't be grounded in a real source, drop that persona.** A confidently-wrong quote attributed to a living engineer is worse than one fewer reviewer. Never fabricate a citation to hit the "≥1 finding" bar.
4. **The finding must stand on its own technical merit.** The persona is a lens that directs attention, not the authority that makes the finding true. A real bug found "through Carmack's lens" is real because it's a bug, not because Carmack said so.

## Rules

- **Ground before role-play.** Anchor each persona in a verifiable source (documented interviews, talks, papers) before applying their lens. Ungrounded = invalid.
- **Findings stand on technical merit**, with the persona's principle as the lens.
- **Product persona mandatory every round.** Engineers miss UX — always include one.
- **Honesty over quantity.** Don't fabricate findings or citations. Clean dimensions get reported clean (with the zero-finding burden below).
- **Zero-finding burden.** "Looks fine" is only valid if you name 3+ principles the code demonstrably satisfies, and how. Non-findings are as expensive as findings.

## Persona Pools

**Product** (pick 1 per round — mandatory):

| Persona | Documented principle | Best for |
|---------|----------------------|----------|
| Steve Jobs | Start from the customer experience, work back to the tech | UX, onboarding |
| Marty Cagan | Fall in love with the problem, not the solution | PRDs, feature specs, scope creep |
| Des Traynor (Intercom) | The first 30 seconds decide adoption | Docs, READMEs, quick starts |

**Engineers** (pick 2 per round):

| Persona | Documented principle | Best for | Blind spot |
|---------|----------------------|----------|------------|
| Ken Thompson | Trust boundaries; do one thing well | Architecture, supply chain, API | UX, docs |
| Linus Torvalds | Eliminate the special case ("good taste"); never break userspace | Logic, data structures, compat | User empathy, DX |
| John Carmack | Measure before you optimize; performance as craft | Algorithms, hot paths | Minimalism |
| Kent Beck | Simple design; make it work → right → fast | Process, testability | Performance, security |
| Fred Brooks | Essential vs. accidental complexity | System design, estimation | Low-level perf |

**Routing (which personas when):**
- Code correctness → Torvalds + Carmack + Jobs
- Architecture/design → Thompson + Brooks + Cagan
- Documentation/API → Thompson + Beck + Traynor
- Performance → Carmack + Torvalds + Jobs
- Security/supply chain → Thompson + Torvalds + Cagan
- First round on any PR → Torvalds + Thompson + Jobs (broadest coverage)

## Severity Levels

| Level | Definition | Action |
|-------|-----------|--------|
| BLOCKER | 2+ personas concur on a CRITICAL, or security/data-loss risk | Fix before any further work |
| CRITICAL | Wrong result, data loss, security hole, or violated core invariant | Fix before merge |
| WARNING | Fragile, misleading, or likely to cause future bugs | Fix, or explain if deferred |
| NOTE | Improvement that doesn't affect correctness | Optional; record for follow-up |

**Promotion:** NOTE → WARNING → CRITICAL → BLOCKER. Two personas independently finding the same issue promotes it one level (concurrence is signal). BLOCKER is the ceiling.

## The Process

**Step 0 — Read twice.** Top-down (comprehension): what changed and why. Bottom-up (adversarial): read function by function, last to first — ask what each function *actually* guarantees vs. what its name implies, where it can fail, and what it assumes about callers. Reading bottom-up breaks the author's mental model. For multi-file changes, trace one end-to-end path.

**Step 1 — Ground the principles first.** For each persona, pull their documented principles from a verifiable source (search "[Name] engineering philosophy principles" and extract only sourced positions) *before* looking at the code, so the principle is applied rather than retrofitted to an opinion already formed.

**Step 2 — Review (3 independent lenses: 2 engineers + 1 product).** Each persona gets: **Mindset** (one sentence from their principles), **Priorities** (3-5 criteria), **Findings** (each mapped to a documented principle + confidence level), or the **zero-finding burden** (3+ principles the code satisfies, with how).

**Step 3 — Synthesize and report.** Merge duplicates; count concurrences; promote per the rule; flag single-lens findings (often the most interesting). Deliver the report in chat, or @mention the PR author/reviewer to hand it off.

## Integrity Check (Feynman)

"The first principle is that you must not fool yourself — and you are the easiest person to fool." — Richard Feynman, *Cargo Cult Science* (Caltech commencement, 1974)

After each round, ask: Would this person's *documented* philosophy actually direct attention here, or is it projection? Was a real, sourced principle cited (confidence marked), or is generic advice dressed in a famous name? Are the findings true on technical merit independent of the name attached? If every finding is NOTE-level, that's one perspective narrated in different voices — switch ≥2 personas and re-review.

## Exit Condition

1 round minimum for any PR. BLOCKER/CRITICAL found → fix, then 1 re-review round. CONCERNS (WARNING) → fix or accept risk, then 1 more round. CLEAN on 2 consecutive rounds → done. CLEAN on round 1 for a low-impact PR → done (1 round is enough).

**Use for:** deeper coverage than standard automated checks; a self-authored PR needing pre-submit hardening; generic review findings that need sourced specificity; methodology/doc reviews (product personas excel here); auth, data, architecture, or public-API changes. **Skip for:** cosmetic-only PRs with no logic change, personas that can't be grounded in a real source, or throwaway/prototype code.

## Anti-Patterns

Inventing a verbatim quote to sound authoritative (cite the sourced principle + confidence, or drop it); "as a senior engineer" without grounding (not a named, sourced lens); same 3 personas every review (rotate per problem type); skipping the mandatory product persona; fabricating a finding to hit "≥1 issue" (the bar is honesty, not quota — use the zero-finding burden); skipping the integrity check (verification without verification is a rubber-stamp); running 3 rounds on a trivial change.

Theoretical grounding: Edward de Bono, *Six Thinking Hats* (1985); Daniel Kahneman, *Thinking, Fast and Slow* (2011) — System-2 forcing via role switching.