Code review through the lens of real engineers' documented philosophies (Torvalds, Thompson, Carmack, Kent Beck, Jobs, Cagan). Complements abstract-role adversarial review with named, sourced perspectives. Use when automated review findings feel generic, when a PR has
Installs just this skill. Get the whole plugin for auto-invocation.
⚡ How it fires
How this skill gets triggered: by you, by Claude, or both.
Fires itselfClaude auto-loads it when your prompt matches the work.
You can call itInvoke it directly when you want it.
Slash command/named-persona-adversarial-review
👁️ Context preview
The summary Claude sees to decide when to auto-load this skill.
Code review through the lens of real engineers' documented philosophies (Torvalds, Thompson, Carmack, Kent Beck, Jobs, Cagan). Complements abstract-role adversarial review with named, sourced perspectives. Use when automated review findings feel generic, when a PR has
📊 Stats
Stars23,060
Forks3,139
LanguagePython
LicenseMIT
📦 Ships with claude-skills
</> SKILL.md
named-persona-adversarial-review.SKILL.md
---name: "named-persona-adversarial-review"
description: "Code review through the lens of real engineers' documented philosophies (Torvalds, Thompson, Carmack, Kent Beck, Jobs, Cagan). Complements abstract-role adversarial review with named, sourced perspectives. Use when automated review findings feel generic, when a PR has architectural or UX impact, or when the author wants pre-submit hardening beyond standard checks."
---# Named-Persona Adversarial Review
> **TL;DR:** Abstract roles find abstract problems. Named engineers with *documented, sourced* philosophies find problems you would actually fix — as long as you cite the real principle and never invent the quote.
**Triggers:** "review this PR with real engineers" | "named persona review" | "philosophy-grounded review"
## 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.
```
Abstract adversarial review ("act as a saboteur") produces generic findings — the model imagines what a reviewer *might* say. This skill grounds each lens in a **real, sourced engineering philosophy** documented in [`references/persona_principles.md`](references/persona_principles.md): what Ken Thompson actually argued about trust, what Linus actually demonstrated about good taste — not what an AI imagines.
**How it differs from `adversarial-reviewer`:** abstract roles → surface-level findings; named, sourced personas → findings anchored to a documented principle you can cite and defend.
**Cost:** 1 round ≈ 8-12 min. Comparable to waiting for CI.
## Attribution discipline (read this first — it is the load-bearing rule)
This skill puts named, real people's *principles* to work. That power is also its failure mode: **language models hallucinate quotes.** To stay honest:
1. **Cite the principle, not a fabricated verbatim quote.** Prefer paraphrasing a documented position ("Thompson's *Reflections on Trusting Trust* argues 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, in `references/persona_principles.md` with a source), `moderate` (widely attributed, source not pinned), `low`/`unknown` (you're inferring). Mirrors `productivity/andreessen`'s citation discipline.
3. **If you cannot ground a persona's lens 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 `references/persona_principles.md` (or a verifiable search) first. Ungrounded = invalid.
- **Findings stand on technical merit**, with the persona's principle as the lens — see the discipline above.
- **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
Each persona's documented principles + sources + confidence live in [`references/persona_principles.md`](references/persona_principles.md).
**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 |
- 1st 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
1. **Top-down** (comprehension): what changed, and why.
2. **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. Multi-file → trace one end-to-end path.
### Step 1: Ground the principles first
For each persona, pull their documented principles from `references/persona_principles.md` (or search `"[Name] engineering philosophy principles"` and extract only sourced positions) **before** looking at the code, so you apply the principle rather than retrofitting one to an opinion you already formed.
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 & post
Merge duplicates; count concurrences; promote per the rule; flag single-lens findings (often the most interesting). Post the report as a PR comment (default) or save to `.claude/review-[timestamp].md`.
## 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:
1. Would this person's *documented* philosophy actually direct attention here — or am I projecting?
2. Did I cite a real, sourced principle (confidence marked), or dress generic advice in a famous name?
3. Are my findings true on technical merit independent of the name attached?
4. All NOTE-level? Then I'm narrating one perspective 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).
## When to Use
- You want deeper coverage than standard automated checks alone.
- A self-authored PR needs pre-submit hardening.
- `adversarial-reviewer` findings feel generic and you want sourced specificity.
- Reviewing methodologies or docs (product personas excel here).
- Auth, data, architecture, or public-API changes.
## When NOT to Use
- Low-impact PR (cosmetic only, no logic change) → use `adversarial-reviewer`.
- No web access AND the persona isn't covered in `references/persona_principles.md` → you can't ground it; don't fabricate.
- Throwaway / prototype code.
## Anti-Patterns
Inherits all from `adversarial-reviewer`. Plus:
| Anti-Pattern | Why wrong |
|-------------|----------|
| Inventing a verbatim quote to sound authoritative | Fabricated attribution to a real person. Cite the sourced principle + confidence, or drop it. |
| "As a senior engineer" without grounding | Not a named, sourced lens. Ground first. |
| Same 3 personas every time | Rotate per problem type — see Routing. |
| Product person skipped | Product catches what engineers miss. |
| Fabricating a finding to hit "≥1 issue" | The bar is honesty, not quota. Use the zero-finding burden instead. |
| Skipping the integrity check | Verification without verification = rubber-stamp. |
| 3 rounds for a trivial change | Low-impact PRs: 1 round is enough. |
- **Sibling discipline:** [`productivity/andreessen`](../../../productivity/andreessen/skills/andreessen/SKILL.md) — the confidence-level / never-fabricate-a-citation pattern this skill adopts
- **Sources & confidence per persona:** [`references/persona_principles.md`](references/persona_principles.md)
- **Theory:** Edward de Bono, *Six Thinking Hats* (1985); Daniel Kahneman, *Thinking, Fast and Slow* (2011) — System-2 forcing via role switching
---
**Attribution:** Concept contributed by [@YuhaoLin2005](https://github.com/YuhaoLin2005) (PR #866). Hardened for this repo: consolidated to one location, anti-fabrication/confidence discipline added, principles sourced in `references/`.
