/character-management

name: character-management
description: This skill should be used when the user asks to "create a character", "update a character", "add a character", "build a family tree", "character relationships", "character timeline", "character arc", "character profile", "relationship graph", "name a character", or needs to manage characters in a story project. NOT for recording or checking character voices (use voice-style), rewriting dialogue so the voices differ (use line-editing), or a thematic arc's lie, truth, and arc type (use theme-craft).

Character Management

Overview

Create and manage rich character profiles for a story project. Each character is a markdown file with YAML frontmatter in the `characters/` directory. Characters are cross-referenced with other story elements through kebab-case identifiers.

Prerequisites

A story project must already exist (created via the story-init skill). Verify by checking for `story.md` in the project root.

Creating a Character

1. Read `story.md` for genre, themes, and tone context 2. Read `characters/_index.md` for existing characters 3. Ask for the character's name and role (protagonist, antagonist, supporting, minor, narrator, deuteragonist). Before settling the name, run `story names '{Name}'` (several candidates can be checked at once): it errors on an exact clash with any existing character, alias, location, faction, artifact, system, or glossary term, and warns about look-alikes and names sharing an initial with a major character. Invented names from a culture should follow its naming rules (see `references/naming-languages.md` in the `worldbuilding` skill) 4. Build the profile through conversation, exploring:

• Appearance and distinguishing features
• Personality, traits, and quirks
• Backstory and formative events
• Motivations (external wants vs internal needs)
• Voice and speech patterns (ask for example dialogue), plus `voice-words` (words and phrases they reach for) and `voice-avoid` (words they would never say)
• Pronunciation, when the name is invented or easily misread (`pronunciation: "SEER-sha"`)
• Character arc (starting state, turning points, ending state)
• Key life events for the timeline

5. Write the character file using the template in `references/character-template.md` 6. Save to `characters/{name-kebab}.md`, or use `story add character '{Name}' --role '{role}'` when the CLI is available. Cyrillic and Greek names are transliterated (`Пётр` gives `characters/petr.md`). When the name is in a script with no transliteration table (`李明`), or the user wants a different spelling, choose the ASCII id yourself and pass it: `story add character '李明' --id li-ming --role supporting` keeps `name: 李明` in the file 7. Leave the `characters/_index.md` table to the CLI: `story add` and `story reindex .` rebuild it from the character files, so never add a row by hand 8. If relationships reference existing characters, update those character files too 9. When CLI access is available, run the maintenance pass in the story root:

story reindex .
story wordcount . --write
story check .

Updating a Character

1. Read the existing character file 2. Read `characters/_index.md` for context on other characters 3. Make the requested changes. If the change happens partway through the story (a scar, a new title, a turn to the other side), add a progression instead of editing the opening value (see Changes Over the Story) 4. If relationships changed, update the other character's file (bidirectional) 5. Change a role or status in the character file only. The `characters/_index.md` table picks it up at the next `story reindex .`, so never edit its rows 6. When CLI access is available, run `story reindex .`, `story wordcount . --write`, and `story check .`

Changes Over the Story

A character file describes the character as the story opens. Record a change that happens in a later chapter as a progression, so an agent drafting an earlier chapter does not write it in too soon:

progressions:
  - from: chapter-10
    field: scar
    value: "Jaw to collarbone, taken holding a door"
  - from: chapter-14
    field: role
    value: antagonist

• `from` is the first chapter where the new value holds. It may be a planned `chapter-NN` with no file yet
• `field` is kebab-case. It can be an existing single-value field (`status`, `role`, `arc`) or a new one (`scar`, `title`). List fields (`aliases`, `relationships`, `locations`, `tags`, voice lists) cannot change this way; record a shifted relationship as a progression on its own field, such as `field: standing-with-kael` with `value: estranged` under `progressions`, never as a top-level field (that would show from chapter 1)
• `value` is one value. `role` and `status` values must be ones the character file allows
• Keep entries in story order. Do not use a progression alone for a death: set `died-in` (see below). A `status` progression is still checked against the story: `story continuity` warns when a progression to `deceased` with no `died-in` is followed by the character in a cast or learning something, when a status progression brings them back between `died-in` and `revived-in`, and when a progression to `deceased` still holds at `revived-in`
• The body of the file is prose for the writer. Describe a change in story terms ("from Festival night she carries the scar"), and do not name `progressions` or other frontmatter fields there
• Before drafting or revising a chapter, run `story knowledge {id} --at chapter-NN`. It lists what the character knows at that chapter in story time (by date when both chapters are dated, otherwise by chapter number), the same rule as `story context`, and which progressions already apply. Write to that state rather than the opening frontmatter alone
• A line marked `reader-knowledge` is already on the page, or known before the book, and may appear in the prose. A line marked `character-knowledge` and `do not reveal`