Session to Post Skill | Agent Skills

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

After completing a meaningful chunk of work you want to share
Creating dev blog content from real sessions
Building case studies for tools, libraries, or techniques
Producing marketing content that demonstrates capability
Documenting a process for teammates who weren't in the session

When NOT To Use

Writing API reference documentation (use scribe:doc-generator)
Creating step-by-step tutorials (use scribe:tech-tutorial)
Cleaning up existing prose (use scribe:slop-detector)
Internal project documentation (use sanctum:doc-updates)

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:

Git history — commits since the session started:

git log --oneline --since="<session_start>" --stat

File inventory — what was created and changed:
```
git diff --stat <start_commit>..HEAD
```
Test results — concrete evidence of what works:
```
cargo test  # or the project's test command
```

Metrics — scope and scale:

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

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

Step 2: Identify the Story

Every session post answers three questions:

What were we trying to do? — the goal, not the task list
What did we actually do? — the real path, including pivots
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

Slop check — Skill(scribe:slop-detector) on the draft
Proof-of-work — Skill(imbue:proof-of-work) on all claims
Recording check — does any section need a GIF?
Title test — would you click this? Does it promise something specific?
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.

Agent Skills: Session to Post

Install this agent skill to your local

Skill Files