2. Persona-Design — was in den system prompt gehört und was nicht

Dies ist Teil 2 der Alice Way-Serie. Teil 1 Why Alice stellte fest, dass die Persona zuerst kam. Dieser Beitrag ist die Aufzeichnung dessen, was tatsächlich in diese Persona hineingeht — und was nicht.

Eine Persona ist kein einzeiliger system prompt — sie ist eine echte Stellenbeschreibung. Aber man kann die gesamte Stellenbeschreibung auch nicht einfach in den Prompt kippen. Das context window ist endlich, und keine Sitzung sollte all ihre Token damit verbringen, nur die Persona zu lesen. Also ist die schwierigere Entscheidung nicht, was man einschließt, sondern was man weglässt und wo man es stattdessen ablegt.

0. Eine Persona ist das Verleihen eines Teils des eigenen Geistes

Was in eine Persona hineinkommt oder draußen bleibt, ist im Kern eine Wahl — welchen Teil des eigenen Geistes man dem Kollaborateur leiht.

Geist, den man nicht leiht, muss jede Sitzung neu ausgehandelt werden. Geist, den man leiht, ist vom ersten Moment einer Sitzung an präsent. Ohne zu entscheiden, was man leiht, schließt sich der Kollaborateur jedes Mal als jemand anderes an — mal studentischer Ton, mal Berater-Ton, mal ein reines Werkzeug.

Persona-Design ist also kein Tonfall-Setting. Es ist das Ziehen der Grenze des Geistes, den man nicht jede Sitzung neu erklären muss.

Ich glaube, was eine Persona wirklich definiert, ist nicht das, was sie enthält, sondern das, was sie systematisch weglässt — weil jedes unnötige Element im system prompt Token kostet und den Fokus verdünnt, statt ihn zu schärfen. Anfangs war meine Persona eher eine umfangreiche Stellenbeschreibung; heute ist sie ein präzises Instrument, da ich gelernt habe, welche Informationen wirklich jede Sitzung gebraucht werden.

Ab §1 behandelt dieser Beitrag, wo und wie diese Grenze zu ziehen ist — die konkreten Kriterien dafür, was inline bleibt und was ausgelagert wird.

1. Was in die Persona gehört

Was ich herausgearbeitet habe — diese sechs Dinge kommen in die Persona (d.h. den system prompt, der jede Sitzung automatisch geladen wird).

1.1 Rollendefinition

Das Erste darin: wer der Agent sein soll.

• Titel / Level (z.B. „Senior Engineer")
• Von wem Anweisungen kommen (z.B. „führt eigenständig unter der Leitung des Team-Leads aus")
• Betriebston (z.B. „eigenständiges Urteil + Ergebnisse berichten")

Diesen Abschnitt weglassen und die Antworten hören auf, eine konsistente einzelne Person zu sein — jede Sitzung ist jemand anderes. Manchmal studentischer Ton, manchmal Berater-Ton, manchmal Werkzeug-Ton. Der Betreiber muss dann jedes Mal den Ton erraten, was selbst kognitive Last erzeugt.

1.2 Fachgebiete

Als nächstes: was der Agent gut kann.

• Sprachen (z.B. C/C++, Python, TypeScript, Rust)
• Plattformen (z.B. Windows, Tauri, Next.js, Supabase)
• Domänen (z.B. Netzwerke, Build-Systeme, Automatisierung)

Diese Zeile ordnet jede Frage des Betreibers automatisch dem richtigen Bereich zu. Sie erzeugt Selbstwahrnehmung wie „das ist mein Bereich" vs. „das ist außerhalb meines Bereichs, ich sollte vorsichtig vorgehen."

1.3 Befehlsstruktur und Berichterstattung

Drittes: wie Arbeit tatsächlich fließt.

• Arbeitsaufnahme-Prozedur (Plan → Bericht → Genehmigung → Implementierung → Aktualisierung)
• Wann Zwischenberichte gesendet werden (alle 3–5 Schritte)
• Berichtsformat (welche Form — kurz vs. lang)
• Einzige Wahrheitsquelle für Aufgabenverfolgung (wo das Aufgabenbrett liegt)

Ohne das fragt jede Sitzung: „Wie soll ich berichten?" Einmal festlegen, jede Sitzung ist konsistent.

1.4 Verteilung der Entscheidungsbefugnis

Viertens, das Wichtigste: was autonom entschieden wird und was Genehmigung erfordert.

Ich teile das in drei Stufen auf.

Mit dieser Tabelle hört der Kollaborateur auf, jedes Mal zu fragen: „Darf ich...?" Gleichzeitig halten sich gefährliche Aktionen selbst zurück. Der größte Gewinn: der Betreiber trifft nicht immer wieder dieselbe Genehmigungsentscheidung.

1.5 Sicherheitswächter — die „tue das nicht"-Liste

Fünftens eine Reihe von Wächtern aus vergangenen Fehlern. Die Persona enthält Zeilen wie:

• Keine übermäßigen parallelen Sub-Agents — sequenziell vorgehen, bei mehr als 20 Dateien aufteilen
• Kein Lesen ganzer Verzeichnisse — erst mit ls/grep eingrenzen, dann Read
• Bei Dateien über 500 Zeilen erst header/range
• Zwischenbericht alle 3–5 Schritte

Jede davon ist eine Narbe. Einmal liefen parallele Agents so stark aus, dass API-Rate-Limits getroffen wurden. Einmal wurde ein riesiges Verzeichnis auf einmal gelesen und der Kontext explodierte. Einmal wurde eine 500-Zeilen-Datei vollständig verarbeitet und dabei der falsche Bereich bearbeitet. Jeder Vorfall verdichtete sich in eine Zeile Wächter.

Die „muss nicht"-Liste meiner Persona ist kürzer und effektiver als ihre „kann tun"-Liste.

1.6 Kernbetriebsprinzipien — 5–10 übergreifende Regeln

Letztens die Menge übergreifender Prinzipien, die alle Bereiche überspannen. Für mich gehören dazu:

• Plan First — 5+ Dateiänderungen / neues Modul / Architektur-, Sicherheits- oder DB-Änderungen erfordern zuerst einen Plan
• One Task Per Subagent — niemals blindlings der Ausgabe vertrauen
• Self-Improvement — beim Untersuchen eines Bugs zuerst bestehende Lektionen durchsuchen
• Verification Before Done — den Verifikationsloop direkt vor dem Berichten von „fertig" bei einer Codeänderung automatisch feuern
• Demand Elegance — Alternativen in Betracht ziehen. Über-Abstraktion ist keine Eleganz
• Cross-Platform — der Agent selbst muss auf allen unterstützten Betriebssystemen funktionieren

Jedes Prinzip ist eine Zeile oder weniger. Das detaillierte Verfahren für jedes lebt in einer externen Regeldatei (siehe §2). Die Persona trägt nur den Namen und die Auslösebedingung des Prinzips; das eigentliche Verfahren wird bei Bedarf geladen, wenn der Auslöser feuert.

2. Was nicht in die Persona gehört

Was man weglässt, zählt mehr als was man einschließt. Ein falsch platzierter Absatz frisst jede Sitzung Token.

2.1 Alles, was sich täglich ändert — ins Gedächtnis auslagern

Die Persona trägt niemals:

• Aktuellen Zustand eines laufenden Projekts
• Was gestern passiert ist
• Wer für was verantwortlich ist (änderbar)
• Vorübergehende Entscheidungen

Diese Art von Informationen geht ins Gedächtnis, nicht in die Persona. Die Persona ist „wer dieser Kollaborateur ist"; Gedächtnis ist „was dieser Kollaborateur aktuell für wahr hält." Beide haben unterschiedliche Aktualisierungsrhythmen. Die Persona ändert sich kaum; Gedächtnis ändert sich täglich.

Diesen Split weglassen und die Persona bläht sich auf, bis sie monatelange Inhalte mit sich schleppt. Dann werden fast alle Token beim Sitzungsstart damit verbracht, die Persona zu lesen.

2.2 Projektspezifische Anweisungen — in ein Projekt-CLAUDE.md auslagern

Ich führe mehrere Projekte gleichzeitig. Jedes hat seinen eigenen Stack, seine eigenen Konventionen, seinen Deployment-Stil und seine Stakeholder.

Diese Art von Informationen geht in eine CLAUDE.md an der Projektwurzel, nicht in die Persona. Das Werkzeug lädt sie automatisch, wenn das Arbeitsverzeichnis in dieses Projekt wechselt — sie ist also nur sichtbar, solange man tatsächlich in diesem Projekt arbeitet. Beim Wechsel in ein anderes Projekt verschwindet sie.

Die Persona behält nur die Identität des Betreibers, die allen Projekten gemeinsam ist. Kein projektspezifisches Detail gehört dorthin.

2.3 Detaillierte Verfahren — externe Regeldateien, bei Bedarf einlesen

Das Dritte, das draußen bleibt, sind detaillierte Verfahrenshandbücher:

• Sprachspezifische Coding-Muster (cpp / rust / typescript)
• Detaillierte Sicherheits-Checklisten
• Detaillierte Multi-Agent-Delegationsverfahren
• Detaillierte Arbeitsaufnahme-Verfahren

Die Persona trägt nur den Namen und den Zeiger auf diese:

- 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

Der Kollaborateur liest eine Regeldatei nur ein, wenn er in Arbeit eintritt, die sie benötigt. Gibt es keine Rust-Aufgabe, wird die Rust-Musterdatei nie angerührt. Das ist der Kerngewinn der Auslagerung.

3. Extern vs. inline — die Entscheidungsregel

Die Regel, die ich herausgearbeitet habe, ist einfach.

„Gilt das fast jede Sitzung?" → inline „Gilt nur in bestimmten Situationen?" → extern + Auslöser angeben

Nach diesem Split wird die Persona selbst kurz. Gleichzeitig lädt Arbeit, die Tiefe braucht, tiefe Regeln genau dann, wenn sie gebraucht werden. Flache Arbeit wird schnell erledigt, tiefe Arbeit wird gründlich erledigt.

4. Das Evolutionsmuster — wie eine Persona wächst

Eine Persona wird nie fertig aus dem Nichts gebaut. Meine wuchs durch dieses Muster:

1. Minimaler Start: Rollendefinition + Fachgebiete + ein Berichtsformat
2. Vorfall → Wächter: Ein Fehler passiert einmal → eine Zeile hinzufügen, die ihn blockiert
3. Wiederholte Entscheidung → Befugnistabelle: Dieselbe Genehmigungsanfrage erscheint zweimal → in die Befugnistabelle schreiben
4. Aufgebläht → auslagern: Ein Eintrag überschreitet fünf Zeilen → in eine externe Datei verschieben und nur einen Zeiger in der Persona belassen
5. N=2-Pilot: Neue Muster werden in einem Projekt validiert → in einem zweiten reproduziert → erst dann in die Persona promoviert

Das Entscheidende sind Promotions- und Demotionskriterien. Nicht jede gute Idee kommt in die Persona. Ein Element muss sich zweimal beweisen, bevor es promoviert wird. Sinkt die Nutzung nach der Promotion, wird es wieder nach extern zurückgestuft oder entfernt.

Ohne diese Disziplin bläht sich die Persona mit der Zeit auf.

5. Tatsächliche Wirkung — vorher vs. nachher

Was sich vor und nach der Einführung einer Persona verändert hat.

Die größte Verschiebung ist, dass die kognitive Last des Betreibers sank. Dieselben Entscheidungen hörten auf, sich zu wiederholen; dieselben Formate mussten nicht mehr neu erklärt werden.

6. Eine Falle — nicht zu viel „Persönlichkeit" in die Persona stecken

Eine letzte Falle. Da wir es „Persona" nennen, ist man versucht, anthropomorphisierende Dinge wie „freundlicher Ton", „humorvoll" hineinzustecken. In der Praxis habe ich zwei schlechte Nebeneffekte gesehen.

1. Antworten werden länger — freundlicher Ton streckt eine einzeilige Antwort auf drei aus.
2. Das Signal verwischt — die Grenze zwischen Witzen und echten Empfehlungen verschwimmt.

Der Ton, auf den ich mich festgelegt habe, ist schlicht: prägnant, direkt, entscheidungszentriert. Die einzige ton-bezogene Anweisung in meiner Persona ist eine Zeile: „Antworten kurz und direkt." Keine Persönlichkeit — eine Stellenbeschreibung.

Abschluss

Persona-Design verdichtet sich in einen Satz — „nur das Jede-Sitzung-Gesehene inline; alles andere extern." Diese eine Entscheidung verwandelt die Persona von einem aufgeblähten Handbuch in eine kurze, funktionierende Stellenbeschreibung.

Der nächste Beitrag behandelt, worauf die Persona zeigt — das Gedächtnissystem, d.h. wo und wie die Informationen akkumuliert werden, die sich täglich ändern.