Session To Post

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

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="<session_start>" --stat
   

2. File inventory — what was created and changed:

   git diff --stat <start_commit>..HEAD
   

3. Test results — concrete evidence of what works:

   cargo test  # or the project's test command
   

4. Metrics — scope and scale:

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

5. Conversation context — the user's goals, constraints, and decisions made during the session

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:

• The hook — what makes this interesting? A hard problem, a surprising approach, an impressive result
• Turning points — where did the plan change? What broke? What worked unexpectedly?
• The number — one metric that captures the outcome (lines written, tests passing, performance gain, time saved)

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:

• Write like explaining to a colleague over coffee
• Specifics over adjectives ("180 tests" not "comprehensive suite")
• Show the mess — readers connect with pivots and debugging
• Credit the tools and techniques that made it work
• Under 1500 words unless the content demands more

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:

• Word count
• Slop score
• Verifiable claims count
• Recordings generated (if any)

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.