# Compose War Story > 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. - Skill: `allyoushawn/compose-war-story` (Agent Skill) - Install (CLI): `npx skillmds@latest add allyoushawn/compose-war-story` - Raw SKILL.md: https://api.skillmd.com/api/skills/allyoushawn/compose-war-story/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - Author: allyoushawn (https://skillmd.com/u/allyoushawn) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/allyoushawn/compose-war-story --- # 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 `log.md` 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.