Triple Persona Review

Overview

Most draft-review feedback fails because it averages. Asking one editorial agent returns smoothed-good prose; asking one reader returns one perspective. Both produce less signal than they look like they produce.

The triple-persona pattern produces more signal by deliberately choosing three readers whose interests do not align, dispatching them in parallel, and treating the contradictions in their feedback as the most useful data. If Persona A loves a paragraph and Persona B finds it preachy, that paragraph is a deliberate audience tradeoff — knowing which side to optimise for is the editorial decision.

Outputs:

• Three independent persona reviews, each in a rigid structured format.
• A consolidated editing report with consensus issues, tradeoff points, outlier flags, and prioritised edits — handed to the author or to whatever skill produced the draft.

The persona library at personas/ grows over time. After each round, calibrate the personas that returned soft, aligned, or off-target feedback.

When to Use

Use when:

• A draft is structurally complete but you want pressure-test feedback before shipping.
• The author wants editorial feedback that isn't averaged-good — distinct readers with distinct biases.
• The piece has multiple plausible audiences and the author wants to see how each will read it.
• After a major rewrite — to check whether the rewrite serves all readers or only one.
• A skill like crafting-portfolio-essays has produced a draft and the author wants the next iteration's audit input.

Do NOT use for:

• Mechanical copyediting — wrong tool.
• Drafts at skeleton level — wait until prose is real, three readers will only complain about the obvious.
• Code review or correctness checks — this is editorial / audience pressure-test only.
• One-off "is this any good?" — you'll get three answers; the author needs to be ready for that.
• Pieces with one true audience — single-persona review is fine.

The Iron Rules

1. Three is the default; never exceed five. Two readers can agree (single signal) or disagree (which is right?). Three produces triangulation: consensus + tradeoff + outlier. Past five, consolidation overhead exceeds marginal information.

2. Personas must include reward AND penalise calibration. Generic personas ("a senior executive") produce generic feedback. The reward/penalise structure is what produces specific, actionable critique. See briefing-template.md.

3. Dispatch in parallel — always. Three sequential agent calls cost 3× wall-clock for the same output. Use a single message with three Agent tool blocks.

4. The output format contract is rigid. Consolidation depends on it. Free-form persona prose breaks the report. Enforce the format in every dispatch.

5. Tradeoff points are the most useful signal — never average them away. The consolidation report must distinguish consensus / tradeoff / outlier. If you smooth tradeoffs into "consider revising", you've thrown away the actual editorial decision.

6. Personas drift — calibrate every 3–4 rounds. Append to the persona's calibration log when their feedback was soft, indistinguishable from another persona, missed an obvious flaw, or was wrong about something the author knew was right.

Workflow

digraph workflow {
    rankdir=LR;
    "1. PICK\nor BUILD\npersonas (3)" [shape=box];
    "2. DISPATCH\nin parallel" [shape=box];
    "3. CONSOLIDATE\neditingreport" [shape=box];
    "4. HAND OFF\nto author or\nupstream skill" [shape=box];
    "5. CALIBRATE\npersona files" [shape=box];

    "1. PICK\nor BUILD\npersonas (3)" -> "2. DISPATCH\nin parallel";
    "2. DISPATCH\nin parallel" -> "3. CONSOLIDATE\neditingreport";
    "3. CONSOLIDATE\neditingreport" -> "4. HAND OFF\nto author or\nupstream skill";
    "3. CONSOLIDATE\neditingreport" -> "5. CALIBRATE\npersona files";
}

Phase 1 — Pick or Build Personas

Read the artifact. Identify the audiences who will actually read it.

For most portfolio essays, the canonical three are:

• Senior peer / executive — could refer or hire the author.
• Builder / follower — sits in the inbound funnel for the author's content.
• Potential client — evaluating the author commercially.

For other artifact types, see personas/README.md for guidance on archetype selection.

Match against personas/ library. Each persona file follows briefing-template.md and includes identity, reading context, reward profile, penalise profile, voice/verdict format, and a calibration log.

If no matching persona exists, write a new one using briefing-template.md. Add to the library.

Phase 2 — Dispatch in Parallel

Use the Agent tool with subagent_type: general-purpose. Send all three in a single message with three Agent tool blocks so they run concurrently.

Each agent receives:

• Their persona briefing (full text from personas/{name}.md).
• The artifact path(s) to read.
• Author / context (2–3 sentence brief about the writer and the piece).
• The output format contract.
• A length cap (default 600 words per persona).

See briefing-template.md §"Dispatch prompt" for the exact template.

Phase 3 — Consolidate

Synthesise into a single editing report at {drafts-or-docs}/editing-report-{slug}.md using the schema in consolidation-template.md.

Required sections:

• Executive summary — one paragraph: what's working, the main fix.
• Verdict tally — table of each persona's reader-action verdict.
• Consensus issues (2/3 or 3/3) — high-priority edits.
• Tradeoff points — where personas disagreed; framed as a decision for the author, not averaged.
• Outlier flags (1/3) — judgment calls, often domain-specific.
• Prioritised edit list — P0 / P1 / P2 with paragraph-level specificity.
• Open questions for the author.

Treat tradeoff points with care: surface the choice, name what each persona wanted, recommend a resolution but make clear it's a decision, not a fix.

Phase 4 — Hand Off

If invoked from another skill (e.g. crafting-portfolio-essays), the editing report becomes the next iteration's Phase 1 audit input. The upstream skill consumes it.

If standalone, hand the report to the author.

Phase 5 — Calibrate (after the round)

Append to personas/{name}-calibration.md (or to the calibration log inside the persona file) when:

• A persona returned feedback indistinguishable from another persona → they need more reward/penalise differentiation.
• A persona was wrong about something the author knew was right → tighten the briefing.
• A persona missed an obvious flaw → add to their reward/penalise profile.
• A persona drifted out of voice → re-read the briefing for tone calibration.

Calibration is what makes the library a long-lived asset rather than a one-off cast.

The Output Format Contract (per persona)

Every persona returns exactly this format. Enforced in dispatch.

## Persona
{Name + one-line capsule}

## What landed
{3–5 bullets, each citing a specific sentence/paragraph and explaining why it worked FOR THAT PERSONA. Quote sparingly.}

## What didn't land
{3–5 bullets, specific evidence, same level of citation as What landed.}

## Specific edit recommendations
{2–4 actionable edits. Format: "§{section} paragraph {n}: {what to change} — {why for your persona}".}

## Overall reaction (one sentence)
{In the persona's voice.}

## Reader-action verdict
{One of the persona-specific options — e.g. "I would take the call" / "I would share this" / "I would not engage" — followed by a 10–15 word reason.}

Common Mistakes