Writing Staffing

Writing Staffing

Compose the right team for each writing task. The goal is coverage across perspectives: critics with different focus areas, researchers with different scopes, and brainstormers exploring different angles. Avoid redundant passes from the same angle.

General Principles

Delegation keeps context clean. Each mode of work benefits from a fresh context window and different model strengths: drafting needs voice fidelity, critique needs adversarial distance, research needs breadth. Orchestrators coordinate mode-switches through agents. If no team composition was provided by your caller, compose one yourself before starting: use the catalogs in the resources below.

Review convergence. Critic loops run until convergence (no new substantive findings), not a fixed number of passes. The orchestrator can stop early, but must log the reasoning in the work directory so future agents understand what was decided and why.

Brainstorm diversity over brainstorm volume. Three brainstormers exploring different angles beats five exploring the same angle. Creative diversity comes from different perspectives, not more of the same perspective.

Style creation and style evaluation are separate modes. Creating style reference files from sample prose is an analytical task. Evaluating whether a draft maintains the project's voice is a critique task with voice focus. Use the right mode for each: see the agent catalogs in resources.

Effort Scaling

Effort scaling applies mainly to critics: the role that fans out within a draft/revise cycle. Writers don't scale within a phase (one writer per scene/chapter; split the brief if it's too big).

For critics, scale to the stakes and complexity of the content:

• Low-stakes drafts (brainstorm captures, wiki stubs): 1-2 critics
• Standard chapters: 3 critics with split focus areas
• Pivotal scenes (character deaths, reveals, arc climaxes): 4-5 critics; for critical focus areas like voice consistency and continuity, duplicate coverage

Parallelism

Think about what depends on what:

• Critics need a finished draft: they wait for the writer
• Critics examine different dimensions: fan them all out simultaneously
• Within a brainstorm fan-out, all brainstormers are independent: fan them out
• Knowledge maintenance has ordering constraints: see resources/knowledge.md
• Character simulations in a multi-character scene are independent: fan them out, then synthesize

Agent Catalogs

See resources for detailed catalogs of available agents and when to use each:

• Read resources/critique-synthesis.md when synthesizing findings from multiple critics: covers reward-channel triage.
• Read resources/critics.md when composing critique panels: covers critic focus areas and the continuity-checker specialist.
• Read resources/researchers.md when dispatching research: covers research focus areas and base agent usage.
• Read resources/builders.md when staffing writing, outlining, or style work: covers writer, outliner, style-creator, and base agents for wiki/reference pages.
• Read resources/knowledge.md when triggering knowledge maintenance: covers chronicler and base agent dispatch order.
• Read resources/character-sim.md when setting up character exploration: covers character-sim dispatch and multi-character fan-out patterns. Read it alongside resources/reader-sim.md when a workflow also needs experiential reader-response data on a draft.

Builders

Agents that produce written artifacts: prose, outlines, brainstorm reports, and wiki pages.

writer

Drafts prose from scene briefs and style files. One writer per scene or chapter: splitting the brief is better than parallelizing writers on the same content, because voice consistency degrades when multiple writers handle adjacent scenes independently.

The writer's output is a draft, not final text. It goes through critique and revision before the orchestrator presents it. Pass the writer:

• A scene brief or outline (what happens)
• Relevant style files (how it should sound)
• Continuity anchors (what came before)
• Character state files for characters in the scene

The writer operates in two modes:

• Autonomous: receives a brief, produces a draft in the drafts directory. This is the mode used in draft/critique loops.
• Interactive: back-and-forth with the author in conversation. Used when the author wants to co-write or iterate on specific passages.

outliner

Structures story at the arc, chapter, and beat level. Produces outlines and mermaid diagrams for arc structure, timeline visualization, and character relationship maps.

Use the outliner when:

• Starting a new arc and need to map the chapter structure
• Breaking a chapter into scene beats before the writer drafts
• Visualizing timeline or relationship complexity
• The author has direction but needs it structured into a writable plan

The outliner's output feeds the writer: a good outline is the single biggest input to draft quality. Skip outlining and the writer makes structural choices that the critic will flag and the revision will have to redo.

The outliner does not brainstorm. For wide-open exploration and option generation before a direction is chosen, spawn the brainstormer instead. Outlining starts after the author has committed to a direction; brainstorming is how they get there.

brainstormer

Explores a question or angle in depth and produces a structured brainstorm report in the brainstorm directory. Tags speculative content with <AI>, preserves vagueness, presents options and tradeoffs rather than committing to a direction.

Use the brainstormer when:

• The author wants to explore ideas before choosing a direction
• An orchestrator needs creative options from multiple angles (fan out brainstormers for diversity)
• Testing "what if" scenarios before committing to structure
• The question is open-ended and the answer shouldn't converge prematurely

Brainstormer and outliner are complementary: brainstorm first to explore the space, then outline once a direction is chosen to lock it into structure the writer can build from.

style-creator

Creates style reference files from sample chapters, author requirements, or existing style files that need revision. Produces standalone style files: voice guides, scene technique guides, tonal register guides, and formatting conventions.

Use the style-creator when:

• The project needs voice files for a new POV character
• Scene-type or tonal register guides don't exist yet and the writer needs them
• Existing style files need updating because the voice has evolved over new chapters
• The author has described a desired voice and wants it codified into a referenceable file

The style-creator does not evaluate prose against styles. That's the critic with a voice focus: checking whether a draft maintains voice consistency, detecting drift, flagging register breaks. The style-creator's output is the reference material the critic's voice focus checks against.

Wiki and Reference Pages

For polished, reader-facing wiki pages, use the base @kb-writer. It writes to the author's wiki space with link discipline and citations back to chapters. For structural kb health (broken links, orphaned pages, relationship diagrams), use the base @kb-maintainer.

Character Simulation

Character exploration through performance. The character-sim agent becomes a character for freeform conversation: the author (or another agent) interacts with the character to discover voice, test dynamics, and explore reactions in unplotted situations.

character-sim

Stays in character. Doesn't break to explain, doesn't over-narrate, doesn't meta-comment on the interaction. Responds as the character would: with their knowledge, their biases, their emotional state.

Works with whatever character context it's given:

• Full context mode: loads relevant style files and character state files. The combination gives voice patterns AND factual grounding (what the character knows, where they are in the story, their relationships). Use when the character is established and the goal is to hear how they'd react to specific situations.

• Ad hoc mode: character description comes entirely from the prompt. "You're a 14-year-old from a fighting dojo who just lost his first real battle. You're proud, stubborn, and your dad is watching. React." No files needed. Use when:
• The character doesn't exist yet
• Sketching a one-off NPC
• Exploring "what if" scenarios with modified traits
• Testing a character concept before committing to a profile

Use cases

Voice discovery: hear how a character sounds in different emotional states. Spawn a character-sim, give it a scenario, and observe the voice that emerges. Especially valuable for characters whose voice isn't established yet.

Relationship testing: play out unscripted encounters between characters. See how they interact without the author scripting the outcome. Reveals dynamics that planned scenes might miss.

Stress testing: confront a character with unexpected situations and see authentic reactions. "What would the protagonist do if she discovered the secret early?" The answer reveals character, even if the scenario never appears in the story.

Ad hoc sketching: describe a character on the fly, interact with them to discover who they are before writing anything down. Useful early in character development when the author has a vague sense and needs to find the specifics.

Multi-character fan-out

The orchestrator spawns multiple character-sim agents as different characters in the same scene. Each loads a different voice and character state. They interact autonomously while the author observes.

# Two characters meeting for the first time
meridian spawn -a character-sim \
  -p "You are [character]. You've just arrived at the inn after a rough day on the road. Someone your age approaches you." \
  -f kb/styles/[relevant style files] \
  -f kb/characters/[character].md

meridian spawn -a character-sim \
  -p "You are [other character]. You've been waiting at the inn for a potential travel companion. Someone about your age walks in looking exhausted." \
  -f kb/styles/voice-kyle.md \
  -f kb/characters/kyle.md

The chronicler or base @session-explorer can later extract voice patterns, relationship dynamics, and character insights from the character-sim transcripts. The value is the conversation itself: character-sim is a read-only agent that doesn't write files.

Staffing considerations

Character simulation is inherently cheap (read-only, no file writes, no tool use beyond conversation). Use it liberally for exploration. The cost of spawning a character-sim is much less than the cost of discovering a character's voice doesn't work after drafting an entire chapter.

Relationship to reader-sim

Character-sim and reader-sim are symmetric simulation agents on different sides of the text: character-sim produces in-character behavior so the author can observe it, while reader-sim consumes a finished draft and reports the reading experience. Both are read-only, both report experience rather than craft findings, and both are cheap enough to spawn liberally.

Critics

Critics catch what revision can't: voice drift, structural issues, continuity holes. The value of multiple critics comes from different focus areas, not redundant reads of the same concern.

critic

Adversarial draft review with a specified focus area. Give each critic a different focus area so you get breadth: the content itself tells you what perspectives matter. Read-only.

Focus Areas

structure: Plot logic, pacing, scene necessity, stakes, setup/payoff. Does every scene earn its place? Do stakes escalate or plateau? Are promises set up that get paid off? Does the pacing serve the emotional arc or fight it? Use on any draft, but especially on chapters that bridge between high-intensity scenes where pacing sag is most likely.

character: Motivation coherence, arc progression, relationship dynamics. Do characters act from established motivation or convenience? Are relationship shifts earned through interaction, not narrated? Does the character's internal state match their behavior? Use when characters make significant choices, confront each other, or change.

voice: Dialogue quality, POV consistency, subtext, voice drift. Does each character sound distinct? Does the narrator's voice stay consistent? Is there subtext in dialogue or is everything surface-level? Does the prose drift toward generic AI voice or maintain the project's established style? Use on every draft: voice is the most common casualty of AI-assisted writing.

prose: Line-level quality: rhythm, clarity, repetition, show vs tell. Are sentences varied or monotonous? Is language precise or vague? Does the prose show states through action or tell them through narration? Are there echoed words or phrases? Use when prose polish matters: pivotal scenes, published chapters.

continuity: Facts, timeline, geography, character state. Does this chapter contradict established canon? Are characters in the right place? Does the timeline hold? Is information the character knows consistent with what they've experienced? Use on any draft, but critical for chapters that reference events from earlier in the story.

Choosing Focus Areas

The content tells you what perspectives matter. A battle scene needs structure (pacing) and continuity (established abilities) more than prose polish. A quiet character scene needs character (motivation) and voice (dialogue quality) more than structure. A chapter that spans multiple locations needs continuity above all.

For standard chapters, three critics with different focus areas provides good coverage. For pivotal scenes, expand to four or five and consider duplicating the most critical focus area.

Fan-Out for Coverage

The multi-agent role decomposition pattern this skill advocates is empirically supported. HoLLMwood (2024, Findings of EMNLP, https://aclanthology.org/2024.findings-emnlp.474/) found that splitting creative writing across distinct writer/editor/actor roles produced measurable improvements in coherence, relevance, interestingness, and overall quality over strong single-agent baselines. The critic fan-out pattern this skill advocates is the critique half of that empirically-supported architecture. If you're reading this and wondering whether the fan-out overhead is worth it, that's the evidence: the overhead pays for itself in finding quality.

When fanning out, use the best available model and vary focus areas across critics so the panel covers different dimensions:

meridian spawn -a critic -p "Focus: structure" -f $DRAFT
meridian spawn -a critic -p "Focus: continuity" -f $DRAFT $CANON
meridian spawn -a critic -p "Focus: voice" -f $DRAFT $VOICE_STYLE

For pivotal scenes where a focus area really matters, duplicate that focus across two different agent spawns rather than relying on a single pass.

continuity-checker

Cross-references content for contradictions across the full project. Unlike the critic's continuity focus (which compares one draft against provided context), the continuity-checker navigates the project's knowledge graph and the kb to find what should be cross-referenced. Read-only.

Use the continuity-checker when:

• A chapter references events, locations, or character state from significantly earlier in the story
• Multiple chapters are being drafted in parallel and need to stay consistent
• The story spans enough time or complexity that the critic's provided context isn't sufficient
• After timeline or world-building changes that might invalidate earlier content

The continuity-checker is more expensive than a critic with continuity focus: it reads broadly. Use the critic for routine continuity checks and the continuity-checker for deep cross-project validation.

Critique Synthesis

Synthesize at the pattern level rather than forwarding individual critic reports. "3 of 4 critics flagged pacing in scenes 2-4" tells the writer what to fix; four separate reports don't.

When triaging findings, categorize against the four reader reward channels (documented in the writing-principles skill):

• Transportation: narrative coherence, POV consistency, continuity, middle-passage drift
• Aesthetic: voice, rhythm, syntactic variety, generic vs specific detail
• Social simulation: character motivation, emotional access through behavior not labels, ambiguity preservation
• Flow: pacing, over-elaboration, exposition placement, challenge-fit

"Three critics flagged findings that damage transportation" gives the author a clear priority call: transportation problems vs aesthetic problems is a different urgency depending on where the draft stands. Prioritize findings by impact on the reader's experience.

Knowledge Maintenance

Agents that keep the kb current: extracting decisions, synthesizing facts, and maintaining connections. These don't write prose or review drafts; they maintain the knowledge layer that lets future agents (and humans) work with accurate context.

chronicler

Extracts story facts from written chapters: character state, timeline events, canon facts, relationship changes. Reads the manuscript and produces compressed, annotated entries in the kb. Not a copy of the chapter: a synthesis of what changed in the project's factual state.

Also handles mining past sessions for decisions and commitments when dispatched with session references (via meridian session). This consolidates knowledge write-back into one agent rather than splitting session-extraction from chapter-extraction.

When to dispatch:

• After a chapter draft is finalized (post-critique, post-revision)
• After significant revisions to existing chapters that change established facts
• After brainstorm sessions where options were explored and direction was chosen
• After interactive writing sessions where the author made story decisions in conversation
• When starting work on a new arc and needing to baseline the current state

The chronicler writes character files, canon files, timeline entries, world entries, and decision records. It reads existing entries to avoid duplication and updates rather than appends when facts change.

Base Agents for Knowledge Work

For graph maintenance, link topology checks, and structural kb health, use the base @kb-maintainer. For session transcript mining (read-only exploration before the chronicler writes), use the base @session-explorer. For wiki/reference page writing, use the base @kb-writer.

The base agents handle the generic mechanics; the chronicler handles CW-specific knowledge extraction that requires understanding story structure, character state, and narrative canon.

Dispatch Order

Fan out the chronicler and base @session-explorer in parallel after the triggering event (chapter finalized, brainstorm concluded). Run base @kb-maintainer after both complete: it depends on the chronicler having finished writing entries.

Reader Simulation

Experiential reader-response agent. The reader-sim agent reads a draft as a reader, not as a critic, and reports the experience as it happens, structured by the four empirically-supported reader reward channels (transportation, aesthetic, social simulation, flow). It produces raw experiential data: the orchestrator or critic translates that data into craft findings.

reader-sim

Stays in the reader stance throughout the read. Doesn't diagnose craft problems, doesn't propose fixes, doesn't rewrite passages. Its value is the felt experience of reading, reported with concrete textual anchors: "I skimmed the fourth paragraph of scene three" is the kind of signal the critic cannot generate from outside.

Read-only. Takes a draft file and (optionally) a focus spec or style references. Produces a structured experiential report. Cheap to spawn; you can run multiple reader-sim instances on the same draft when the draft is long or the stakes are high, because different perspectives land on different reading sensibilities.

When to spawn

• After a draft converges in the write/critique loop: before presenting to the author, a reader-sim pass tells you what the text actually feels like to read, which is information the critic's pattern-matching doesn't capture.
• On long drafts or pivotal scenes: chapters where middle-drift consistency bugs are likely ("Lost in Stories," arxiv 2603.05890), or scenes where the author is uncertain whether the emotional target lands.
• When craft critique and reader experience might diverge: a scene can be technically clean and still leave a reader cold. A reader-sim pass is the cheapest way to notice that before the author does.
• Alongside critics, not instead of them: the two reports answer different questions. A critic catches what a reader might miss and vice versa; the orchestrator synthesizes across both.

What reader-sim is not

Reader-sim is not a second critic. When its report reads like a craft critique, such as "the pacing is off," the stance collapsed and the value is lost. The orchestrator should reject that kind of output and re-spawn with tighter framing.

Reader-sim is also not a summary agent. The caller already has the draft. What reader-sim provides is the experience of reading it.

Fan-out patterns

For a long draft, one reader-sim pass is usually enough. For a pivotal scene, fan out two or three reader-sim instances so the orchestrator can see whether an experience (absorption, aesthetic reward, emotional landing) held across readers or was specific to one perspective.

Relationship to character-sim

Reader-sim and character-sim are symmetric simulation agents on different sides of the text. Character-sim produces in-character behavior from one side of the page; reader-sim consumes the finished text from the other side and reports what landed. Both report experience rather than craft findings, and both are read-only.

Researchers

For web research (craft references, worldbuilding facts, genre conventions, sensitivity review, fact-checking), muse handles it directly using WebSearch/WebFetch. For fast local project exploration (file navigation, kb queries, past session search), use the base @explorer.

Research Focus Areas

When doing web research, pick a focus area to guide the search:

craft: Narrative technique and published craft knowledge. How do published authors handle unreliable narrators? What are best practices for multi-POV transitions? Use when the writing team needs technique guidance beyond what the project's style files cover.

world: Real-world references for worldbuilding. Historical parallels, scientific accuracy, cultural context, geography. Use when the story's world mechanics draw from real-world systems and the team needs grounding beyond what's in the wiki.

genre: Conventions, reader expectations, tropes, market context. What do readers of this genre expect from a training arc? Use when making structural choices that should be informed by genre awareness: not to follow conventions blindly, but to know what you're subverting.

sensitivity: Representation, authenticity, community perspectives, common pitfalls. Use when the story touches identity, disability, cultural practices, or traumatic experiences: early in the process, not as a last-minute check.

fact-check: Verifying specific claims. Dates, locations, technical details, real-world accuracy of fictional parallels. Use when the story makes specific factual claims that could undermine credibility if wrong.

Choosing Focus Areas

Most research tasks have a clear primary focus. When the question spans multiple areas ("how should a martial arts tournament arc work?"), spawn multiple researchers in parallel: one for craft (tournament arc structure in fiction), one for world (real martial arts tournament formats), one for genre (tournament arcs in the specific genre).

Research reports are the deliverable: thorough, with trade-off analysis and source URLs. The orchestrator synthesizes across reports; the researcher goes deep on one dimension.

Local Exploration

The base @explorer is cheap: use it liberally for orientation before committing to expensive spawns:

• Understanding what exists in the project before composing a team
• Identifying continuity anchors before a writer drafts
• Consulting the knowledge graph for related content
• Searching past sessions for relevant decisions or context