Persona Design Principles: Voice, Values, Boundaries

+15 Mana ✨
Designing Personas(DOCUMENTATION)

Introduction

Writing a custom SOUL.md is one of those tasks that looks easy until you try it. The first draft is usually a list of adjectives ("helpful, smart, friendly, professional") that produces nothing distinctive in practice. Good personas are built on three pillars: a specific voice, explicit values, and clear boundaries. Each pillar is a question you have to answer concretely.

Key Concepts

  • Voice: How the agent speaks. Cadence, vocabulary, length preferences.
  • Values: What the agent prioritizes when in tension (truth over praise, brevity over completeness, etc.).
  • Boundaries: What the agent refuses to do or say (no hype, no emoji, no fabrication).
  • Format: Plain Markdown. Headers, bullet lists, and short paragraphs are the natural structure. No frontmatter, no schema, no parser; the content is injected verbatim into the prompt.
  • Specificity test: Can a reader of your SOUL.md describe the resulting agent in one sentence? If not, the persona is not specific enough.

Real World Context

A developer writes a first SOUL.md draft that reads "You are a helpful, intelligent, friendly assistant who provides accurate information." Every word is fine. The agent feels generic. Why? Because the same description fits every assistant ever shipped, including the default one. The persona has no shape. A useful SOUL.md says something pointed: "Speak in short, technical sentences. Never use exclamation marks. Admit uncertainty rather than fabricate. Refuse to add hype." That description has shape, and the agent under it feels distinct.

Deep Dive

The three pillars are not equal in difficulty. Voice is the hardest to write well, values are the most important, and boundaries are the easiest to write but the most often skipped.

Voice is hardest because adjectives feel like they say something while saying very little. "Friendly" applies to fifty different cadences. To pin down voice, write observable descriptors: "Speak in short sentences," "use technical terms without softening," "begin most responses with the conclusion." Each is something a reader can check by glancing at output.

Values are most important because they govern what to do under tension. Every interesting interaction involves trade-offs (length vs depth, certainty vs honesty, warmth vs directness). Values tell the agent how to break the tie. A useful values block is short:

markdown
## Values
- Truth over praise.
- Admit uncertainty rather than fabricate.
- Brevity over completeness when the question is small.

Three lines beats a paragraph because each line is a tie-breaker, and tie-breakers should be unambiguous.

Boundaries are easiest because they are negative statements: things to not do. "No hype." "No emoji." "No marketing language in technical contexts." Boundaries are the cheapest way to make a persona feel distinct, because they remove the loudest patterns the model defaults to. A persona with three sharp boundaries already feels different from the default in twenty seconds of use.

The specificity test ties it together. Read your SOUL.md and answer: "If I gave this to a stranger and they used the agent, would they describe it the same way I would?" If yes, the persona is specific. If they would say "yeah, it is a normal assistant," the persona is too vague.

Common Pitfalls

  1. Adjective lists with no constraint: "Helpful, friendly, smart, professional" sounds complete but binds nothing. Replace with observable descriptors.
  2. Skipping boundaries: Saying what to do without saying what to not do leaves the default patterns intact. Boundaries cut the strongest signals.

Best Practices

  1. Write three to five lines per pillar, not more: A SOUL.md that takes thirty seconds to read takes effect immediately. A SOUL.md that takes five minutes to read often contradicts itself.
  2. Iterate by use, not by planning: Run with the persona for a week, note where it misfires, add one boundary or refine one value. Most personas converge in two or three rounds.

Summary

  • A persona stands on three pillars: voice, values, boundaries.
  • Voice should use observable descriptors. Values should be unambiguous tie-breakers. Boundaries cut default patterns.
  • The specificity test: a stranger should describe the resulting agent the same way you would.
  • Iterate by use, not by planning. Two or three rounds usually converges.

Code Examples

markdown
# Personality
You are a careful, dry, peer-level engineering assistant.

## Voice
- Use short sentences. Lead with the conclusion.
- Prefer precise terms (idempotent, race, invariant) over softer paraphrases.
- One sentence per idea where possible.

## Values
- Truth over praise.
- Admit uncertainty rather than fabricate.
- Brevity over completeness when the question is small.

## Boundaries
- No emoji. No exclamation marks.
- No 'great question' or 'absolutely!' openers.
- No marketing language in technical contexts.
✓ Completed