compose-war-story

name

compose-war-story

description

Composes a narrative "war story" history of how a line of work, a project, or a research direction evolved — what was tried, what was believed, what broke that belief, what changed, and where it's heading. Produces a mental-model document a newcomer (or future-self) can absorb. Use when the user asks for "the history of how X evolved", "a war story", "how did we get here", "the backstory/trajectory of this work", or wants the reasoning arc behind a series of decisions. Verifies factual and chronological claims against sources (NotebookLM if available) to avoid timing/inspiration contradictions, and ends with a CLI review gate.

Compose War Story

Produce a narrative history that gives the reader a mental model of how a body of work evolved — not a changelog, not a summary, but the reasoning trajectory: what was tried, what we believed, what evidence broke that belief, what we changed, and where we're going. The voice is a candid retrospective ("we started with X, thought Y, found Z, so we changed to W...").

This skill is for understanding the journey. For a point-in-time KB note use kb-update/kb-from-conversation; for a literature survey use literature-survey.

When to use

Triggers: "give me the history of how this evolved", "war story", "how did we get here", "the trajectory/backstory of this work", "help me understand the context of this line of work", or a request for the reasoning arc behind a sequence of decisions.

Operating principles

• Narrative, not bullets. Tell it as a story with cause and effect. Each act should answer: what did we believe → what did we do → what did we learn → what did that change.
• Surface the turning points. The valuable part is where beliefs flipped and why (a failed experiment, an adversarial review, a reframe). Make those the spine.
• General chronological order, but don't be a slave to it. Group by idea/theme when that's clearer; you may flash back/forward. But never state a timing- or inspiration-contradiction (e.g. "the 2018 work was inspired by the 2024 method"). Every inspiration/"builds-on" arrow must point backward in time.
• Verify before you assert. Factual claims — dates, who-did-what, who-inspired-whom, who-extends-whom — must be checked against sources, not recalled. Flag corrections inline so the reader trusts the timeline.
• Honest about uncertainty. Distinguish what's established from what's inferred. Carry forward the load-bearing caveats.

Steps

1. Scope the story. Identify the line of work and gather the raw material: project log.md/README.md, prior artifacts in the working folder, relevant survey/notebook outputs, and the conversation history. Determine whether the story is about the project's own decisions, the field's evolution, or (often best) both interleaved.

2. Extract the beats. Build an ordered list of turning points: initial framing → each major decision → what challenged it → the resulting change. Note the belief held at each step and the evidence that moved it. A good war story usually has 5–9 "acts."

3. Verify factual & chronological claims (mandatory).

   • If a NotebookLM notebook covers the domain, query it to confirm/correct: publication years, authorship, and explicit citation/inspiration/"extends" relationships. Ask it directly to flag any claim that implies a later work inspired an earlier one.
   • Otherwise verify against the source files (e.g. read-papers/*.md, registries) or web search.
   • Apply every correction the verification returns before writing the narrative. If a claim can't be verified, soften it or drop it — don't assert it.

4. Compose the war story to a markdown file in the session/working folder (default war-story.md). Recommended shape:

   • A one-line sourcing note stating what was verified and how (so the timeline is trustworthy); flag corrected claims inline (e.g. with ★).
   • Act 0 — the problem and the framing that shaped everything after.
   • Middle acts — each a believe→do→learn→change beat; make turning points vivid.
   • Closing — "the arc in one sentence," the current direction/standing plan, and the load-bearing caveats carried forward.

5. Run the review gate (mandatory). Invoke /cli-review on the composed file. Route to Codex when the story is about an implementation/engineering trajectory, Gemini for a broad conceptual/literature narrative; when in doubt or mixed, you may run both. Ask the reviewer specifically to check for: (a) chronological/inspiration contradictions, (b) unsupported factual claims, (c) whether the reasoning arc is coherent and the turning points are the real ones.

6. Incorporate review feedback, then tell the user where the file is and give a 2–3 sentence summary of the arc. Append a line to the project if one exists.

Anti-patterns

• A flat summary of the final state with no sense of how or why it changed.
• A pure changelog ("did X, then Y, then Z") with no beliefs, evidence, or turning points.
• Asserting dates/authorship/inspiration from memory without verification.
• Any sentence where an earlier work is said to draw on a later one.
• Skipping the /cli-review gate.