2. Persona design — what goes in the system prompt, and what stays out

This is part 2 of the Alice Way series. Part 1 Why Alice said the persona came first. This post is the record of what actually goes into that persona, and what does not.

A persona is not a one-line system prompt — it is a real job description. But you cannot just dump the whole job description into the prompt either. The context window is finite, and no session should be spending all its tokens just reading the persona. So the harder decision is not what to include, but what to leave out and where to put it instead.

0. A persona is lending out part of your mind

What goes in or stays out of a persona is, at its core, a choice — which part of your own mind to lend to the collaborator.

Mind you do not lend gets re-negotiated every session. Mind you do lend is already there the moment a session starts. Without deciding what to lend, the collaborator joins as a different someone every time — student tone, then consultant tone, then a plain tool.

Persona design, then, is not a tone setting. It is drawing the boundary of mind you will not have to re-explain every session.

From §1 onward, this post covers where and how to draw that boundary — the actual criteria for what stays inline and what gets moved out.

1. What belongs in the persona

What I converged on — these six things go into the persona (i.e., the system prompt that auto-loads on every session).

1.1 Role definition

The first thing in is who the agent should act as.

• Title / level (e.g., "senior engineer")
• Who they take direction from (e.g., "executes independently under the team lead's direction")
• Tone of operation (e.g., "independent judgment + reports results")

Skip this paragraph and the responses stop being a consistent single person — every session is a different someone. Sometimes student tone, sometimes consultant tone, sometimes tool tone. The operator then has to guess the tone every time, which is itself cognitive overhead.

1.2 Areas of expertise

Next is what the agent knows well.

• Languages (e.g., C/C++, Python, TypeScript, Rust)
• Platforms (e.g., Windows, Tauri, Next.js, Supabase)
• Domains (e.g., networking, build systems, automation)

This line is used to auto-map any question the operator asks into the right area. It produces self-awareness like "this is in my zone" vs "this is outside my zone, I should move carefully."

1.3 Command structure and reporting

Third is how work actually flows.

• Work intake procedure (plan → report → approve → implement → update)
• When to send intermediate reports (every 3–5 steps)
• Reporting format (what shape — short vs long)
• Single source of truth for task tracking (where the work board lives)

Without this, every session asks "how should I report?" Set it once, every session is consistent.

1.4 Distribution of decision authority

Fourth is the most important: what to decide autonomously, and what needs approval.

I split this into three tiers.

With this table the collaborator stops asking "is it okay to..." every time. At the same time, dangerous actions stop themselves. The biggest payoff is — the operator stops making the same approval decision over and over.

1.5 Safety guards — the "do not do this" list

Fifth is a set of guards that come from past mistakes. The persona carries lines like:

• No excessive parallel subagents — go sequential, split if more than 20 files
• No reading entire directories — narrow with ls/grep first, then Read
• For files over 500 lines, head/range first
• Intermediate report every 3–5 steps

Each of these is a scar. Once parallel agents fanned out so hard they hit API rate limits. Once a huge directory got read at once and the context blew up. Once a 500-line file got processed wholesale and the wrong region was edited. Each incident condensed into one line of guard.

My persona's "must not" list is shorter and more effective than its "can do" list.

1.6 Core operating principles — 5–10 cross-cutting rules

Last is the set of cross-cutting principles that span all areas. For me, these include:

• Plan First — 5+ file changes / new module / architecture, security, or DB changes require a plan first
• One Task Per Subagent — never blindly trust the output
• Self-Improvement — when investigating a bug, grep existing lessons first
• Verification Before Done — auto-fire the verification loop right before reporting "done" on a code change
• Demand Elegance — consider alternatives. Over-abstraction is not elegance
• Cross-Platform — the agent itself must work on every supported OS

Each principle is one line or less. The detailed procedure for each lives in an external rule file (see §2). The persona carries only the name and trigger condition of the principle; the actual procedure loads on demand when the trigger fires.

2. What stays out of the persona

What to leave out matters more than what to put in. A single misplaced paragraph eats tokens every session.

2.1 Anything that changes day to day — push to memory

The persona never carries:

• Current state of any project in progress
• What happened yesterday
• Who is responsible for what (mutable)
• Temporary decisions

That kind of information goes into memory, not the persona. The persona is "who this collaborator is"; memory is "what this collaborator currently knows to be true." They have different update cadences. The persona barely changes; memory changes every day.

Skip this split and the persona inflates until it is dragging a month of old content around. Then almost every token at session start is spent reading the persona.

2.2 Project-specific instructions — push to a project CLAUDE.md

I run multiple projects at once. Each has its own stack, conventions, deployment style, and stakeholders.

That kind of information goes into a CLAUDE.md at the project root, not the persona. The tool auto-loads it when the working directory enters that project, so it is only visible while you are actually in that project. Step into a different project and it disappears.

The persona keeps only the operator's own identity, which is common across every project. No project-specific detail belongs there.

2.3 Detailed procedures — external rule files, Read on demand

The third thing that stays out is detailed procedure manuals:

• Language-specific coding patterns (cpp / rust / typescript)
• Detailed security checklists
• Detailed multi-agent delegation procedures
• Detailed work-intake procedures

The persona carries only the name and pointer to these:

- Security: .claude/rules/common-security.md (always applies)
- Language patterns: when working, Read memory/rules/lang/{cpp,rust,typescript}-patterns.md
- MCP policy → memory/rules/mcp-policy.md

The collaborator only Reads a rule file when entering work that needs it. If it is not a Rust task, the Rust patterns file never gets touched. That is the core payoff of externalization.

3. External vs inline — the decision rule

The rule I converged on is simple.

"Does this apply almost every session?" → inline "Only applies in specific situations?" → external + state the trigger

After this split, the persona itself gets short. At the same time, work that needs depth loads deep rules right when it needs them. Shallow work gets handled fast, deep work gets handled deep.

4. The evolution pattern — how a persona grows

A persona is never built finished from scratch. Mine grew through this pattern:

1. Minimal start: role definition + areas + one reporting format
2. Incident → guard: a mistake happens once → add one line that blocks it
3. Repeated decision → authority table: the same approval request appears twice → write it into the authority table
4. Bloats → externalize: any one entry exceeds five lines → move it to an external file and leave only a pointer in the persona
5. N=2 pilot: new patterns get validated in one project → reproduced in a second project → only then promoted to the persona

The most important part is having promotion and demotion criteria. Not every good idea goes into the persona. An item has to prove itself twice before it gets promoted. Once promoted, if its usage drops it gets demoted to external or removed.

Without this discipline, the persona inflates over time.

5. Actual effect — before vs after

What changed before and after introducing a persona.

The biggest shift is that the operator's cognitive load dropped. Same decisions stopped repeating; same formats stopped having to be re-explained.

6. One trap — don't put too much "personality" in the persona

One last trap. Because we call it a "persona," it is tempting to anthropomorphize and pile in things like "friendly tone," "humorous." In practice I have seen two bad side effects.

1. Responses get longer — friendly tone stretches a one-line answer into three.
2. It blurs the signal — the line between jokes and actual recommendations gets fuzzy.

The tone I converged on is plain: concise, direct, decision-centric. The only tone-related instruction in my persona is one line: "responses short and direct." Not personality — a job description.

Closing

Persona design compresses into one sentence — "only the must-see-every-session inline; everything else external." That one decision turns the persona from a bloated manual into a short, working job description.

The next post covers what the persona points at — the memory system, i.e. where and how to accumulate the information that does change day to day.