necmttn/ax/narrate

Claude Code and agent skill by necmttn/ax

Trust tier 3
  • community
Source check pending

Checking that the SKILL.md file is still in the repository.

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.

Install

npx vskill@latest install necmttn/ax/narrate

SKILL.md

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.

  1. 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.

  1. 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:

kindrequired fieldsuse for
file_hunkfile, old_text, new_text, label, opt turn_seqa real code change
code_stateartifact, label, lang, code, opt turn_seqthe evolving architecture snapshot
turnturn_seq, labela plain moment in the transcript
user_directionturn_seq, quoteuser steering (not correcting)
correctionturn_seq, quote, outcomeuser correcting course
tool_failureturn_seq, tool, error_excerpt, recoveryconsequential failure
termname, definitiona 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:

json
{
"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.

Security

  • Security scanPassed, 90 of 100Pattern checks on the skill's files.
  • Model reviewPassed

Quality evaluation

  • Task evaluationNot runNo evaluation yet. Run one in Skill Studio.

Source

Popularity

7-day trend score
0

Not refreshed yet.

Works with

Any agent vskill installs to: 56 targets in all. These 39 have a page on this site.

  • Claude Code
  • Cursor
  • GitHub Copilot
  • Windsurf
  • Codex
  • Gemini CLI
  • Cline
  • Amp
  • Roo Code
  • Goose
  • Continue
  • Kilo Code
  • Junie
  • Trae
  • OpenHands
  • Qwen Code
  • AI Agent
  • Tabnine Chat
  • Sourcegraph Cody
  • Amazon Q
  • Firebase Genkit
  • Sweep
  • Devin
  • Phind
  • Mentat
  • Claude Desktop
  • Aider
  • GPT Pilot
  • Plandex
  • bolt.new
  • v0
  • Replit Agent
  • Anse
  • TypingMind
  • BetterChatGPT
  • LibreChat
  • Warp AI
  • Pieces
  • Fig AI
Embed badge
vskill VERIFIED badge
[![vskill VERIFIED](https://verified-skill.com/api/v1/skills/necmttn/ax/narrate/badge)](https://verified-skill.com/skills/necmttn/ax/narrate)

Something wrong with this skill or its page? Tell us.