StoryForge Charakter-Anatomie

English Version

Zurück zur StoryForge-Hauptseite

Überblick

Jede Figurendatei eines Buchs wird nach dem Speichern vom PostToolUse-Hook validate_character.py geprüft. Diese Seite beschreibt:

• das Frontmatter-Schema und was der Hook nach dem Speichern beanstandet
• die Rollen und die Status-Stufen einer Figur
• die empfohlenen Abschnitte und wann Nebenfiguren weniger brauchen
• die Alias-Auflösung für characters_present im Brief
• das Verhalten des Hooks im Detail
• Serien-Tracker und den Serien-Lebenszyklus

Die Vorlage liegt im Plugin unter templates/character.md und enthält Hinweise zu jedem Abschnitt.

Speicherort

Eine Datei je Figur. INDEX.md wird vom Hook übersprungen. Bei Memoir folgen die Personendateien einem anderen Schema, siehe Memoir-Unterstützung.

Frontmatter

Der Hook verlangt mindestens:

---
name: "Anzeigename"
role: protagonist
status: Concept
---

Bei Fiction-Figuren sind name, role und status Pflicht. Fehlt eines, meldet der Hook das nach dem Schreiben mit Exit-Code 2 an das Modell zurück, das es ergänzen muss. Bei Memoir-Personendateien entfällt role, siehe Abschnitt „Memoir-Personendateien" unten. Weitere Felder wie age, job, description, archetype oder pov sind freie Metadaten, die der Hook ignoriert. Die Vorlage führt zusätzlich gender (leer vorbelegt) und aliases (auskommentiert) mit.

Optional sind diese Blöcke, die Prüf-Werkzeuge auswerten:

• tactical: für Kampf- und Reiseszenen, siehe Technische Details
• knowledge: für die POV-Grenze, siehe Technische Details

Zustand der POV-Figur

Inventar, Kleidung, Verletzungen, veränderte Zustände und Wahrnehmungs-Dämpfer der POV-Figur liest der Chapter Writing Brief in dieser Reihenfolge:

1. die Frontmatter-Felder current_inventory, current_clothing, current_injuries, altered_states und environmental_limiters der Figurendatei, falls vorhanden
2. der Snapshot in der Datenbank der Serie, den chapter-writer beim Abschluss eines Kapitels mit update_character_snapshot schreibt (die Figurendatei bleibt dabei unverändert)
3. Heuristiken über die Kapitel-Timeline und die Entwürfe

Ein Frontmatter-Feld as_of_chapter darf in der Datei stehen, der Brief liest es aber nicht.

Wenn keine Quelle etwas liefert, steht im Brief eine Warnung, und der Skill fragt nach, statt zu erfinden. Frontmatter-Werte entstehen zum Beispiel durch das Bootstrapping aus einem Vorgängerband oder durch deine Hand.

Herkunfts-Marker series_evolution_imported_from

Befüllt /storyforge:bootstrap-book-from-series eine Figurendatei, trägt sie das Feld series_evolution_imported_from: B1. Es ist informativ und sagt, aus welchem Band die Startwerte stammen. Danach kannst du jedes Feld frei ändern.

Alias-Auflösung

scan_for_named_characters füllt characters_present im Brief, indem es das Feld name und alle Aliase im Outline sucht. Zwei Quellen werden kombiniert:

• Aus dem Namen: Jeder in Anführungszeichen stehende Teil von name gilt als Alias. Aus Theodore "Theo" Wilkons wird Theo.
• Explizit: aliases: ["S.", "Sera"] im Frontmatter.

Gesucht wird mit Wortgrenzen, Lin trifft also nicht in Linguistics, und Initialen mit Punkt funktionieren.

Gültige Rollen

Eine unbekannte Rolle erzeugt eine Warnung mit der Liste der gültigen Werte.

Status-Stufen

Concept → Profile → Backstory → Arc Defined → Final

Der Status ist ein Signal an dich, wie reif die Datei ist. Er steuert kein Werkzeug.

Empfohlene Abschnitte

Der Hook warnt, wenn diese bei einer Figur fehlen, die nicht minor ist. Er akzeptiert Überschriften der Ebene 2 und 3.

Want vs. Need

Das äußere Ziel gegen die innere Wahrheit. Dazu gehört die Lüge, die die Figur glaubt und die sie am Need hindert.

Beispiel: Want: beweisen, dass er mehr ist, als andere sehen. Need: akzeptieren, dass er genug ist. Lüge: „Ich bin nicht genug.“

The Ghost

Das einzelne einschneidende Ereignis oder die anhaltende Bedingung, die die Figur geprägt hat. Es ist die Wurzel der Lüge. Die Vorlage legt es als ### The Ghost unter ## Backstory an.

Fatal Flaw

Kein bloßer Schwachpunkt, sondern ein Fehler, der aktiv Probleme verursacht, mit dem Thema verbunden ist und im Ghost wurzelt.

Motivation Chain

Drei Mal „warum?“: erst das genannte Ziel, dann der emotionale Motor, dann das wundengetriebene Kern-Need.

Character Arc

Bogentyp (positiv, negativ, flach) plus Beats: Setup, Challenge, Midpoint, Crisis, Resolution. Pflicht für den Status Arc Defined.

Relationships

Die Vorlage führt den Abschnitt als ## Key Relationships, und genau diese Überschrift akzeptiert der Harvest-Reader von /storyforge:harvest-character-evolution auch — ebenso ## Relationships, ## Relationship und ## Beziehungen (mit oder ohne Zusatz „über die Bände"). Eine Umbenennung ist also nicht nötig. Bullets mit fettem Namen sind das übliche Format:

## Relationships

- **Theo:** Partner, die Beziehung, die ihn in die Familie zurückzieht.
- **Caelan:** Vater, sein am längsten ungelöster Konflikt.

Wann Figuren weniger brauchen

Nicht jede benannte Figur braucht Arc Defined. Der Hook ist hier nur ein Signal, der Maßstab hängt von der Rolle ab:

Verhalten des Hooks

Der Hook läuft als PostToolUse nach Write, Edit und MultiEdit auf .md-Dateien in characters/ und people/. Die Datei ist zu diesem Zeitpunkt schon geschrieben. Exit-Code 2 gibt die Meldung an das Modell zurück, das den Fund beheben muss.

Was mit Exit-Code 2 gemeldet wird

Was warnt (Exit-Code 0)

Was übersprungen wird

• Dateien außerhalb von characters/ und people/
• INDEX.md
• genau der Tracker-Pfad series/{serie}/characters/{datei} bzw. series/{serie}/people/{datei} — die letzten vier Pfadsegmente müssen exakt series / Serien-Slug / characters oder people / Dateiname lauten. Figurendateien von Büchern, die unter series/{serie}/{buch}/characters/ liegen, treffen dieses Muster nicht und werden wie jede andere Figurendatei geprüft.

Memoir-Personendateien

Dateien, die am Frontmatter (person_category, consent_status oder real_name) als Memoir-Personendateien erkennbar sind, bekommen eine verkürzte Prüfung: Der Wert von role wird nicht gegen die Rollenliste abgeglichen, und die empfohlenen Abschnitte der Fiction-Figuren entfallen. role ist bei ihnen auch kein Pflichtfeld mehr — Pflicht sind nur name und status. Das Tool create_person schreibt status, aber kein role, und besteht die Prüfung damit direkt. Details: Memoir-Unterstützung.

Serien-Tracker

Serien-Projekte haben je Figur zusätzlich eine Tracker-Datei unter series/{serie}/characters/{tracker-slug}.md. Das ist eine dünne Serien-Ebene: Sie hält fest, was über alle Bände konstant ist, und führt die Entwicklung je Band.

Verknüpft sind beide über das optionale Feld book_slug im Tracker. Fehlt es, gilt der slug des Trackers als Slug der Buch-Datei:

---
name: "King Caelan"
slug: king-caelan          # Slug des Trackers
book_slug: caelan          # optional: Buch-Datei ist caelan.md
role: protagonist
species: vampire
status: "Profile"
recurs_in: ["B1", "B2"]
tracker_type: "thin"
---

Das Feld brauchst du nur, wenn der Tracker einen Rollen- oder Titel-Slug trägt, die Buch-Datei aber den bloßen Namen. Ohne die Verknüpfung liefert der Brief für diese Figur series_evolution: null.

tracker_type ist thin (Standard, die Buch-Datei bleibt Quelle der Wahrheit) oder full (der Tracker selbst, selten).

Aufbau eines Trackers

## Snapshot
Ein Absatz Essenz im Serien-Maßstab: Was ist über alle Bände konstant?

## Evolution per Band
### B1 Start
### B1 Ende
### B2 (geplant)

## Beziehungen über die Bände
- **Andere Figur:** B1-Dynamik → B2-Wandel → B3-Auflösung

## Updates Log

Der Parser kennt zwei Formen: Bullets je Band (### B1 Firelight mit **Start:** und **Ende:**) und getrennte H3-Überschriften (### B1 Start, ### B1 Ende). Schreibende Skills behalten die Form bei, die dein Tracker schon nutzt. Die Vorlage ist templates/series-character-tracker.md.

Serien-Lebenszyklus

So wandert eine Figur von einem Band in den nächsten:

1. Während Band 1: Beim Abschluss eines Kapitels mit Status Review oder Final schlägt chapter-writer einen Snapshot der POV-Figur vor und speichert ihn nach deiner Bestätigung in der Datenbank. Bleibt das Kapitel auf Draft, entfällt der Vorschlag.
2. Band 1 ist abgeschlossen: Der Buchstatus läuft über Drafting und Revision auf Proofread, sobald alle Kapitel Final sind. Editing, Export Ready und Published setzt du selbst. Steht das Buch auf Export Ready oder Published, läuft /storyforge:harvest-character-evolution firelight ohne Rückfrage los. Bei Editing oder Proofread fragt der Skill, ob er trotzdem laufen soll, früher blockt er. Er liest den Endzustand jeder wiederkehrenden Figur und ihre Beziehungen, synthetisiert eine Zusammenfassung „B1 Ende“ und geht die Figuren einzeln mit dir durch (übernehmen, ändern, überspringen, bestehendes behalten). Bestätigtes landet im Tracker, dazu ein Eintrag im Updates Log.
3. Band 2 anlegen: /storyforge:new-book fragt selbst nach Serie und Nummer und registriert das Buch bei bekannter Nummer noch während des Anlegens per add_book_to_series. Ist die Serie und Nummer bekannt, kopiert der Skill danach automatisch die wiederkehrenden Figurendateien (gefiltert nach recurs_in) mit copy_recurring_chars_to_new_book 1:1 ins neue Buch, nach deiner Bestätigung. Figuren, die nur in Band 1 vorkommen, bleiben außen, neue Figuren von Band 2 legst du manuell an. Der Kopierschritt leitet das Band-Kürzel aus series_number ab und überspringt sich, wenn die Nummer fehlt, 0 oder 1 ist. Wurde die Nummer beim Anlegen offen gelassen und trägst du sie erst später über add_book_to_series nach, läuft dieser automatische Kopierschritt nicht mehr, du kopierst dann selbst. Die Reihenfolge zeigt das Series-Workflow-Beispiel.
4. Bootstrap: /storyforge:bootstrap-book-from-series firelight moonrise liest je Tracker „B1 Ende“ und „B2 (geplant)“, synthetisiert einen Startzustand, geht die Figuren einzeln mit dir durch und schreibt ihn ins Frontmatter der Figurendatei im neuen Band, samt series_evolution_imported_from. Steht der Vorgängerband noch nicht auf Export Ready oder Published, fragt der Skill, ob er trotzdem laufen soll.
5. Schreiben: chapter-writer liest characters_present[*].series_evolution: den Endzustand im Vorgängerband (previous_book_end), den Plan für den aktuellen Band (current_book_plan) und die Beziehungsentwicklung (relationships_evolution). Das befüllt der Brief für Bücher in beiden Ablagen, flach unter projects/{buch} und verschachtelt unter series/{serie}/{buch}.
6. Von vorn: Ist Band 2 auf dieselbe Weise abgeschlossen, läuft das Harvest erneut für Band 3.

Ein komplettes Beispiel mit allen Ausgaben steht unter Series-Workflow-Beispiel.

Wann series_evolution leer bleibt

Das Feld ist im Brief immer vorhanden, damit Verbraucher auf null prüfen können. Es ist null, wenn eine dieser Bedingungen zutrifft:

• Das Buch gehört zu keiner Serie: Eigenständige Romane tragen kein series: in der README. harvest-character-evolution meldet dann, dass das Buch zu keiner Serie gehört, und endet sauber. bootstrap-book-from-series verlangt, dass beide Bücher dieselbe Serie teilen.
• Die series_number des Buchs ist kleiner als 1. Ein Buch, das noch nicht mit add_book_to_series nummeriert wurde, hat series_number 0 oder keine.
• Es gibt keinen Tracker für den Buch-Slug der Figur, oder der Tracker enthält für den aktuellen Band weder Start-, Ende- noch Geplant-Text. recurs_in prüft der Brief dafür nicht.

← Zurück zur StoryForge-Hauptseite