# Character Template

Use this template when creating a new character file at `characters/{character-name-kebab}.md`.

```yaml
---
name: "{Full Name}"
role: {protagonist|antagonist|supporting|minor|narrator|deuteragonist}
status: {alive|deceased|unknown|missing}
died-in: {chapter-NN}
aliases:
  - "{Alias 1}"
relationships:
  - character: {other-character-kebab}
    type: {relationship-type}
locations:
  - {location-kebab}
tags:
  - {tag-1}
  - {tag-2}
arc: {character-arc-theme}
arc-type: {change-positive|change-negative|flat}
lie: "{The false belief the character clings to}"
truth: "{The belief that would set them free}"
ghost-wound: "{The past wound that made the lie feel true}"
---
```

`died-in` is optional. Set it (with `status: deceased`) when a character dies on the page so `story continuity` can flag appearances in later chapters; leave it out for characters who died before the story begins. Posthumous appearances in flashbacks, memories, or recordings belong in chapter/scene `mentions`, not `characters`.

## Appearance

Physical description: build, height, distinguishing features, typical clothing, how they carry themselves.

## Personality & Traits

Core personality traits, temperament, habits, quirks. What makes them memorable in a scene.

## Backstory

Key events that shaped who they are. Only include what's relevant to the story.

## Motivations & Goals

What drives them. What they want (external goal) and what they need (internal goal). How these conflict.

## Location References

Important places tied to this character. Keep this list in sync with `notable-characters` in location files.

## Voice & Speech Patterns

How they talk: vocabulary level, sentence length, verbal tics, dialect, tone. Include 2-3 example lines of dialogue that capture their voice.

Example:
> "I didn't come here to make friends. I came here because someone has to clean up this mess."

## Character Arc

- **Starting state:** Where they begin emotionally/psychologically
- **Key turning points:** What changes them
- **Ending state:** Where they end up (or projected end)

Arc-type guidance (set `arc-type` in frontmatter; the lie/truth framing follows the widely taught Weiland school of character arcs):

- **Change-positive:** The classic arc. The character moves from lie to truth — each turning point cracks the lie a little more until the climax forces the choice between the old belief and the new one. The `ghost-wound` is the past event that made the lie feel true; reference it whenever the lie resurfaces.
- **Change-negative:** The tragic arc. The character clings to the lie and doubles down at each turning point. Track the spiral: each refusal of the truth costs more than the last, until the lie wins and the ending is worse than the beginning.
- **Flat (steadfast):** The character already holds the truth and does not need to change. Do not give them growth beats — write tests-of-steadfastness instead: moments where holding the truth costs them something, and they hold it anyway. Their arc is measured by how they change the world around them, not by how they change.

## Antagonist Design

An antagonist file uses this same template — set `role: antagonist` and give them the same depth as the protagonist. A worthy opponent:

- **Believes they are right.** The antagonist acts from their own logic, values, and wound — not from a desire to be evil. If you cannot write their case for them, they are a cardboard villain.
- **Is stronger in some dimension.** Resources, skill, knowledge, position, conviction — the protagonist must grow or outthink them to win. An opponent weaker than the hero generates no tension.
- **Argues the counter-premise.** The antagonist embodies the story's opposing value (see the `premise:` / `counter-premise:` fields in `story.md`). Their arc is the dark mirror of the protagonist's.
- **Could carry the story.** Draft their plan as if they were the protagonist of their own plot: goal, plan, escalations, what the protagonist's interference costs them. If their opposition collapses without the hero's involvement, it is passive — rewrite it.

When the true antagonist is a system, culture, or institution, personify it: give the force a face — a specific person who embodies and enforces it. The reader argues with a person, not an abstraction.

## Timeline

Key life events in chronological order:

| When | Event | Relevance |
|------|-------|-----------|
| | | |

# Ensemble Cast

Guidance for managing multiple significant characters — ensemble stories, large casts, multi-POV novels. Each member still gets a full character file; this reference covers how the cast works as a unit.

## Anchor Character

Designate one anchor character: the POV or emotional center the reader returns to. The anchor carries the main thematic question and gets the most page time. Without an anchor, ensembles drift — every scene feels like a reset. Record the anchor in the `characters/_index.md` notes and weigh scene count against it during revision.

## A/B/C Story Braiding

Give each major character their own story thread (A = main plot, B = secondary, C = tertiary). Braid them so chapters alternate threads and each thread's escalation lands at a different point — two threads peaking simultaneously dilutes both. Track each thread as its own arc in `plot/arcs/`.

## Per-Character Thematic Relevance

Every significant character must connect to the story's central value question. If a character can be removed without changing what the story argues, their role is not load-bearing — cut them, merge them, or rewrite their role so their arc takes a position in the debate.

## Merge-Characters Discipline

When two characters serve one function — same role in the plot, same relationship to the protagonist, same thematic position — merge them into one. A smaller cast of stronger characters beats a large cast of thin ones. Before merging, check: do both characters have distinct goals? If not, they are already the same character wearing two names. Move the useful traits to the survivor, update all cross-references, then run `story reindex .`, `story links .`, and `story validate .`.

# Relationship Types Reference

Use these types in character frontmatter `relationships[].type` field.

## Family

| Type | Description |
|------|-------------|
| parent | Parent of the other character |
| child | Child of the other character |
| sibling | Brother or sister |
| spouse | Married partner |
| partner | Unmarried romantic partner |
| grandparent | Grandparent of the other character |
| grandchild | Grandchild of the other character |
| uncle | Uncle of the other character |
| aunt | Aunt of the other character |
| nephew | Nephew of the other character |
| niece | Niece of the other character |
| cousin | Cousin |
| in-law | Related by marriage (specify in notes) |

## Social

| Type | Description |
|------|-------------|
| friend | Close friend |
| ally | Allied but not necessarily close |
| rival | Competitive relationship |
| enemy | Hostile opposition |
| adversary | Named personal opposition with direct stakes |
| mentor | Teacher/guide figure |
| student | Learner/protege |
| employer | Boss or authority figure |
| former-supervisor | Former boss or authority figure |
| subordinate | Works under the other character |
| colleague | Works alongside |

## Story Role

| Type | Description |
|------|-------------|
| protagonist | Main character in opposition or partnership |
| antagonist | Primary opposition to this character |
| love-interest | Romantic interest |
| foil | Character who contrasts/highlights traits |
| confidant | Character they confide in |

## Usage

The type set is open and extensible: the CLI does not enum-check `relationships[].type`, so any kebab-case value passes `story validate`. Prefer a type from this reference when one fits; when none does, coin a descriptive kebab-case type (e.g. `former-supervisor`) and use it consistently on both sides.

Relationships are bidirectional. When adding a relationship to one character, add the inverse to the other:

- If A has `type: parent` to B, then B has `type: child` to A
- If A has `type: mentor` to B, then B has `type: student` to A
- If A has `type: rival` to B, then B has `type: rival` to A (symmetric)

Inverse pairs:
- parent <-> child
- grandparent <-> grandchild
- uncle/aunt <-> nephew/niece
- mentor <-> student
- employer <-> subordinate

Symmetric types (same both ways):
- sibling, spouse, partner, friend, ally, rival, enemy, adversary, cousin, colleague, foil, confidant, love-interest, former-supervisor

# Supporting Characters

Brief guidance for roles smaller than deuteragonist. Major supporting characters still get full files from `references/character-template.md`; minor ones can be a paragraph in the `characters/_index.md` notes.

## Role Vocabulary

- **Mentor** — teaches or equips the protagonist, then gets out of the way (often dies or withdraws so the hero must stand alone)
- **Foil** — contrasts with the protagonist to highlight their traits and choices
- **Confidant** — someone the protagonist talks to honestly; reveals interiority
- **Love interest** — romantic stake in the protagonist's outcome; must want something independent of the romance
- **Comic relief** — releases tension; must have their own dignity, not just be a joke
- **Threshold guardian** — tests the protagonist's readiness before a new stage; the test teaches something the next act requires

## Every Supporting Character Needs

- **Their own goal.** A want independent of the protagonist's plot — not just "help the hero." A goal that conflicts with the protagonist's, even slightly, makes them feel alive.
- **2–3 defining traits.** One vivid, specific trait beats five vague ones. Make each trait visible in a single scene when the character first appears.
- **An exit.** Supporting characters should leave the story when their function is done. Lingering extras dilute tension.