persona-generator

name	persona-generator
description	Generate tailored review personas for any project. Reads the codebase, presents a role menu, and produces persona files with domain-specific expertise, review criteria, and voice.
allowed-tools	Bash Read Write Glob Grep

Persona Generator

Generate review personas tailored to your project's tech stack. Each persona is a markdown file you can hand to Claude as a review lens — "run this persona over the changeset."

Note: This skill generates personas. To run them, tell Claude directly: "Run the security-reviewer.md persona over the changeset."

When to Use

• The user says "generate personas", "create personas", or "build review personas"
• The user asks for review personas for a project
• The user wants to set up persona-based code review for a codebase

Workflow

Follow all five steps in order. Do not skip steps. Do not generate personas until Step 3 is complete.

Step 1 — User Declares Project Type

Ask the user:

"What kind of project is this? (e.g., iOS app, WordPress plugin, React SPA, Express API)"

Free-form answer. This declaration anchors all persona generation — use it alongside codebase findings to tailor content.

Step 2 — Read the Codebase

First, verify the working directory is a project root. Check for source files, a package manifest (Package.swift, composer.json, package.json, etc.), or a git repository. If none of these exist, ask the user to confirm they're in the right directory.

From the project root, scan the codebase to understand the tech stack:

1. Languages and runtimes — Check file extensions, package manifests, config files.
2. Frameworks — Read dependency files (Package.swift, composer.json, package.json, requirements.txt, etc.) and identify major frameworks.
3. Testing — Find test directories and existing test files to identify the testing framework and conventions.
4. Architecture — Scan directory structure and key files to understand the architectural pattern.
5. Key tools — Check for CI configs, build tools, linters, formatters.
6. Conventions — Read a few representative source files to identify coding conventions, naming patterns, and style.

Present findings to the user for confirmation:

Here's what I found in the codebase:

• Language/Runtime: [e.g., Swift 6, PHP 8.1]
• Frameworks: [e.g., SwiftUI, UIKit, WordPress Plugin API]
• Testing: [e.g., XCTest, PHPUnit + Brain Monkey]
• Architecture: [e.g., MVVM, MVC with service layer]
• Key tools: [e.g., SPM, Composer, GitHub Actions]
• Conventions: [e.g., strict concurrency, WPCS, PSR-4]

Does this look right? Anything to add or correct?

Wait for the user to confirm or correct before proceeding.

If the codebase is sparse (few source files, no dependencies, scaffolding only), tell the user:

"This codebase doesn't have enough code for me to generate meaningful personas. Run this skill again once the repo is more populated."

Stop here. Do not generate personas from an empty codebase.

Step 3 — Present Role Menu & User Selects

Read references/roles.md and present the available roles:

Available persona roles:

1. Security Reviewer — audits for vulnerabilities, data exposure, and unsafe patterns
2. Platform Engineer — evaluates architecture, idioms, performance, and testability
3. UI/UX Designer — reviews interface design, accessibility, and platform guidelines
4. QA Engineer — evaluates test coverage, edge cases, and regression risk
5. Performance Engineer — focuses on profiling, optimization, and resource efficiency

Which roles do you want? (e.g., "1, 2, 3" or "all" or "security and UI")

If the user requests a role not in the menu, generate it as a custom role. Tell the user:

"That's a custom role — I don't have built-in seed guidance for it, so review the output more carefully."

After role selection, ask two follow-up questions:

Specificity:

"Want me to include project-specific references (actual class names, UI patterns, tools from your codebase) or keep these generic to the stack?"

If the user wants project-specific references but the codebase doesn't have enough distinctive content to meaningfully personalize, say so and fall back to stack-generic content.

Sections:

"The default sections are Role, Expertise, Review Criteria, and Voice. Want to add or remove any sections?"

Wait for the user to answer both questions before proceeding to Step 4.

Step 4 — Generate Personas

For each selected role, generate a persona file:

• Use references/persona-template.md as the structural guide
• Use references/roles.md for role-specific seed content (focus areas, review lens, voice guidance)
• Tailor expertise, review criteria, and voice to the tech stack and codebase findings from Step 2

Content guidelines:

• Expertise should include 8-12 stack-specific skills. Not "database security" but "$wpdb->prepare() and parameterized queries" for WordPress, or "Keychain Services and App Transport Security" for iOS.
• Review Criteria must be actionable. Each item is something the persona evaluates when looking at code, not a vague principle.
• Voice must describe how the persona communicates, not what it knows. Include what references it cites, how it formats findings, and its communication style.

If the user requested project-specific references, weave in actual class names, patterns, and tools found in the codebase. If they chose generic, keep content at the stack level.

If the user requested custom sections, add them after Voice.

Security Reviewer note: The generated security reviewer persona must include this note in its Voice section: "This persona is an assistive review tool. For production systems handling sensitive data, authentication, or payments, validate findings with a human security review."

Ask where to save:

"Where should I save the personas? Default: personas/ in the project root."

If the directory doesn't exist, create it.

Check for existing personas: If the target directory already contains persona files, list them and ask:

"I found existing personas in personas/: [list]. Want me to overwrite all of them, or just generate specific ones?"

Only write the files the user confirms.

File naming: Use lowercase kebab-case matching the role name (e.g., security-reviewer.md, platform-engineer.md, ui-ux-designer.md, qa-engineer.md, performance-engineer.md). Custom roles follow the same pattern.

Step 5 — Present & Confirm

Show the user what was generated: list of files with a preview of each (the Role section):

Generated personas in personas/:

• security-reviewer.md — [First sentence of Role section]
• platform-engineer.md — [First sentence of Role section]
• ui-ux-designer.md — [First sentence of Role section]

Want to revise any of these, or are they good?

If the user requests revisions, make them and show the updated preview. Repeat until the user approves.

After approval:

"Personas saved to personas/. To use them, tell Claude: 'Run the security-reviewer.md persona over the changeset.'"