# Using Code Review Personas in Claude Code > [!question] Lingering Questions > - Does the generated persona's Expertise section stay accurate as a project's dependencies change, or does it need the same re-generation discipline the article criticizes hand-copied personas for lacking? > - What happens when two personas (Security, Performance) disagree on the same line of a diff — is there any reconciliation mechanism, or is that left entirely to the developer? > - Could the read-confirm-commit pattern generalize to other Claude Code skills that generate config or scaffolding on a developer's behalf, beyond persona generation specifically? > [!tip] Article Ideas > - Generate a Security Reviewer persona against one owned WordPress plugin repo and diff its criteria against the existing `wordpress-security` skill's Security Trinity checklist. > [!link] Cross Reference > - [[3. Resources/MOCs/AI & the Future of Knowledge Work MOC]] — a small, concrete instance of agent-tooling craft: giving an AI reviewer a stated point of view instead of a generic one > - [[3. Resources/Literature Notes/Navigating Claude Code Subagents Done Right]] — adjacent Claude Code workflow-craft piece; that one scopes what a subagent returns, this one scopes what stance a reviewer takes > - [[3. Resources/Literature Notes/Keep Claude Code Up to Date on Time and Date (Tom McFarlin)]] — same author, same practitioner-blog register > [!quote] Vocabulary > - **Review persona** — a markdown document instructing Claude to adopt a specific reviewer identity (Role, Expertise, Review Criteria, Voice), giving an otherwise stakeless generalist reviewer a stance and domain knowledge to review from ## Bib capsule Tom McFarlin, "Using Code Review Personas in Claude Code," tommcfarlin.com, 2026 — https://tommcfarlin.com/code-review-personas-in-claude-code/ ## Author's thesis (Q1+Q2) Claude Code's default review reads as a "smart generalist with no particular stake in your stack" — it names the shape of a problem without committing to specifics, because nothing in the prompt assigns it a domain or a point of view. McFarlin's fix is the review persona: a short markdown contract (Role, Expertise, Review Criteria, Voice) that gives the model a stance before it opens a diff, paired with a linked skill (`claude-code-persona-generator`) that reads the actual codebase and drafts that contract instead of the developer hand-copying a template between projects. ## Key arguments (≤3) 1. **Generic review comes from a stakeless reviewer, not a weak model** — the model hedges because it has no assigned domain, not because it lacks capability; specificity requires committing to one stack's actual failure modes. 2. **A persona is cheap context plus a stance, and that's the whole mechanism** — Role, Expertise, Review Criteria, Voice is enough to convert a generalist into a domain-specific reviewer; the article's closing argument generalizes this past the one skill. 3. **Read-confirm-commit beats generate-then-hope** — stating what the codebase read found (language, frameworks, conventions) and waiting for developer confirmation before writing any persona file catches a misread stack (e.g., a CLI tool read as a REST API) before it propagates into every subsequent review. ## Claim atoms ### Reviewer without a stake hedges instead of committing > [!quote] ID:tommcfarlin_persona_stake > "It's a smart generalist with no particular stake in your stack, so it hedges." Where/why: Names the mechanism behind generic AI review feedback — not "the model is bad," but "the model has no assigned point of view" — the load-bearing claim the article's fix depends on. #xref ### Skill reads and confirms the stack before generating > [!quote] ID:tommcfarlin_persona_readconfirm > "The skill doesn't guess. Before it writes anything, it reads the codebase and tells you what it found." Where/why: The article's stated reason this skill avoids the common "AI generates a config file for you" failure mode — a checkpoint pattern reusable for any generator skill. #xref ### Point of view reduces to context plus a stance > [!quote] ID:tommcfarlin_persona_thesis > "A reviewer with a point of view gives better feedback than a reviewer without one, and a point of view is mostly just context plus a stance." Where/why: The article's generalized closing thesis, past the specific skill — strongest candidate for reuse as a standalone claim in other AI-review-workflow writing. #aphorisms ## Permanent candidates - **P1 — generated security review is assistive, not an audit**: already covered in shape by [[3. Resources/Permanent Notes/Generated Accessibility Targets Do Not Transfer Verification Responsibility]] (a generated artifact aiming at a safety property doesn't relieve the human of verifying it) and [[3. Resources/Permanent Notes/Automated Review Is Only As Accountable As The Standards Behind It]] (an automated reviewer's trustworthiness is bounded by something outside itself). The specific instance — a Claude Code security persona vs. a real human audit — is close enough to those two existing claims that a third near-duplicate note would add noise, not signal. Connecting, not duplicating; see the Literature note's Links section. - **New**: "Point of view reduces to context plus a stance" (atom 3 above) is the one claim in this article that doesn't already exist in the vault and is one-line-articulable on its own — promoted below as [[3. Resources/Permanent Notes/A Reviewers Point of View Is Context Plus a Stance]]. ## Processing checklist - [x] Checked for existing Literature Note — none found for this source - [x] Checked for existing Permanent Notes covering this source's claims — found two close analogs for the "assistive, not audit" caveat ([[3. Resources/Permanent Notes/Generated Accessibility Targets Do Not Transfer Verification Responsibility]], [[3. Resources/Permanent Notes/Automated Review Is Only As Accountable As The Standards Behind It]]); no existing note captured "point of view = context + stance," so that one was promoted - [x] Connected into [[3. Resources/MOCs/AI & the Future of Knowledge Work MOC]] ## Links - [[3. Resources/MOCs/AI & the Future of Knowledge Work MOC]] — agent-tooling craft: giving an AI reviewer a domain and a stance instead of leaving it generalist - [[3. Resources/Permanent Notes/Generated Accessibility Targets Do Not Transfer Verification Responsibility]] — parallel claim in a different domain: generated output aiming at a good property still needs human verification - [[3. Resources/Permanent Notes/Automated Review Is Only As Accountable As The Standards Behind It]] — parallel claim: an automated reviewer's trust is bounded by something outside the review step itself