From agent-skills
Orchestrates a multi-persona code review of the user's current project by spawning parallel sub-agents — each adopting a different reviewer persona (security, performance, WordPress, WooCommerce, frontend/UX, devops, QA) — then synthesizing their findings into a single prioritized, actionable report with severity ratings, deduplicated issues, and decisions-needed flagged for the user. Use whenever the user asks for a code review, code audit, multi-persona review, panel review, second opinion on a codebase, "review this project", "audit this repo", a security + performance + UX pass, or names specific reviewer personas. Trigger on loose phrasing too ("get a few sets of eyes on this", "review my plugin/theme for production", "what would a senior engineer say about this"). The skill auto-detects which personas to run (always runs security/performance/QA; adds WordPress, WooCommerce, frontend/UX, and devops based on signals in the code), writes raw findings and a synthesized report under `.reviews/{timestamp}/` in the project root, and offers follow-ups to render an HTML report or file GitHub issues. Not for single-file targeted bug hunts; not for greenfield design reviews where there is no code yet.
How this skill is triggered — by the user, by Claude, or both
Slash command
/agent-skills:multi-persona-code-reviewThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Orchestrate a panel of specialist reviewer personas against the user's current project, in parallel, then synthesize their findings into one prioritized report.
README.mdpersonas/00-senior-engineer.mdpersonas/01-security-engineer.mdpersonas/02-performance-engineer.mdpersonas/03-wordpress-developer.mdpersonas/04-woocommerce-specialist.mdpersonas/05-frontend-ux-engineer.mdpersonas/06-devops-engineer.mdpersonas/07-qa-engineer.mdstages/1-parallel-review.mdstages/2-debate.mdstages/3-synthesis.mdtemplates/finding.mdtemplates/render-github-issues.mdtemplates/render-html-report.mdOrchestrate a panel of specialist reviewer personas against the user's current project, in parallel, then synthesize their findings into one prioritized report.
The skill itself is the conductor. Each persona is a separate sub-agent (spawned via the Task tool) that runs in its own fresh context. Independence is the point — parallel sub-agents give genuinely different perspectives instead of one anchor opinion that drags the rest along.
confidence: low; speculation without evidence is dropped.reviewers: listing each contributor.decisions-needed.md instead of being silently resolved.If unsure, ask. A full multi-persona run uses a non-trivial amount of tokens; don't fire it speculatively.
The project under review is the current working directory at the time the skill is invoked — typically a git repository root. The skill's own location (project-level .claude/skills/, user-level ~/.claude/skills/, or installed as a plugin) is irrelevant to where output goes. All internal references in this skill use paths relative to SKILL.md.
Output always lands under ${PROJECT_ROOT}/.reviews/{YYYY-MM-DD-HHMM}/, where ${PROJECT_ROOT} is the user's current working directory at invocation time. Create .reviews/ if it doesn't exist and add it to .gitignore if the user wants (ask once, then remember within the run).
Three stages. Stage 2 is optional and conditional.
For each persona selected for this run, spawn one sub-agent via the Task tool. Each sub-agent receives:
personas/NN-<slug>.md) verbatimstages/1-parallel-review.md)templates/finding.md)Sub-agents are spawned in a single message with multiple Task tool calls so they actually run concurrently. Each writes its findings to ${RUN_DIR}/raw/{persona-slug}/ — one file per finding plus a _summary.md for its own coverage notes.
Do not pass one persona's draft findings to another at this stage.
After synthesis (Stage 3) flags needs-debate.md entries, the user (or a follow-up invocation) can request Stage 2 for a specific finding. A single sub-agent loads the disputed finding plus the contributing personas' source files and plays each role through one structured round (opening → response → synthesis attempt → recommendation). Output is either an updated final finding or an escalation to decisions-needed.md. See stages/2-debate.md.
Stage 2 does not run automatically — it is a follow-up. The first invocation reports back with what's in needs-debate.md and waits.
After every Stage 1 sub-agent has returned, spawn one final sub-agent as the senior-engineer persona (personas/00-senior-engineer.md) with the Stage 3 instructions (stages/3-synthesis.md). It reads everything under raw/, dedupes, re-rates severity using the cross-domain rubric, ranks, and produces:
findings/{ID}.md — one file per final finding, IDs prefixed by severity (CRIT-001, HIGH-001, …)summary.md — executive overview, counts, top priorities, cross-cutting themes, effort estimate, coverage notesdecisions-needed.md — questions only the user can answer, each with options and a recommendationneeds-debate.md — present only if there are contested findings worth a Stage 2 passnice-to-have.md — present only if there is noise worth recording but not promotingWalk through these steps in order.
Identify the project root (usually pwd, but if the user invoked from inside a sub-directory, walk up to the nearest git root or ask). Then determine which personas apply.
Always include:
security-engineerperformance-engineerqa-engineerConditionally add based on signals in the codebase. Detect with shell tools (fd, rg, grep, ls) — don't rely on intuition.
| Persona | Add when (any signal matches) |
|---|---|
wordpress-developer | wp-config.php, wp-content/, wp-load.php, functions.php, or content matches rg -l 'add_action\(|add_filter\(|wp_[a-z_]+\(' |
woocommerce-specialist | woocommerce.php anywhere, any path containing woocommerce, or content matches rg -l 'WC\(\)|wc_get_|class WC_|\$order->|\$cart->' |
frontend-ux-engineer | Significant template/component files (*.tsx, *.jsx, *.vue, *.svelte, template parts in a theme, block sources), or substantial CSS, or register_block_type calls |
devops-engineer | Dockerfile, docker-compose*, .env*, .github/workflows/, Makefile, Procfile, *.tf, ansible/, k8s/, helm/, or composer.json / package.json with deploy scripts |
The user can override:
all — run every persona regardless of signalsState the chosen persona list back to the user before spawning sub-agents. Don't ask for approval, just state — they'll interject if it's wrong.
${PROJECT_ROOT}/.reviews/{YYYY-MM-DD-HHMM}/
├── raw/ # one subdir per persona, created by Stage 1
├── findings/ # final, deduplicated findings (Stage 3)
├── summary.md # Stage 3
├── decisions-needed.md # Stage 3
├── needs-debate.md # Stage 3, only if contested findings exist
└── nice-to-have.md # Stage 3, only if there is noise worth recording
Use the local timezone for the timestamp. If a run started this minute already exists, append a -2 suffix rather than overwriting.
Spawn one sub-agent per selected persona — all Task tool calls in a single message so they execute concurrently. Each prompt should include:
personas/{NN-slug}.md relative to this SKILL.md)stages/1-parallel-review.md)templates/finding.md)${RUN_DIR}/raw/{persona-slug}/The sub-agent must be told explicitly: write each finding as a separate markdown file, and write a _summary.md with its coverage notes (scope, finding count by severity, areas focused, areas skipped, confidence, open questions).
Wait for all sub-agents to return.
Spawn one sub-agent with the senior-engineer persona and the Stage 3 instructions. It reads everything under ${RUN_DIR}/raw/, produces the deliverables described above, and returns a short summary.
A short message with:
decisions-needed.md has entries (and how many)needs-debate.md has entriessummary.mdDo not paste the full report into chat. The artifacts on disk are the deliverable.
After the initial run, the user may ask for any of these. The skill handles them as follow-ups; the run directory is the input.
report.html in the run directory. See templates/render-html-report.md.gh issue create bash script. See templates/render-github-issues.md.needs-debate.md (or one the user names). See stages/2-debate.md.If the user has the github-issues skill installed (this repo ships it), the issue-creation step can hand off to it — pass the individual finding markdown files as input.
If the user is not running Claude Code (e.g. using the Anthropic API directly, or a different agent harness), they can still use this skill manually:
personas/*.md file and run it as a separate Claude API conversation against the codebase.templates/finding.md.personas/00-senior-engineer.md + stages/3-synthesis.md as the final synthesis pass with the raw findings as input.The structure is the same; only the orchestration changes.
A full multi-persona run is not cheap. Each Stage 1 sub-agent does a substantive read of the codebase; the synthesis sub-agent reads every raw finding. On a medium-sized WordPress codebase, expect a six-persona run to consume significantly more tokens than a single audit. Recommend single-persona invocations for routine sanity checks; reserve the full panel for pre-launch, post-incident, due diligence, or "we inherited this codebase" situations.
npx claudepluginhub happyprime/agent-skills --plugin agent-skillsCreates, edits, and optimizes skills for Claude Code, including drafting, evaluating with test prompts, iterating on performance, and improving skill descriptions for better triggering accuracy.