Nm Scribe Session To Post

> Night Market Skill — ported from claude-night-market/scribe. For the full experience with agents, hooks, and commands, install the Claude Code plugin.

Session to Post

Capture what happened in a Claude Code session and turn it into a blog post, case study, or social media thread that others can learn from.

The skill extracts the real story from git history, file changes, and conversation context — then shapes it into a narrative that shows process, not just results.

When To Use

When NOT To Use

Integration Points

This skill connects to several others in the ecosystem. Use them when the post needs more than prose.

| Need | Skill | What it adds | |------|-------|-------------| | Terminal demo GIF | scry:vhs-recording | Record a build/test run as an animated GIF | | Browser demo GIF | scry:browser-recording | Capture a web UI walkthrough via Playwright | | Composite media | scry:media-composition | Stitch terminal + browser GIFs side-by-side | | Proof of claims | imbue:proof-of-work | Verify every number in the post with evidence | | Code quality narrative | pensive:code-refinement | Describe what was cleaned up and why | | Review narrative | imbue:structured-review | Capture review findings as post content | | Change summary | imbue:catchup | Summarize what changed for the post's "The Work" section | | Diff analysis | imbue:diff-analysis | Risk-scored change breakdown for technical audiences |

Recording Integration (scry)

When the post describes something visual — a running app, a test suite, a build pipeline — capture it instead of describing it.

Terminal recordings (build output, test runs, CLI demos):

Invoke Skill(scry:vhs-recording) with a tape that runs:
  make test        → shows 180 tests passing
  make play        → shows the build + server startup

Browser recordings (web apps, rendered output):

Invoke Skill(scry:browser-recording) with a Playwright spec that:
  navigates to the app
  interacts with it
  captures the result

Composition (side-by-side before/after, terminal + browser):

Invoke Skill(scry:media-composition) to stitch recordings into
a single visual that tells the story.

Place generated GIFs in docs/posts/assets/ and reference them from the markdown with relative paths.

Proof-of-Work Integration (imbue)

Every claim in the post should be verifiable. Before finalizing:

Invoke Skill(imbue:proof-of-work) to:
  - Tag each claim with [E1], [E2], etc.
  - Run verification commands
  - Report PASS / FAIL / BLOCKED

This prevents publishing posts with stale numbers or broken examples.

Methodology

Step 1: Extract Session Context

Load the session-extraction module for the full checklist.

Gather raw material from what actually happened:

1. Git history — commits since the session started:

   git log --oneline --since="" --stat
   

   git diff --stat ..HEAD
   

   cargo test  # or the project's test command
   

   find . -name "*.rs" -not -path "*/target/*" | xargs wc -l
   

Step 2: Identify the Story

Every session post answers three questions:

1. What were we trying to do? — the goal, not the task list 2. What did we actually do? — the real path, including pivots 3. What came out of it? — concrete, measurable results

Look for:

Step 3: Draft the Post

Load the narrative-structure module for formatting templates.

Structure (adapt to content):

# Title: [Verb] + [What] + [With What]
Opening (2-3 sentences)
What we set out to do and why. No throat-clearing.
Starting Point
Where things stood before. Concrete: file counts, code state,
what worked and what didn't.
The Work
Key phases. Focus on decisions and pivots, not keystrokes.
Phase 1: [what and why]
Phase 2: [what and why]
Include GIFs from scry recordings where visual.
How We Tested It
What verification looked like. Show the test run, the proof-of-work
evidence. Include terminal recording GIF of tests passing.
Results
Hard numbers. Before/after. What works now.
Screenshots or browser recording GIF if visual.
What's Next
Honest remaining work. No false completeness.

Tone:

Step 4: Quality Gate

1. Slop check — Skill(scribe:slop-detector) on the draft 2. Proof-of-work — Skill(imbue:proof-of-work) on all claims 3. Recording check — does any section need a GIF? 4. Title test — would you click this? Does it promise something specific? 5. Opening test — does paragraph one say what the post is about?

Step 5: Output

Write the post to the requested location (default: docs/posts/).

Report:

Example

A session that ported a Quake 2 engine from C to Rust:

> Title: Rewriting a Quake 2 Engine in Rust with Claude Code > > Opening: We took a 150,000-line C game engine and started > rewriting it in Rust targeting WebAssembly. In one session we went > from an empty workspace to a prototype loading real game data in > the browser. > > Starting point: A Yamagi Quake II fork compiled with Emscripten. > Goal: idiomatic Rust with wasm-bindgen, glow for WebGL2, and > matchbox for P2P multiplayer. > > The work: Seven parallel agents built subsystems — collision, > movement, filesystem, networking, renderer, server, client — while > the main session coordinated integration. A Makefile with > prerequisite checks automated the full build-to-browser pipeline > including game data download. > > How we tested: 180 unit tests across 13 crates. BSP loading > verified against real Quake 2 demo pak0.pak. Browser diagnostics > logged every init step. [Terminal GIF: make test output] > > Results: 10,950 lines of Rust, 180 tests, real game data > loading and flat-shaded BSP rendering in the browser with WASD > movement and mouse look. > > What's next: Textured rendering, collision debugging, sound, > menus, multiplayer.

Every claim is checkable — line counts from wc -l, test counts from cargo test, file counts from filesystem log output.

A session that ported a Quake 2 engine from C to Rust:

> Title: Rewriting a Quake 2 Engine in Rust with Claude Code > > Opening: We took a 150,000-line C game engine and started > rewriting it in Rust targeting WebAssembly. In one session we went > from an empty workspace to a prototype loading real game data in > the browser. > > Starting point: A Yamagi Quake II fork compiled with Emscripten. > Goal: idiomatic Rust with wasm-bindgen, glow for WebGL2, and > matchbox for P2P multiplayer. > > The work: Seven parallel agents built subsystems — collision, > movement, filesystem, networking, renderer, server, client — while > the main session coordinated integration. A Makefile with > prerequisite checks automated the full build-to-browser pipeline > including game data download. > > How we tested: 180 unit tests across 13 crates. BSP loading > verified against real Quake 2 demo pak0.pak. Browser diagnostics > logged every init step. [Terminal GIF: make test output] > > Results: 10,950 lines of Rust, 180 tests, real game data > loading and flat-shaded BSP rendering in the browser with WASD > movement and mouse look. > > What's next: Textured rendering, collision debugging, sound, > menus, multiplayer.

Every claim is checkable — line counts from wc -l, test counts from cargo test, file counts from filesystem log output.