ax-narrate

name	ax-narrate
description	Write the agent-generated narration of the current session - the reviewable story of what changed, including what never reaches a PR (user corrections, abandoned attempts, tool failures). Triggers on "narrate this session", "summarize what changed", "write the session story", "narrate what we did", "session narration". Output is .ax/narrations/<session-id>.json for the ax studio narration view. Do NOT fire on "summarize this file" or generic recap questions answered inline - this skill writes a structured artifact.
role	verification

ax:narrate - write the session's story as a structured narration

You were there. This skill turns YOUR OWN memory of the session into a reviewable artifact: 3-7 stops in reading-flow order, each anchored to real evidence - code hunks, turn numbers, user quotes, failures. The point is to capture what a PR diff never shows: the corrections, the dead ends, the recoveries.

The artifact validates against SessionNarration in apps/studio/src/routes/narration-types.ts and renders in ax studio.

Step 1 - identify the session

• Preferred: ax sessions here --days=1 --json and pick the current session's id (the one matching this conversation). Use the short id.
• If ax is unavailable or the session isn't ingested yet, derive a slug: <repo>-<YYYYMMDD-HHmm>. Note in meta that turn seqs are best-effort ordinals in that case.
• If available, ax sessions show <id> --json gives you the real turn seqs to anchor against. Prefer real seqs over guesses.

Step 2 - reconstruct the story from your own context

Re-read the conversation in your head before writing anything:

1. What did the user originally ask for? (intent)
2. What existed before, what exists now? (before/after)
3. Where did the user redirect or correct you? EVERY one of these becomes a correction anchor. No exceptions.
4. Which tool failures actually mattered (changed your approach, cost real time, forced a workaround)? Each becomes a tool_failure anchor. Skip trivial retries that changed nothing.
5. Which attempts were abandoned? They get a stop or at least a turn anchor - abandonment is part of the story.

Step 3 - choose 3-7 stops, in reading-flow order

A stop is a LOGICAL unit of change, not a file. If three files changed for one reason, that is ONE stop with several anchors. Order rules (stolen from the code-tour playbook because they work):

• Entry point first: the change that, understood alone, unlocks the rest.
• Cause before effect: the correction comes before the code it caused.
• Definitions before consumers: types/schema stops before usage stops.
• Verification last: tests, typecheck, and the failures hit on the way.
• Combine trivial housekeeping into one final stop, or omit it.

Step 4 - write each stop

• title: short and friendly. "Call counts become a char diffstat", not "Changes to files-touched.ts".
• gist: ONE sentence. Not two. A reader who reads nothing else must get the stop from the gist. Conversational, the way you'd say it to a colleague.
• detail: 2-4 sentences of markdown (paragraphs, inline code, bold). Say WHY the change looks the way it does; "we did X instead of Y because Z" is exactly what the reader wants.
• transition: a short connective phrase to the next stop; empty string "" for the last stop.
• anchors: MUST be non-empty. An unanchored stop is an unsupported claim. Anchor kinds:

kind	required fields	use for
file_hunk	file, old_text, new_text, label, opt turn_seq	a real code change
code_state	artifact, label, lang, code, opt turn_seq	the evolving architecture snapshot
turn	turn_seq, label	a plain moment in the transcript
user_direction	turn_seq, quote	user steering (not correcting)
correction	turn_seq, quote, outcome	user correcting course
tool_failure	turn_seq, tool, error_excerpt, recovery	consequential failure
term	name, definition	a domain term the story leans on

Hard anchor rules

• file_hunk carries VERBATIM old/new fragments from the actual edits you made - copy the real text, never paraphrase code. Keep hunks short (5-15 lines per side); pick the most telling fragment, not the whole edit. old_text: null for pure insertions, new_text: null for pure deletions. Never both null.
• Every user correction/redirect in the session gets a correction anchor with a verbatim (trimmed) quote and a concrete outcome - what actually changed because of it.
• Every consequential tool failure gets a tool_failure anchor with a real error_excerpt and how you recovered (or "abandoned").
• Never fabricate turn seqs. Use ax sessions show seqs when you have them; otherwise count user turns from the start of the conversation and say so in the detail.
• code_state is the architecture spine of the narration: pick ONE stable artifact id (e.g. "review-architecture") and restate the FULL snapshot at each stop where the design moved - pseudo-code of types/interfaces, how they compose, and the call stack (plan-style: Caller -> Callee // note). Consecutive snapshots of the same artifact animate token-by-token in studio, so KEEP shared lines byte-identical between stops and let only the real delta differ - a new method, a renamed shape, an added edge case. Use code_state for the evolving design; use file_hunk for one-off code jumps (those render as static before/after diffs, not motion).

Step 5 - emit the artifact

Write .ax/narrations/<session-id>.json (create the directory if needed) with exactly this top-level shape:

{
  "schema_version": 1,
  "kind": "narration",
  "meta": {
    "session_id": "<id>",
    "generated_at": "<ISO-8601 now>",
    "generator": "skill",
    "model": "<your model id>"
  },
  "title": "...",
  "intent": "...",
  "before": "...",
  "after": "...",
  "stops": [ { "title": "...", "gist": "...", "detail": "...", "transition": "...", "anchors": [ ... ] } ]
}

Before finishing, self-check against the validator's rules:

• stops non-empty (3-7), every stop's anchors non-empty.
• Every gist is one sentence; every correction has an outcome; every tool_failure has a recovery; no file_hunk with both sides null or empty.
• Strings are plain JSON strings (escape newlines in hunks as \n).

Then tell the user where the file landed and give a 2-line summary of the story you wrote. Do not paste the whole JSON into chat.