Using Code Review Personas in Claude Code | Tom McFarlin  🔗 **Source:** [Using Code Review Personas in Claude Code | Tom McFarlin](https://tommcfarlin.com/code-review-personas-in-claude-code/) > [!note]+ Document Notes > tags: [claude-code, code-review, developer-tools, ai-coding-workflows, prompt-engineering, wordpress-security] > author: Tom McFarlin > source: tommcfarlin.com > reference: https://tommcfarlin.com/code-review-personas-in-claude-code/ > date created: 2026-08-17 > > > [!info] Generated analysis — not the author's words. Sections below are machine-written > > from the captured source. Only text inside `> [!quote]` blocks is verbatim from the author. > > Do not quote or attribute any other line to the named author. > > # 🏷️ Title: Using Code Review Personas in Claude Code | Tom McFarlin > <!-- deep-read:sections start --> ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - [claude-code-persona-generator (GitHub)](https://github.com/tommcfarlin/claude-code-persona-generator) — the skill the article describes - Install path referenced in-article: `~/.claude/skills/persona-generator` ## 📝 Summary - **What happened.** Tom McFarlin describes and links a Claude Code skill, `claude-code-persona-generator`, that reads a project's actual codebase (languages, frameworks, testing tools, conventions) and generates markdown "review persona" files — Security Reviewer, Platform Engineer, UI/UX Designer, QA Engineer, Performance Engineer by default, or any custom persona requested — which the developer then hands a diff to for a review that reasons about the specific stack instead of giving generic feedback. - **Why it matters.** Default Claude Code review output is diffuse ("consider your error handling," "this could be more performant") because the reviewer has no stated point of view. A persona is a lightweight, editable-by-hand markdown contract (Role, Expertise, Review Criteria, Voice) that gives the model a stance, and the skill automates the tedious, error-prone part of writing and maintaining that contract per project (the article's own example: a stale "React reviewer" persona still describing class components years after the team moved on). - **Key stakeholders.** Individual developers and small teams using Claude Code for review; maintainers of Claude Code skills/plugins; by extension, any WordPress plugin/theme developer who wants a Claude Code reviewer that actually checks nonce verification, capability checks, and sanitized `$_POST` handling instead of generic "input validation" comments. - **Risks and tradeoffs.** The generated personas are only as good as what the skill's codebase read surfaces — a misread stack (the article's own example: reading a CLI tool as a REST API) propagates into every subsequent review until corrected. The author explicitly flags that a generated security-reviewer persona is assistive, not a substitute for a real audit on anything sensitive — a caveat easy to lose once the workflow becomes routine. - **Bottom line.** A review persona is context plus a stance; the skill's contribution is making that artifact cheap enough to generate, confirm, and keep current per project instead of hand-copied and left stale. ## 📖 Main Content - **The core problem: generic review from a stakeless reviewer.** Claude Code's default review is a "smart generalist with no particular stake in your stack," so it hedges — it names the shape of a problem ("error handling," "performance") without committing to the specifics that make review feedback actionable. The article ties the fix directly to specificity: a web app's real error-handling risk is an unsanitized `$_POST` value reaching a database call; an iOS app's is a retain cycle in a closure. Generic prompts produce generic review because nothing in the prompt commits the model to one domain's failure modes over another's. - **The persona as artifact.** A review persona is a markdown document instructing Claude to adopt a specific reviewer identity — e.g., "a security auditor who knows WordPress, cares about nonce verification and capability checks, and speaks bluntly about data exposure." The article treats hand-writing these as the actual friction: tedious to write once, worse to write several times, and prone to bit-rot when copied between projects (the persistent "React reviewer" example). - **What the skill automates.** `claude-code-persona-generator` reads the target codebase and writes personas tuned to what it actually finds — frameworks, libraries, conventions, functions in use — rather than assembling a templated document with the project name substituted in. It defaults to five reviewer types (Security, Platform Engineer, UI/UX, QA, Performance) but explicitly accepts free-form requests ("Create an accessibility reviewer and a database performance reviewer for this project"). - **Read-confirm-commit as the trust mechanism.** The article singles out the skill's read-then-confirm step as its most important design choice, contrasting it with "AI generates a config file for you" tools that commit to output before checking their premises. The skill states what it found (language, frameworks, testing tools, conventions) and waits for developer confirmation before generating persona files, on the reasoning that a one-line correction is cheaper than discovering and rewriting a wrong assumption after three personas already exist. - **Persona structure.** Each generated file has four fixed sections: Role (a short identity statement), Expertise (stack-specific knowledge, e.g., "WordPress Plugin API: actions, filters, and the hook lifecycle"), Review Criteria (numbered evaluation dimensions, each with a stated reason), and Voice (how the persona communicates — terse for a security auditor, more human for a UX reviewer). Files land in a `personas/` directory and are plain markdown meant to be hand-edited afterward. - **Workflow integration.** Generation happens once per project. Afterward, the developer hands a finished diff to the persona most relevant to the change (e.g., "Review this against `personas/security-reviewer.md`"), and for larger changes runs the diff past two or three personas in sequence (commonly security, then platform, then others), each one staying in its own lane rather than commenting outside its remit. - **Installation and invocation.** Install via `git clone https://github.com/tommcfarlin/claude-code-persona-generator.git ~/.claude/skills/persona-generator`. Invoke with natural language ("Generate personas for this project," or a scoped request like "Create security and UI review personas for this WordPress plugin") or via the `/persona-generator` slash command. - **Stated limitation.** The author explicitly caveats that a generated security-reviewer persona is an assistive tool, not a substitute for a real audit on anything sensitive — it catches a lot, not everything, and carries no liability. - **The generalized claim.** The article closes by widening the argument past this one skill: a reviewer with a point of view outperforms one without, and a point of view reduces to context plus a stance — the tedious part has always been writing that down, keeping it current, and repeating it per role per project, and that's the part a codebase-reading skill can absorb. ### 🗒️ Notes - Not a transcript; no timestamps to segment. Dense notes above cover the article's full argument arc: problem (generic review) → cause (no point of view) → artifact (persona document) → automation (the skill) → trust mechanism (read-confirm-commit) → structure (four sections) → workflow (hand diff to persona) → install → caveat → generalized thesis. - Concrete technical anchors worth flagging for a WordPress-plugin-dev reader: nonce verification, capability checks, unsanitized `$_POST` → database call, and "WordPress Plugin API: actions, filters, and the hook lifecycle" as a sample Expertise-section line — these map directly onto the WordPress Security Trinity (sanitize input / validate data / escape output) this workflow already tracks. ## 📚 References - [claude-code-persona-generator (GitHub, tommcfarlin)](https://github.com/tommcfarlin/claude-code-persona-generator) — primary source, the skill itself - Article does not cite external secondary sources; all references are to the linked repo and the author's own prior practice. ## 🗣️ Paraphrase - Claude Code's default review comments are technically correct but too generic to be useful, because the model has no assigned stake in the specific stack it's reviewing. - Writing a persona document (a stated identity, domain knowledge, and criteria) fixes this, but hand-authoring and maintaining one per project/role is tedious and the personas rot when copy-pasted between projects. - The persona-generator skill reads the actual codebase and drafts personas grounded in what it finds, rather than filling in a generic template. - Before writing anything, the skill states its read of the project (language, frameworks, tooling, conventions) and waits for the developer to confirm or correct it — catching a wrong assumption before it propagates into every generated persona. - Each persona is a four-section markdown file (Role, Expertise, Review Criteria, Voice) meant to be edited by hand afterward, not treated as a locked output. - In practice, the developer generates personas once per project, then routes each finished diff to whichever persona (or sequence of personas) fits the change. - The author caveats that even a generated security persona is an assistive check, not a substitute for a real security audit. - The broader claim: a point of view is just context plus a stance, and any tool that can supply both cheaply improves review quality — this generalizes beyond Claude Code personas specifically. ## 📰 Newsletter Ever get a Claude Code review that says "consider your error handling, this could be more performant" and think — sure, but about what, specifically? Tom McFarlin's latest post names the actual gap: the model isn't wrong, it's just stakeless. His fix is a review persona — a short markdown file that gives Claude a point of view (security auditor, platform engineer, whoever) before it opens your diff — and a linked [skill](https://github.com/tommcfarlin/claude-code-persona-generator) that reads your codebase and drafts one instead of you hand-copying a stale template between projects. Worth a look for anyone maintaining WordPress plugins: the sample Expertise line literally reads "WordPress Plugin API: actions, filters, and the hook lifecycle," and the security-persona framing (nonce verification, capability checks, sanitized `$_POST`) lines up with our own Security Trinity playbook. One honest caveat baked in: a generated security reviewer is a helpful second pair of eyes, not a substitute for a real audit before anything sensitive ships. ## ✅ Action Items #### DevRel - Developer advocacy: none surfaced — article is a single-author blog post, not a project with an advocacy program to plan against. - Education: consider a short internal writeup/demo showing a WordPress-tuned security persona reviewing a real plugin diff, to make the "context plus a stance" claim concrete for the team. - Developer experience: if The WPOCC or affiliated projects publish a Claude Code skill of their own, borrow this article's read-confirm-commit pattern as a UX standard for any skill that generates files on a developer's behalf. - Developer marketing: not applicable — no campaign, funnel, or attribution surface in this source. - Community management: not applicable — no community or moderation angle in this source. - Internal/external/cross-project: worth sharing in a plugin-dev Slack/Discord as a workflow tip, not a formal cross-project initiative. #### OSPO - Not applicable to this source — the article covers an individual developer tool/workflow, not organizational open-source governance, licensing, or security program management. #### Community - Not applicable to this source — no maintainer/contributor/sponsor/ecosystem structure discussed; the "community" here is informal (a blog post + a public repo). #### WordPress - Core: not applicable — article doesn't touch WordPress core development. - Core Performance: not applicable. - Core AI: tangential relevance only — this is a third-party Claude Code skill, not a WordPress-core AI initiative, but the read-then-confirm pattern is a good reference point if Core AI ever ships developer-facing generation tooling. - Core Program Team: not applicable. - Mobile: not applicable. - Playground: not applicable. - Community: not applicable. - Training: candidate action — a short "write your own Claude Code review persona for a WordPress plugin" tutorial would translate well to Training's learning-path backlog, using the article's four-section persona shape (Role/Expertise/Review Criteria/Voice) as the worked example. - Marketing: not applicable. - Support: not applicable. - Design: the UI/UX Designer default persona is directly relevant — worth testing against an actual plugin settings screen to see if it produces WCAG-aware feedback out of the box, or needs an accessibility-specific persona per this article's own suggestion ("Create an accessibility reviewer... for this project"). - Documentation: candidate action — document a canonical "WordPress plugin security reviewer" persona (nonce verification, capability checks, sanitize/validate/escape) as a reusable example in any Claude Code + WordPress dev-tooling guide this workflow maintains. - Photos: not applicable. - TV: not applicable. - Polyglots: not applicable. - Accessibility: direct action candidate — generate and test an accessibility-focused review persona (per the article's own example prompt) against a real plugin/theme PR and compare its findings to the existing `wordpress-accessibility` skill's WCAG 2.2 AA checklist. - Meta: not applicable. - CLI: the install/invoke pattern (`git clone` into `~/.claude/skills/`, then a `/slash-command`) is a reusable reference for any future CLI-distributed WordPress dev skill. - Hosting: not applicable. - Tide: tangential — Tide's automated plugin scoring and a generated security-reviewer persona solve adjacent but distinct problems (automated static scoring vs. conversational diff review); worth a one-line comparison note if Tide tooling is ever discussed alongside AI-assisted review. - Openverse: not applicable. - Themes: same applicability as Plugins below — a theme-reviewer persona (block theme conventions, `theme.json`, template hierarchy) is a natural extension of this pattern. - Plugins: strongest match in this list — the article's own worked example is a WordPress plugin security reviewer. Concrete next step: clone the linked skill against one of the plugin repos this workflow maintains (`dev-post-kinds-for-indieweb`, `dev-post-formats-for-block-themes`, `dev-outpost`, `dev-link-extension-for-xfn`) and evaluate whether the generated Security Reviewer persona's criteria overlap with or usefully extend the existing `wordpress-security` skill's Security Trinity checklist. #### The WPOCC - Programs: not applicable — no fellowship, microgrant, or stipend angle in this source. - Projects: candidate action — if The WPOCC runs any shared Claude Code tooling for member plugins, evaluate adopting the persona-generator pattern as a documented governance clinic exercise ("generate and review your project's persona files together"). - Funding experiments: not applicable. ### FAIR - Not applicable to this source — no technical-independence, provenance, or governance-artifact content; this is a developer-tooling workflow post unrelated to FAIR's charter. ## 🧪 Hypotheses - H1: A Claude Code review persona built from the specific codebase (frameworks, conventions actually in use) surfaces more actionable, stack-specific findings per review than the default unprimed review, measured by reviewer-comment specificity or developer accept-rate. - H2: The read-confirm-commit step reduces the rate of persona files built on a misidentified stack (e.g., CLI misread as REST API) compared to a "generate-then-review" flow with no confirmation checkpoint. - H3: Personas generated directly from a codebase stay accurate longer (measured by staleness — e.g., references to frameworks the project has since dropped) than personas manually copied and adapted from a different project's persona file. - H4: Routing a diff through multiple narrowly-scoped personas in sequence (security, then platform, then design) produces fewer overlapping/duplicate comments than a single generalist review pass covering all concerns at once. - H5: A WordPress-plugin-specific security persona (nonce verification, capability checks, sanitize/validate/escape) catches a materially different set of issues than a generic "security reviewer" persona on the same PHP diff. ### 📊 Methodology - For H1/H4: A/B comparison — run the same set of real PRs through (a) default Claude Code review and (b) persona-scoped review; have developers blind-rate comment specificity/usefulness and log accept vs. dismiss rates per comment. - For H2: Controlled test where the skill is pointed at codebases with intentionally ambiguous stack signals (e.g., a CLI tool with an HTTP client that could read as a REST API); measure confirmation-step correction rate vs. a variant with no confirmation step. - For H3: Longitudinal tracking — snapshot personas at generation time and again 6-12 months later against the live codebase; count outdated Expertise/Review Criteria references, comparing skill-generated vs. manually-copied personas across matched projects. - For H5: Run the generated WordPress security persona and a generic security persona against the same set of historical plugin vulnerability reports (e.g., known CVEs or Trac security tickets) and compare recall/precision of flagged issues. ### ❓ 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? - How does the skill's codebase read handle a polyglot repo (e.g., a WordPress plugin with both PHP and a JS build step) — does it produce one blended persona or does the developer need to request separate ones? - What happens when two personas (say, Security and Performance) disagree on the same line of a diff — does the workflow have any mechanism for reconciling conflicting review feedback, or is that left entirely to the developer? - Is there a risk that a well-specified persona increases false confidence in AI review output precisely because it sounds more authoritative, even though the underlying model's actual reasoning reliability hasn't changed? - Could the read-confirm-commit pattern be reused for other Claude Code skills that generate config/scaffolding, beyond persona generation specifically? ### 🔮 Future Research - Empirical comparison of persona-scoped vs. default Claude Code review across a real plugin repo's PR history, quantifying both false positives (spurious flags) and false negatives (missed known issues) per persona. - Investigation into persona drift: build tooling to detect when a persona's stated Expertise no longer matches the current codebase (dependency version bumps, removed frameworks) and prompt regeneration automatically. - Study of multi-persona review sequencing (security → platform → design, per the article's stated practice) versus a single combined review, on review time and defect-catch rate. - Extension of the security-persona concept to a WordPress-specific "release-readiness" persona that cross-checks against the existing Security Trinity, accessibility WCAG 2.2 AA criteria, and performance budgets in one document. ### 💡 Implications - **Practice.** Teams doing AI-assisted code review get a low-cost lever (a markdown file, not new infrastructure) to materially improve review specificity — worth piloting on at least one actively maintained plugin repo before broader adoption. - **Policy.** Any internal policy requiring AI-assisted review before merge should explicitly note that a generated security persona is assistive only, per the article's own caveat, and should not be treated as satisfying a "security review completed" gate for sensitive changes. - **Security.** A WordPress-tuned security persona that names nonce verification, capability checks, and sanitized `$_POST` handling as first-class criteria is a good low-effort complement to (not replacement for) the existing manual security review process this workflow already runs. - **Education.** The four-section persona shape (Role/Expertise/Review Criteria/Voice) is simple enough to use as a teaching artifact for how to specify an AI reviewer's scope — a reusable pattern for any Training-track content on AI-assisted code review. - **Funding models.** Not applicable — no funding or business-model implications in this source. ### 🧠 Learning Styles Assessment - Reading level estimate: approximate Flesch-Kincaid grade ≈ 9–10 (conversational blog register, short paragraphs, some technical vocabulary — nonce, capability checks, retain cycle, REST API — assumed familiar to the target developer audience without being defined). #### 👀 Visual learners - Present: one screenshot (the persona-generator skill's interface) and one code block showing the `personas/` directory tree. - Improve: a before/after diagram contrasting a generic review comment against a persona-scoped one on the same line of code; a flowchart of the read → confirm → generate → use cycle. #### 🔊 Aural learners - Present: none — no audio, podcast, or narration accompanies the article. - Improve: a 2-3 minute narrated walkthrough of installing the skill and generating a first persona would suit this content well, given its procedural nature. #### 🗣️ Verbal learners - Present: strong analogy work throughout (the stale "React reviewer" example, the web-app-vs-iOS-app error-handling contrast) and a clear closing definition ("a point of view is mostly just context plus a stance"). - Improve: a short glossary callout for WordPress-specific terms (nonce, capability check) for readers outside that ecosystem. #### 🧩 Kinesthetic learners - Present: concrete install command and two example invocation phrasings developers can copy directly. - Improve: a minimal reproducible example repo the reader could clone and run the persona generator against immediately, rather than only their own project. #### 🧠 Logical learners - Present: a clear problem → cause → mechanism → workflow → caveat → generalized-claim structure that reads like a small argument. - Improve: a comparison table (default review vs. persona-scoped review, across specificity/consistency/setup cost) would make the logical case more scannable. #### 🧑‍🤝‍🧑 Social learners - Present: none — no discussion prompts, forum links, or collaborative angle. - Improve: an invitation to share generated personas or a community repository of persona templates per stack/framework would suit this content. #### 🧘‍♀️ Solitary learners - Present: the article works well as a self-paced read-and-try — install command, invocation phrasing, and expected output are all given inline. - Improve: a short self-check ("does your generated persona correctly name your actual framework?") would reinforce the read-confirm-commit habit. #### 🌿 Naturalistic learners - Present: none — no sustainability or ecosystem-lifecycle framing. - Improve: not a natural fit for this content; skip rather than force an analogy. ### 📊 Accessibility Assessment #### Screen reader semantics - Present: standard heading hierarchy (H2 section headers), ordered lists for the persona-role menu and the four-section persona structure. - Improve: the single screenshot has an empty `alt=""` attribute — should carry descriptive alt text (e.g., "Persona generator skill output listing detected frameworks and conventions"). #### Keyboard navigation - Present: standard link and blockquote markup; nothing keyboard-trapping in a static article. - Improve: not applicable beyond standard site-template concerns, which are outside this article's content. #### Contrast and readability - Present: short paragraphs, code spans visually distinguished via `<code>` tags. - Improve: cannot assess actual color contrast from html_content alone — would need a rendered-page check against WCAG 2.2 AA 4.5:1 minimum. #### Text resizing and reflow - Present: content is plain HTML paragraphs/lists, which reflow natively. - Improve: verify the code block (`personas/` tree, install command) doesn't clip or require horizontal scroll at 200% zoom. #### Media and captions - Present: one image, no video/audio. - Improve: add real alt text to the screenshot (see Screen reader semantics above); no captioning need otherwise. #### Forms and interactions - Present: not applicable — no forms or interactive elements in the article content itself. - Improve: not applicable. #### Standards reference - Primary gap against WCAG 2.2 AA: the empty `alt=""` on the figure image (fails 1.1.1 Non-text Content if the image conveys information, which this one does — it's the skill's confirmation output). ### 🌍 DEIB Assessment #### Cultural breadth - Present: none — single-author, single-perspective developer blog post with no regional or multilingual framing. - Improve: not a natural fit for this content type; not a meaningful gap here. #### Inclusive language - Present: plain, jargon-explained-in-context language (e.g., defines what a retain cycle risk looks like rather than assuming the term alone suffices). - Improve: WordPress-specific terms (nonce, capability check) are used without definition, which assumes prior WordPress security knowledge — a one-line gloss would widen the audience. #### Neurodiversity support - Present: consistent structure (problem → mechanism → workflow → caveat), short paragraphs, frequent headings. - Improve: the persona-role list and the four-section persona structure could both use icon+text labels for faster scanning. #### Representation - Present: not applicable — no people, roles, or identities represented or discussed beyond the abstract "developer." - Improve: not applicable. #### Psychological safety - Present: the article is low-stakes and non-confrontational in tone throughout; the caveat section is framed constructively rather than as a warning. - Improve: not applicable — no safety concerns present in this content. ### ✅ Logical Validity #### Strong reasoning - Causal reasoning, opening section: the claim that generic prompts produce generic review is supported by a concrete mechanism (the reviewer has "no particular stake in your stack, so it hedges") rather than asserted alone — strong because it names the mechanism, not just the symptom. - Analogical reasoning, "Enter the Persona Generator Skill" section: the contrast between a templated persona ("your project name pasted in") and a codebase-read persona is a clear, falsifiable distinction that supports the article's core claim about specificity. - Inductive reasoning, closing section: generalizing from one skill's success to the broader claim "a point of view is mostly just context plus a stance" is reasonable given the specific mechanism described earlier in the piece, though it remains a single-case generalization (see Fallacies below). #### Fallacies - Hasty generalization (mild), closing section: the article generalizes from one project/skill's apparent success to a universal claim about AI code review quality ("the good version of code review stops being something you have to set up by hand every time") without presenting comparative data against default review or against manually-written personas. Location: final two paragraphs. Fix: qualify as "in my experience" or cite even informal before/after examples, which the article otherwise does well elsewhere (the React-reviewer anecdote). - No other significant fallacies identified — the piece is largely descriptive/procedural rather than argumentative, which limits the surface area for reasoning errors. #### Tone of voice - Conversational, confident, and mildly self-deprecating in places ("It's not wrong but it's saying much" — likely intended as "isn't saying much," a probable typo preserved verbatim from source). Practitioner voice throughout: first-person practice descriptions ("The pattern I use..."), direct address to the reader, no hedging on the core recommendation while still being explicit about the tool's limits. ### 🛡️ DARVO Analysis - Not applicable to this source — DARVO (Deny/Attack/Reverse victim-offender) analyzes rhetorical patterns around accusation and blame; this is a neutral developer-tooling how-to with no accusation, conflict, or defensive rhetoric present. ## 🎯 Conclusion - **Bottom line.** A Claude Code review persona is a small, editable markdown artifact (Role, Expertise, Review Criteria, Voice) that converts a stakeless generalist reviewer into a domain-specific one; the linked skill's contribution is generating that artifact from the actual codebase, with a read-confirm-commit step that catches misread stacks before they propagate into every persona. - **Practical next steps.** (1) Clone `claude-code-persona-generator` into `~/.claude/skills/persona-generator` and run it against one actively maintained plugin repo. (2) Compare its generated Security Reviewer persona against the existing `wordpress-security` skill's Security Trinity checklist for overlap and gaps. (3) Treat any generated security persona as assistive only — it does not replace a real audit before shipping anything sensitive, per the article's own explicit caveat. ## 🔄 Refactor Appendix — Using Code Review Personas in Claude Code > Density: 2–5 Literature atoms (H3), 0–3 Permanent candidates (H4). > Defaults: 3 Literature, 1 Permanent. Resonance filter: if you can't > articulate in one line why a claim matters, drop it. > > Konik claim-header rules: present tense, declarative, ≤10 words when > possible, searchable, unique, mirrors annotation focus if present. > > Atomicity: one declarative sentence per atom. "and"/"also" → split. > > Tag pool: #bmf · #addendum · #xref · #articleseed · #storystem · #share · #aphorisms ### 📚 Literature Atoms (H3) #### [H1] 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." **Context & use**: - "Wait, What's The Problem?" section, second paragraph - Names the actual mechanism behind generic AI review feedback — not "the model is bad," but "the model has no assigned point of view" — which is the load-bearing claim the rest of the article's fix depends on **Tags**: #xref **Highlight**: [view highlight](readwise://) <!-- atomicity: 1 idea ✓ --> #### [H2] 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." **Context & use**: - "It Reads First, Then Confirms" section, opening - 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 Claude Code skill that generates files on the developer's behalf **Tags**: #xref **Highlight**: [view highlight](readwise://) <!-- atomicity: 1 idea ✓ --> #### [H3] 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." **Context & use**: - "The Takeaway" section, closing argument - The article's generalized thesis, past the specific skill — strongest candidate for reuse as a standalone claim in other AI-review-workflow writing **Tags**: #aphorisms **Highlight**: [view highlight](readwise://) <!-- atomicity: 1 idea ✓ --> ### 🧠 Permanent Candidates (H4) #### [P1] A generated security review is assistive, not an audit **Claim** (one sentence, Courtney's voice): A generated security-reviewer persona catches real issues but does not substitute for a real audit on anything sensitive, so it belongs before a human security review, not instead of one. **Evidence pointer**: [[#H3]] **Scope & conditions**: Holds for any AI-generated review artifact, not just Claude Code personas — applies equally to a generated `wordpress-security` checklist run or a generated accessibility persona. Breaks down as a claim only if the persona is explicitly validated against a known vulnerability corpus and its recall is measured, which this article does not attempt. **Links** (≥1 with annotation): - [[WordPress Security Trinity]] — because extends (persona-based review as a cheap first pass ahead of the existing sanitize/validate/escape manual check) <!-- atomicity: 1 idea ✓ --> ### ✏️ Fleeting Queue - [F1] Generate a Security Reviewer persona against one owned WordPress plugin repo and diff its criteria against the existing `wordpress-security` skill checklist — https://github.com/tommcfarlin/claude-code-persona-generator #xref - [F2] Check whether the "React reviewer still talking about class components" staleness problem the article names also affects any hand-maintained review checklists in this workflow's own skills #xref ### → Things 3 (max 2 actions) - [ ] Clone `claude-code-persona-generator` into `~/.claude/skills/persona-generator` and run it against one plugin repo (post-kinds, pfbt, outpost, or xfn) to evaluate persona quality — dev-tooling eval #things <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/Using Code Review Personas in Claude Code Tom McFarlin.md|Using Code Review Personas in Claude Code | Tom McFarlin by tommcfarlin.com]] ## Highlights - The reason is straightforward: by default, the reviewer has no point of view. It’s a smart generalist with no particular stake in your stack, so it hedges. It notices the shape of a problem without committing to the specifics, and specifics are the entire value of a review. ([View Highlight](https://read.readwise.io/read/01m07xzkkfqfxcfghb4jsfngea)) - Note: Names the mechanism behind generic AI review feedback: no assigned point of view means no commitment to specifics. - Tags: xref, atom/literature/h1 - The skill doesn’t guess. Before it writes anything, it reads the codebase and tells you what it found. This includes things like the language, the frameworks, the testing tools, the conventions it noticed, then it waits for you to confirm. ([View Highlight](https://read.readwise.io/read/01m07xznwb8gt3664qs5bsd1ea)) - Note: The read-confirm-commit trust mechanism: state findings, wait for correction, before generating anything. - Tags: xref, atom/literature/h2 - One caveat worth stating plainly: a generated security reviewer is an assistive tool, not a substitute for a real audit on anything sensitive. It’ll catch a lot. It won’t catch everything, and it doesn’t carry liability. ([View Highlight](https://read.readwise.io/read/01m07xzrxe4ffxczehh00yw3q8)) - Note: Explicit caveat: generated security personas are assistive, not an audit substitute -- Permanent candidate P1 in the Refactor Appendix. - Tags: xref, atom/literature/h3 - With that said, the broader idea generalizes past this one skill. 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. ([View Highlight](https://read.readwise.io/read/01m07xzvp9gycat9w84ysyx4yr)) - Note: The article's generalized thesis: point of view = context plus a stance. - Tags: atom/literature/h1, aphorisms