How to Develop Document Council Personas
This guide explains how to create a new named persona for the Document Council (e.g. a specific person or role) so the council can review documents from that perspective. For adding generic role personas (e.g. “Delivery lead”) or new doc types, see the Extending section in the personas mapping.
Reference example: The Uttam Kumaran (CEO) persona in standards/04-prompts/planning/personas/uttam-kumaran.md and its entry in document-council-personas.md.
When to Create a Named Persona
Create a dedicated persona file when:
- You want the council to roleplay a specific person (e.g. CEO, CSO, a key client role) whose judgment and voice are well understood.
- You have enough primary sources (transcripts, written docs, style guides) to capture how they think, speak, and review.
- The persona will be reused across multiple doc types (e.g. internal proposals, plans, SOWs).
For one-off or generic roles (e.g. “Engineer (feasibility)”), a short definition in the mapping table is usually enough.
Step 1: Gather Primary Sources
Collect material that shows how the person actually behaves in reviews and communication:
| Source | What to extract |
|---|---|
| Meeting transcripts | Recurring questions, pushbacks, phrases, what they approve or block. Search vault for their name (e.g. knowledge/**/transcripts/*.md). |
| Written artifacts | Tone, vocabulary, structure (e.g. Second Brain / CLAUDE.md, style guides, LinkedIn or internal posts). |
| Resume or role description | Background, expertise, and authority so the persona has clear identity. |
Tip: For transcripts, a simple script can extract lines attributed to the person and count recurring phrases (e.g. “I feel like”, “how do you know”) to identify voice patterns and review lenses.
Step 2: Define Identity and Philosophy
In the persona file, spell out:
- Who they are: Role, background, and why their perspective matters for the doc types you’ll use them for.
- Core beliefs: 2–5 short statements they consistently act on (e.g. “We’re a partner, not a staffing firm”).
- What they reject: Phrases, behaviors, or doc patterns they’d flag or block (e.g. corporate fluff, vague metrics).
This gives the model a stable “self” so reviews stay in character.
Step 3: Capture Voice and Tone
Document how they sound so the council’s output matches them:
- Signature phrases — Exact wording they use when agreeing, pushing back, or asking for evidence.
- Softening patterns — How they couch criticism (e.g. “I feel like…”, “I don’t think…”).
- Questions they ask — Recurring challenges (e.g. “Who’s the audience?”, “How do you know that’s gonna decline?”).
- What to avoid — Words or tone that would be out of character (e.g. “leveraging synergies”).
Include a short vocabulary / anti-pattern list (words they use vs. words they avoid) if it helps.
Step 4: Define the Review Lenses
Turn their behavior into repeatable review criteria. For each lens:
- Name (e.g. “Metrics & Reality”, “Jargon & Clarity”).
- What they ask — Concrete questions they’d pose when reviewing.
- Red flags — What would make them block or demand changes.
Aim for 3–5 lenses. These drive what the persona actually checks in the doc.
Step 5: Specify Verdict Style and Output Format
- Verdict style: How they signal approve / revise / block (e.g. “Yeah, I’m good with it if you are” vs. “I don’t know if…”).
- Output format: A small template the model should follow (e.g. “Uttam’s Take” with Verdict, What Works, Questions I Have, Concerns, What I’d Change, TL;DR). This keeps council output consistent and scannable.
Step 6: Write the Persona File
Create a single markdown file under standards/04-prompts/planning/personas/:
- Filename:
{name-or-role-slug}.md(e.g.uttam-kumaran.md). - Sections (suggested): Identity → Voice & Tone → Review Lenses → Verdict Style → Output Format. Optionally add a short “Source context” (what the persona was derived from) and last-updated date.
The file should be self-contained so the Document Council skill can load it as the system prompt for that reviewer.
Step 7: Wire Into the Document Council
- Mapping: In
standards/04-prompts/planning/document-council-personas.md, add the persona to the Doc type → personas table for each doc type where they should run (e.g. Internal proposal, Plan). - Usage note: In the same file, add a short section (e.g. “Uttam Kumaran (CEO) persona”) that states:
- When to include this persona.
- How to load it (path to the persona file and that it defines identity, voice, lenses, output format).
This way the skill knows when to use the persona and where to find the full prompt.
Checklist for a New Persona
- Primary sources gathered (transcripts, written artifacts, role/resume).
- Identity and philosophy written (who they are, what they believe, what they reject).
- Voice and tone captured (phrases, questions, avoid list).
- 3–5 review lenses defined (name, questions, red flags).
- Verdict style and output format specified.
- Persona file created under
standards/04-prompts/planning/personas/{slug}.md. - Persona added to the doc-type table and a “how to load” note added in
document-council-personas.md.
References
- Document Council skill:
.cursor/skills/document-council/SKILL.md - Doc type → personas mapping:
standards/04-prompts/planning/document-council-personas.md - Example persona:
standards/04-prompts/planning/personas/uttam-kumaran.md(CEO persona derived from transcripts and Second Brain)