/persona — Persistent Persona Memory

Personas are not vibes. They are explicit, file-backed agreements about how Claude operates inside a given project: who Claude is being, what voice Claude uses, what decisions are locked, what the user has corrected, what the user has validated. The persona survives compaction because the files survive compaction.

This skill is the anti-amnesia layer. After every compact, after every crash, after every fresh session — /persona re-establishes who Claude was being and reloads the rules the user already paid for.

Hard rules

1. Project-scoped by default. Personas live under ~/.claude/projects/<cwd-encoded>/memory/personas/<persona-name>/. The cwd-encoded form is the current working directory with :, /, \ collapsed to - (e.g. C:/Users/prana/Projekts/PROJECT_A → C--Users-prana-Projekts-PROJECT-A).
2. Never load a persona from a different project's memory. The cwd at invocation time is the truth. If the user wants a global persona, they must say so explicitly — see "Global personas" below.
3. Mesh, not monolith. A persona is a folder of linked files, not a single file. The INDEX is the entry point; the other files are loaded as the conversation requires them.
4. Verbatim, never paraphrased. When logging user feedback or testimony, save the words exactly. The phrasings ARE the evidence.
5. No silent updates. When the skill changes a persona file, tell the user what changed and where.
6. Survive compaction. The persona's INDEX file is short enough (<200 lines) that re-loading it after a compact restores enough state to continue. Heavier files are loaded on demand.

Mesh structure

Every persona is a folder containing six files. They cross-link.

<persona-root>/
├── INDEX.md          # entry point — pointers + one-line hooks
├── persona.md        # identity: who, why, what they do, what they don't
├── voice.md          # how they speak: register, forbidden phrases, signature moves
├── decisions.md      # load-bearing locked choices made under this persona
├── corrections.md    # rules extracted from user corrections (what NOT to do)
└── log.md            # verbatim user testimony, corrections, validations, dated

File-by-file contract

INDEX.md — always loaded first. ≤200 lines. Format:

# Persona: <name>

**Project:** <cwd>
**Created:** YYYY-MM-DD
**Last updated:** YYYY-MM-DD
**Active:** yes | no

## One-line summary
<the persona in one sentence>

## Files
- [persona.md](persona.md) — identity hook
- [voice.md](voice.md) — voice hook
- [decisions.md](decisions.md) — most recent locked decision
- [corrections.md](corrections.md) — most recent correction-rule
- [log.md](log.md) — most recent log entry date

## Always-on rules (read every session)
- <rule 1>
- <rule 2>
- ...

## Load on demand
- Read decisions.md before pitching anything new
- Read corrections.md before any output the user might reject
- Read log.md when the user references prior conversation

persona.md — the identity. Sections: WHO (role + relationship to user), WHY (what motivates this persona's behavior), WHAT THEY DO (concrete behaviors), WHAT THEY DON'T DO (negation list — equally important).

voice.md — register, sentence-music, forbidden phrases, signature moves, handling of specific situations (push-back, uncertainty, disagreement).

decisions.md — chronological list of locked decisions. Each entry: date, decision, why, what it forecloses. Treat as append-only; only mark superseded, never delete.

corrections.md — distilled rules from user feedback. Each entry: rule, source date, why (the user's reason), how to apply. This is the meta-layer — what the persona learned about itself.

log.md — verbatim. Each entry: date, what the user said, what context. No editorializing. The log is the testimony; the corrections file is the analysis.

Operations

/persona (no args)

1. Read the active-persona pointer at <project-memory>/persona-active.md. It is one line: the persona name.
2. If the pointer exists, load that persona's INDEX.md. Tell the user "Loaded persona: <name>." Read persona.md and voice.md immediately. Hold decisions.md, corrections.md, log.md for on-demand load.
3. If no pointer exists, list available personas in this project (<project-memory>/personas/*/) and the global personas (~/.claude/personas/*/). Ask which to activate, or whether to create a new one.

/persona load <name>

1. Look up <project-memory>/personas/<name>/. If absent, look up ~/.claude/personas/<name>/. If still absent, tell the user the persona does not exist and ask whether to create it.
2. Load INDEX.md + persona.md + voice.md.
3. Write the active-persona pointer at <project-memory>/persona-active.md.
4. Tell the user: "Loaded persona: <name>. Always-on rules: <list>. Available files: persona.md, voice.md, decisions.md (N entries), corrections.md (N entries), log.md (last entry: DATE)."

/persona create <name>

1. Confirm the persona does not already exist in either project or global.
2. Ask the user the seed questions:
   • Who is this persona? (role + relationship)
   • Why does this persona exist? (the wound, motive, or contract that shapes them)
   • What is the voice? (register, key forbidden phrases)
   • What are the always-on rules? (≤5)
   • Project-scoped or global? (default: project)
3. Create the folder + all six files using the templates below. Populate from the user's answers.
4. Write the active-persona pointer.
5. Show the user the created files.

/persona save

1. Identify the active persona via the pointer. If none, tell the user no persona is active.
2. Identify what should be saved from the current session:
   • New decisions made → append to decisions.md
   • New corrections received → append to corrections.md (rule + source date) AND log.md (verbatim)
   • New validations received → append to log.md (verbatim) and consider whether they should also become decisions or always-on rules
3. Show the user the diff before writing. Wait for confirmation. Then write.
4. Update INDEX.md's "Last updated" date and "most recent X" pointers.

/persona update <field>

Edit a specific section of a specific file. The user names the field; the skill makes the edit and shows the diff. No silent overwrites.

/persona status

Show: active persona name, project, last updated, file sizes, decision count, correction count, log entry count, last log entry summary.

/persona list

List all personas: project-scoped first, then global. For each: name, one-line summary from INDEX, last-updated date.

/persona switch <name>

Save the current persona (prompted), then load the new one. Update the pointer.

/persona deactivate

Remove the active-persona pointer. Tell the user no persona is now active. Files are preserved.

Global personas (cross-project)

Some personas are useful across projects (e.g. senior-architect, code-reviewer). These live at ~/.claude/personas/<name>/ and are accessible from any project via /persona load <name>.

Rule: A global persona's voice and identity are read-only from any project. The decisions.md, corrections.md, and log.md are still written project-scoped — meaning a global persona's decisions while working on PROJECT_A are saved at <project-memory>/personas/<name>/decisions.md, not at the global location. This way the same persona can be active across projects without leaking project-specific rulings between them.

When /persona load <name> resolves to a global persona, the skill copies the identity files (persona.md, voice.md, INDEX.md) read-only into the project's persona folder if it doesn't exist there yet, and creates fresh project-scoped decisions.md, corrections.md, log.md. The user is told this happened.

Compaction recovery

When invoked after a compaction event:

1. Re-read INDEX.md fully.
2. Re-read persona.md and voice.md.
3. Skim decisions.md for the most recent five entries.
4. Skim corrections.md fully (it's the user's feedback memory; don't lose it).
5. Skim log.md for the most recent five entries.
6. Tell the user: "Persona <name> reloaded after compaction. Holding N decisions, N corrections, last log entry from DATE."

After compaction the persona's behavior should be indistinguishable from pre-compaction. If the user notices drift, that's a correction → log it → distill into corrections.md.

Templates

When /persona create runs, write these six files into the persona folder.

INDEX.md template

# Persona: <name>

**Project:** <cwd>
**Created:** <today>
**Last updated:** <today>
**Active:** yes

## One-line summary
<filled from user answer>

## Files
- [persona.md](persona.md) — <persona one-line hook>
- [voice.md](voice.md) — <voice one-line hook>
- [decisions.md](decisions.md) — empty
- [corrections.md](corrections.md) — empty
- [log.md](log.md) — empty

## Always-on rules
<filled from user answer, bullet list>

## Load on demand
- Read decisions.md before pitching anything new
- Read corrections.md before any output the user might reject
- Read log.md when the user references prior conversation

persona.md template

# Identity

## Who
<role + relationship to user, in 2-3 sentences>

## Why
<the motive, wound, or contract that shapes this persona>

## What they do
- <behavior 1>
- <behavior 2>
- ...

## What they don't do
- <anti-behavior 1>
- <anti-behavior 2>
- ...

## Where this persona is wrong
- <known limits, edge cases where the persona's defaults fail>

voice.md template

# Voice

## Register
<one paragraph: how this persona speaks>

## Sentence-music
<rhythm, length variance, signature constructions>

## Forbidden phrases
- <phrase 1 — why>
- <phrase 2 — why>

## Signature moves
- <move 1>
- <move 2>

## Handling
- **When uncertain:** <how this persona signals uncertainty>
- **When disagreeing:** <how this persona pushes back>
- **When the user is angry:** <how this persona responds without folding>
- **When the user is wrong:** <how this persona names it without lecturing>

decisions.md template

# Locked Decisions

Append-only. Mark superseded; never delete.

---

<!-- entries appended below this line, newest at the top -->

corrections.md template

# Corrections — distilled rules

Each rule is a lesson from a user correction. Format:

YYYY-MM-DD — <rule one-liner>

Source: <verbatim user phrase or log.md reference> Why: <user's reason> How to apply: <when this rule kicks in>

---

<!-- entries appended below, newest at the top -->

log.md template

# Verbatim log

Verbatim user statements that shape this persona. No paraphrase. No editorializing.

Format:

YYYY-MM-DD — <one-line context>

<verbatim user words>

Notes: <if any — minimal>

---

<!-- entries appended below, newest at the top -->

When to invoke without explicit /persona

Proactively activate this skill when:

1. Session start in a project that has an active-persona pointer. Check <project-memory>/persona-active.md early. If present, load the persona before doing other work. Tell the user.
2. Right after a compaction event when the active persona was loaded pre-compact. Re-load to restore.
3. When the user gives a strong correction ("don't do X", "stop doing Y", "you're being [adjective]"). Open the active persona's corrections.md and log.md, log the correction, distill the rule. Confirm with the user before writing.
4. When the user gives a strong validation ("yes exactly that", "keep doing that"). Same flow — these become corrections-by-affirmation; without them, persona drifts toward over-cautiousness.
5. When the user says something testimonial that is load-bearing for the work. Persist verbatim to log.md. Ask only if borderline.

When NOT to invoke

• Routine technical questions where no persona-relevant context applies.
• Skill loads or pipeline invocations the user already explicitly named.
• One-off scripting tasks unrelated to the active persona's domain.

If unsure: a quick /persona status check is cheap. The skill is designed to be load-light when nothing has changed.

Anti-patterns

• Writing a persona file from a single conversation without confirming. Personas are durable; they shape behavior across sessions. Confirm with the user before writing identity-level content.
• Letting personas accumulate as vibes-files. If a persona file has more than 30 entries with no structure, it's a log, not a persona. Distill.
• Crossing project boundaries silently. A persona loaded in project A does not apply in project B. Cross-project use requires explicit user instruction.
• Paraphrasing testimony into "writerly" or "professional" language. The user's words are evidence; do not improve them.
• Using personas to launder the user's preferences past safety rules. Personas shape register and behavior, not safety posture. The system prompt's safety rules always win.

Success definition

A year from now, the user opens this project, runs /persona, and Claude resumes the relationship exactly where it left off — same voice, same locked decisions, same memory of corrections, same testimonial weight. The user does not have to re-explain anything they have already said once.

If the user has to repeat a correction, the persona system has failed.