Structured Expert Prompting (SEP) — A methodology for building production-ready AI expert personas with complete deployment scaffolds.
Persona Architect is a methodology — and a deployable AI persona (Dr. Petra Vance) — for building structured, expert-grade AI collaborators using Claude.
The core thesis: generic AI assistants underperform not because of model capability, but because of poor persona architecture. Research on the "Persona Depth Gap" demonstrates that LLMs perform significantly better when given specific, deeply constructed personas containing credentials, named methodologies, and domain-specific verification protocols.
This repository provides:
- The Persona Construction Protocol (PCP) — an 8-step repeatable framework for designing expert AI personas
- The 5-File Deployment Scaffold — a production-ready file architecture that separates identity, state, memory, and self-improvement
- Dr. Petra Vance — the Persona Architect herself, deployable in Claude Code or Claude Projects
- Mandatory Protocol Templates — Chain of Verification (CoV), Forensic Analysis Protocol (FAP), and Operational Verification (OV) for every persona type
Most AI persona prompts fail in predictable ways:
| Symptom | Root Cause |
|---|---|
| Inconsistent responses across sessions | No persistent state or memory architecture |
| Generic outputs despite "expert" labeling | Missing named methodology and domain-specific frameworks |
| Errors that repeat across sessions | No self-improvement mechanism |
| No root cause analysis capability | No forensic diagnostic protocol |
| Work marked "done" without verification | No operational verification step |
| Monolithic prompt files that become unmanageable | No separation of concerns |
The result: personas that feel like assistants wearing a costume — not experts with a systematic way of working.
Every persona built with this methodology ships as a complete file system, not just a prompt document.
project-root/
├── CLAUDE.md ← Session orchestrator: workflow rules, file read order, project config
├── PERSONA.md ← Expert identity: credentials, methodology, CoV, FAP, OV
├── current-task.md ← Active state tracker: current work, subtasks, blockers
├── memory.md ← Long-term knowledge store: decisions, patterns, learnings
└── lessons.md ← Self-improvement log: mistake patterns → prevention rules
| File | Responsibility | Volatility |
|---|---|---|
CLAUDE.md |
Session orchestration + workflow discipline | Stable |
PERSONA.md |
Expert identity, methodology, verification protocols | Stable |
current-task.md |
Active work state, subtask checklist | Volatile (every session) |
memory.md |
Long-term project knowledge | Append-only (grows over time) |
lessons.md |
Mistake → prevention rule log | Append-only (after corrections) |
Why not just one file?
Putting everything in CLAUDE.md creates a monolith — a single 1000+ line file where persona identity, task state, project config, and accumulated knowledge blur together. Over time, the model can't focus on what matters per session, and the file becomes impossible to maintain.
Modular architecture solves this: each file has exactly one job, files can be updated independently, and the read order at session start ensures the right context loads at the right time.
Every persona produced by this methodology includes four non-negotiable structural elements plus a deployment success test. These are not optional add-ons — they are part of what "persona" means in this methodology.
Declares the concrete actions that would break the relationship if violated.
Distinct from expertise scope (what the persona doesn't do because it's not their job) — Sacred Trust declares what the persona will never do because doing it would constitute betrayal of the user's trust.
3–5 inviolable boundaries, declared in concrete (not aspirational) terms. Asked of the user upfront: "What would break the relationship with this persona if violated?" Generic answers like "be ethical" are rejected — they provide no actual constraint.
| Domain | Example Sacred Trust Entries |
|---|---|
| Trading / Finance | Never share keys; never share live edges; never expose user to undisclosed risk |
| Marketing | Never publish under user's name without approval; never spend ad budget without ROI gate; never represent product as having features it doesn't |
| Code Review | Never approve security holes; never silently rewrite user-authored logic; never bypass branch protections |
Sacred Trust sits at the top of PERSONA.md, between Core Principles and Methodology — visible before any user request is processed.
Verifies thinking before output is delivered.
Real experts review their own work before presenting it. CoV builds this into the persona's response loop:
- Initial Response — generate the first-pass answer
- Domain-Specific Challenge Questions — 3–5 questions targeting the most common failure modes in the field
- Independent Verification — re-examine output against each challenge question
- Final Revised Output — apply corrections, note changes, flag remaining uncertainties
Challenge questions are domain-specific, not generic. Example:
| Domain | Example CoV Questions |
|---|---|
| Trading / Finance | "Does this survive a black swan event?" / "Am I confusing correlation with causation?" |
| Software Engineering | "What happens when this input is null/0/∞?" / "Will this still work at 100x load?" |
| Game Development | "Is this fun, or just technically clever?" / "What happens when the player does the unexpected?" |
| Marketing / Content | "Would I click this if I saw it in the wild?" / "Is this for the audience or for my ego?" |
Diagnoses root causes, not just symptoms.
When a persona needs to investigate failures, unexpected results, or system behavior, it applies a domain-adapted 5W2H forensic framework:
| Factor | Core Question | Purpose |
|---|---|---|
| WHO | Who is involved? | Identify actors, systems, dependencies |
| WHAT | What happened? | Describe the symptom or failure precisely |
| WHEN | When did it occur? | Timeline, triggers, frequency, patterns |
| WHERE | Where in the system? | Locate the layer, component, environment |
| WHY | Why did it happen? | Root cause — not the symptom |
| HOW | How did it manifest? | Mechanism, sequence of events |
| HOW MUCH | How much impact? | Severity, blast radius, cost |
Every persona rewrites these questions in domain-specific language. A trading persona's FAP asks about P&L impact, market sessions, and execution failures. A software persona's FAP asks about stack traces, deploy versions, and error rates.
Proves execution is correct before declaring work done.
CoV verifies thinking. OV verifies execution. Both are required.
Before any persona marks a task complete, it must:
- Prove it works — run tests, check logs, demonstrate correctness
- Staff-level review — ask "Would a senior expert in this field approve this?"
- Diff check — demonstrate behavior before vs. after changes
- Edge case coverage — verify the domain-specific boundary conditions
Domain-adapted evidence requirements:
| Domain | OV Evidence |
|---|---|
| Trading | Backtest results, risk metrics, paper-trade confirmation |
| Software | Unit tests pass, integration tests pass, no regressions |
| Game Dev | Playtesting results, performance benchmarks, edge case coverage |
| Content | Audience testing, readability scores, brand consistency |
Proves the persona itself works in deployment, not just that the files have correct structure.
Three concrete checks, included in every PERSONA.md, runnable by the user on day one:
- Correct-shape output — a domain-typical request and the expected output shape. Pass = output is recognizably this persona's work, not a generic assistant.
- Out-of-scope refusal — a request deliberately outside the persona's expertise or constraints. Pass = refusal on principle (not capability), in the persona's voice.
- Planted-error CoV catch — a request containing a deliberate, domain-relevant error or trap. Pass = CoV flags it and the revision notes name what changed and why.
CoV verifies thinking. OV verifies execution. Deployment Success Tests verify the persona itself works as advertised.
The 8-step process Petra follows when building any new persona:
Step 1: Domain Analysis — Core field, sub-specialization, task analysis, user context
Step 2: Credential Research — Education, experience, certifications (specific, verifiable)
Step 3: Methodology Design — Named framework, 4–6 steps, output format
Step 4: Voice Calibration — Tone, signature phrases, trait grounding (every non-credential
trait references a real or planned-incident class), soul-vs-method
tagging (techniques never enter the soul)
Step 5: Constraint Definition — Scope boundaries, quality standards, interaction rules,
Sacred Trust (concrete relationship-violating actions)
Step 6: Mandatory Protocol Integration — CoV, FAP, OV (domain-adapted, no exceptions)
Step 7: Deployment Scaffold Generation — All 5 files with correct separation of concerns,
Last Reviewed headers, explicit memory scope rules
Step 8: Assembly & Polish — Consistency check, Deployment Success Tests, practical additions
Real experts have names, backgrounds, and scars. Credentials must be specific and verifiable — real schools, real certifications, real years of experience that shape perspective.
Every expert has a repeatable framework they always use. Named frameworks create consistency across responses and feel credible. Generic step-by-step instructions do not.
Tone must match the persona's background. Include specific phrases, pet peeves, and communication quirks. What a persona never says is as important as what they say.
Real experts have opinions and limits. Include what the persona refuses to do, what red flags they watch for, and what corners they never cut.
CoV, FAP, and OV are not features — they are the difference between a tool that generates text and a persona that operates like a senior expert.
Real experts don't just solve problems — they diagnose root causes. The 5W2H investigative framework (Who, What, When, Where, Why, How, How Much) is adapted to each domain and used whenever the persona needs to investigate failures or perform root cause analysis. Forensic capability transforms a persona from "answer provider" to "problem solver."
A persona document alone is not production-ready. It needs a session orchestrator, state tracking, persistent memory, and a self-improvement loop. The 5-file scaffold is the product.
A persona without operational discipline is an expert who can't execute. Plan before building, verify before declaring done, learn from every mistake. The CLAUDE.md defines HOW the persona works, not just WHO it is.
Personas built with this methodology fall into five archetypes, each with specific adaptations:
| Category | CoV Focus | FAP Focus | OV Focus |
|---|---|---|---|
| Technical | Edge cases, null inputs, scale failures | Debugging, system failures, performance degradation | Tests pass, no regressions, benchmarks met |
| Business / Strategy | Market assumptions, competitive blind spots, financial projections | Strategy failures, missed KPIs, market shifts | Data validation, model backtesting, stakeholder sign-off |
| Creative | Audience fit, originality, brand consistency | Engagement drops, creative blocks, audience misalignment | Audience testing, A/B results, stakeholder review |
| Analytical / Research | Methodology flaws, sample bias, confounders | Data anomalies, replication failures, contradictions | Statistical validation, reproducible results |
| Translation / Bridge | Semantic drift, lost context, false equivalences | Translation failures, context mismatches | Round-trip validation, side-by-side comparison |
- Clone this repository into your project root
- Open Claude Code in the project directory
- Claude Code automatically reads
CLAUDE.mdon startup - Petra adopts her identity from
PERSONA.mdand begins the session
Petra requires only three fields to start (the Minimum Viable Brief):
DOMAIN: [Field/specialty — e.g., "crypto quant trading"]
PRIMARY TASK: [What the persona is asked to do — e.g., "design and validate trading strategies"]
EXAMPLE OUTPUT: [One concrete sample of what success looks like — e.g., "a strategy spec with entry/exit rules, risk parameters, and backtest config"]
Petra will state explicitly when she's working from a minimum brief and surface design tradeoffs (alternatives considered) on every non-trivial choice. You can always redirect.
Optional Enrichment (front-load to tighten the design):
USERS: [Who interacts, their level]
TONE: [Preferred style]
TECH STACK: [Languages, frameworks, platforms]
CONSTRAINTS: [Any limitations]
SPECIAL: [Multiple modes? Code translation? Other quirks?]
COMMUNICATION CONTRACT: [Daily digest vs on-demand? Tables vs prose? When does the persona ping vs wait?]
USER WORLDVIEW: [Pragmatist vs theorist? Formality level? Stance the persona should mirror.]
SACRED TRUST: [What would break the relationship with this persona if violated? Concrete, not aspirational.]
Petra will ask for SACRED TRUST explicitly if not provided — she will not invent inviolable boundaries on the user's behalf.
Note: You never need to request CoV, FAP, OV, Sacred Trust, the deployment scaffold, the Deployment Success Tests, or workflow orchestration rules. They are included automatically in every persona Petra builds.
EXISTING PERSONA: [Reference or paste]
CHANGE: [What to modify — be specific to file + section]
REASON: [Why the change is needed]
SCOPE: [Only the named change | OR change + cascade to anything that goes stale]
Default scope is only the named change. Petra will:
- Touch only the requested file/section
- Flag adjacent items in a severity-tagged "Noticed but not changed" list (
blocker | nice-to-have | cosmetic) for you to decide on separately - Cascade flags, never cascades silently — if a change logically requires touching another file to stay consistent, Petra flags it and asks before applying
The CLAUDE.md is the session orchestrator — not the persona. It must:
- Open with a one-line project description
- Define the file read protocol (order, purpose, when to update)
- Contain project-level config (tech stack, conventions, testing standards)
- Contain Workflow Orchestration rules (plan mode, subagent strategy, elegance, autonomy levels)
- Contain Task Management lifecycle (plan → verify → track → explain → document → learn)
- Contain Core Principles (simplicity, no laziness, minimal impact)
- Reference all 4 companion files
- Stay under ~150 lines for maintainability
It must NOT contain:
- Persona content (that belongs in
PERSONA.md) - Task state or memory entries (those belong in
current-task.mdandmemory.md) - Lesson entries (those belong in
lessons.md)
Every persona ships with an explicit autonomy table:
| Situation | Action |
|---|---|
| Bug report | Just fix it. No hand-holding. |
| Simple / obvious fix | Fix and explain. No permission needed. |
| Non-trivial change | Plan first. Check in before implementing. |
| Architecture decision | Plan + verify plan with user before building. |
| Unclear requirements | Ask one focused clarifying question. |
| Task going sideways | STOP. Re-plan. Don't push through. |
lessons.md is not passive documentation — it is an active prevention system. It also tracks the persona's identity evolution, separately from prevention rules.
Prevention rules. After any correction from the user, the persona:
- Records the mistake (what went wrong)
- Records the correction (what the right approach was)
- Writes a prevention rule as an imperative directive (
ALWAYS.../NEVER...) - Reviews all lessons at the start of every session
Identity Growth. The persona's traits and values are seeded minimally and earn their weight incident by incident. Each evolution entry is tied to a specific event — never abstract, never assigned. Empty review periods are healthy data: maturity is principles compounding, not getting rewritten weekly.
The goal: mistake rate approaches zero over time, while identity earns its weight through real contact with the work.
persona-architect/
├── CLAUDE.md ← Petra's session orchestrator
├── PERSONA.md ← Dr. Petra Vance — the Persona Architect
├── current-task.md ← Active task template
├── memory.md ← Long-term knowledge store
├── lessons.md ← Self-improvement log (prevention rules + identity growth)
├── CONTRIBUTING.md ← Contribution guidelines
├── LICENSE ← MIT
└── README.md ← This document
"A persona without a methodology is just a costume."
"Specificity is the soul of expertise."
"CoV catches what you missed. FAP finds why you missed it. OV proves you fixed it."
"CLAUDE.md orchestrates. PERSONA.md thinks. current-task.md tracks. memory.md remembers. lessons.md learns."
"Plan before you build. Verify before you ship. Learn from every mistake."
The Persona Architect methodology was developed from the observation that the gap between a useful AI collaborator and an impressive-sounding but unreliable one is almost entirely architectural — not a question of model capability.
Good architecture forces the right behaviors: verification before delivery, forensic thinking when things go wrong, persistent learning across sessions, and clear separation between who the persona is, what it's working on, and what it knows.
These are not prompting tricks. They are engineering principles applied to persona design.
Contributions welcome — especially:
- New persona examples across domains not yet covered
- Domain-adapted CoV question sets for niche fields
- Forensic Analysis templates for specific industries
- Lessons.md patterns derived from real deployment experience
- CLAUDE.md templates for specific tech stacks or team configurations
Please open an issue before submitting large changes, so we can align on direction.
MIT License — see LICENSE for details.
Use, adapt, and build on this methodology freely. Attribution appreciated but not required.
This methodology was developed through hands-on deployment of AI personas across crypto trading automation, software architecture, game development, e-commerce, and HR platform engineering. It reflects the operational reality of using AI collaborators across multiple concurrent, high-stakes technical projects.
The 5-file scaffold emerged from repeated failure of single-file approaches — monoliths that grew unmanageable, personas that forgot their own history, and experts that couldn't learn from their own mistakes.
Dr. Petra Vance is the distillation of everything that worked.