Session To Post

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
• Sharing a session story with a Reddit community (r/programming,

r/rust, r/Python, r/ClaudeAI, etc.)

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.

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 and 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

Choose format first:

For Reddit: load modules/reddit-format.md instead of the blog template below. The structure, tone, and quality gate differ.

Load the narrative-structure module for blog/case-study templates.

Blog post 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

For blog posts and case studies: 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?

For Reddit posts (additional gates): 1. TL;DR present: is it after --- at the end? 2. Lede not buried: is the most interesting thing in the first two sentences? 3. Subreddit fit: does the content match the target subreddit's norms? Check the subreddit's top posts of the month. 4. First comment drafted: are the repo link and any reference material ready to post as a follow-up comment? 5. Header count: if the post is under 600 words, are headers absent (or replaced with bold inline labels)?

Step 5: Output

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

Report:

• Format used (blog post / case study / Reddit post)
• Word count
• Slop score (blog/case-study only)
• Verifiable claims count
• Recordings generated (if any)
• For Reddit: target subreddit and first-comment content

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.

Exit Criteria

• [ ] Format selected (blog post, case study, or Reddit post)
• [ ] Session brief compiled from git history and conversation

context

• [ ] Draft written to docs/posts/ (or specified path)
• [ ] For blog/case-study: slop score reported, all claims

tagged with evidence references

• [ ] For Reddit: TL;DR present, lede in first two sentences,

target subreddit identified, first comment drafted

• [ ] Word count and verifiable claim count reported
• [ ] Incomplete or unverifiable claims are flagged, not silently

dropped

Narrative Structure

Templates and patterns for turning a session brief into a post.

Post Formats

Blog Post (default)

Best for: dev blogs, company engineering blogs, personal sites.

# [Verb]ing [What] [With/In/Using What]

[2-3 sentence opener. State what was done and the headline result.
No "In this post we will...": just say the thing.]

## Where We Started

[Concrete starting state. Numbers, not adjectives.
"A 150K-line C codebase" not "a large legacy codebase."]

## What We Built

### [Phase/Decision 1 name]

[What and why. 2-4 sentences. Code snippet only if it
illustrates a technique worth sharing.]

### [Phase/Decision 2 name]

[Same pattern. Focus on the interesting parts; skip
anything a reader could guess.]

![Terminal recording of tests passing](assets/tests.gif)

## How We Verified It

[Show the proof. Test output, before/after measurements,
screenshots. This is where recordings from scry belong.]

![Browser recording of the running app](assets/demo.gif)

## Results

| Metric | Before | After |
|--------|--------|-------|
| Lines of code | 0 | 10,950 |
| Tests passing | 0 | 180 |
| Build target | Emscripten | wasm-pack |

## What's Left

[Honest list. Readers respect knowing what isn't done.]

- [ ] Remaining item 1
- [ ] Remaining item 2

Case Study

Best for: marketing, demonstrating tool capability to prospects.

# [Outcome]: [How]

## The Challenge

[1 paragraph. What problem needed solving and why it was hard.]

## The Approach

[Walk through the method. Emphasize decisions, not steps.
Show how the tool/technique enabled the outcome.]

## The Evidence

[Hard numbers. Before/after. Screenshots and recordings.]

## Key Takeaways

1. [Insight that generalizes beyond this project]
2. [Insight about the tool or technique]
3. [What would change if doing it again]

Social Thread

Best for: Twitter/X, Bluesky, LinkedIn.

1/ [Hook: the result in one sentence]

2/ Starting point: [concrete state before]

3/ The approach: [key technique in 1-2 sentences]

4/ [The interesting part: a decision, a pivot, a surprise]

5/ Results: [numbers]

6/ What's next: [honest assessment]

[Attach: GIF from scry recording, screenshot of output]

Writing Rules

1. Lead with the result, not the process 2. One number per section minimum: ground every claim 3. Show, don't summarize: a GIF of tests passing says more than "we wrote comprehensive tests" 4. Name the tools: readers want to know how, not just what 5. Include a pivot: straight-line success stories aren't believable or interesting 6. End with honesty: what's unfinished, what you'd change

Title Patterns That Work

• [Verb]ing [Big Thing] in [Constraint]

e.g. "Porting a Game Engine to Rust in One Session"

• How We [Achieved Result] with [Tool/Technique]

e.g. "How We Hit 180 Tests in 3 Hours with Parallel Agents"

• [Number] [Things] I Learned [Doing X]

e.g. "5 Things I Learned Rewriting C as Rust for WebAssembly"

• From [State A] to [State B]: [How]

e.g. "From Empty Repo to Playable Game: A Claude Code Session"

Anti-Patterns

• "In this blog post, we will explore...": skip the preamble
• "It's worth noting that...": if it's worth noting, just note it
• Listing every file changed: nobody cares about the full diff
• Explaining things the audience already knows
• Screenshots of code when a link to the repo would do
• Claiming something works without showing evidence

Reddit Post Format

Templates and rules for turning a session brief into a Reddit text post that earns upvotes through specificity and honesty.

When Reddit, When Blog

Choose Reddit when:

• You want community engagement (questions, discussion, feedback)
• The work fits a specific subreddit's current interests
• The story is worth starting a conversation, not just archiving

Choose blog when:

• You want permanent, search-indexed content you own
• The post will be linked from documentation or READMEs
• It needs a stable URL for future reference

Subreddit Targeting

Match the primary technology or theme to one subreddit. Avoid cross-posting within 48 hours; it triggers spam filters and community backlash.

Post Structure

Reddit text posts have no required format, but this pattern works for session stories:

Hook (first 2 sentences): the most interesting outcome or observation. Do not bury the lede. Readers who stop scrolling past line 3 are gone.

Context (1-2 sentences): what you were trying to do and why.

The work (2-4 paragraphs): what you built or changed. Name the tools and techniques. Include one code block if it shows something surprising or non-obvious.

Result: numbers. What works now that did not before.

Honest close: what remains, what you would change, what surprised you. This is what makes the post worth bookmarking.

---

TL;DR (required): the whole story in 2-3 sentences. Place it after a --- separator at the bottom. Readers who skip to the end first are your secondary audience; do not disappoint them.

Title Patterns

The title is the entire hook. Test it with: "would someone who knows nothing about this click it?"

• I [did thing] with [tool] — here's what I learned
• Built [thing] in [constraint] — [surprising number]
• [Surprising result]: how we [achieved it]
• Show r/[subreddit]: [what you built] ([brief description])
• [Honest take on tool] after [real production use case]

Keep under 120 characters. The title must work without the body.

Writing Rules

1. First person: "I built" not "we built" unless the team matters to the story 2. No section headers for posts under 600 words; above that, use one level of bold headers only 3. One code block maximum in the body; link the rest to a repo or Gist 4. TL;DR is required: after ---, at the end 5. Under 600 words for most posts; if longer, reconsider whether a blog post is the better medium 6. Conversational close: "happy to answer questions about X in the comments" gives readers a reason to engage

Anti-Patterns

• Copy-pasting your blog post: the tone is wrong and readers notice
• Burying the lede: starting with context before the interesting part
• Screenshot of code instead of a fenced code block
• No TL;DR on anything over 300 words
• "In conclusion...": just end the post
• Excessive bold/italic throughout: signals AI-generated content

First Comment Strategy

For technical posts, plan a follow-up comment before posting. Use it for:

• Full code links (repo URL, Gist)
• Setup instructions that would bloat the post body
• Benchmarks or test output that are reference material, not story

Write this comment in the quality gate step and post it immediately after the main post goes live.

Session Extraction Checklist

Run these commands and capture the output. This is the raw material the narrative is built from.

Git History

# Commits this session (adjust date/hash as needed)
git log --oneline --stat HEAD~20..HEAD

# Files changed summary
git diff --stat <start_commit>..HEAD

# Diff size
git diff --shortstat <start_commit>..HEAD

Capture: commit messages, files touched, insertions/deletions.

Codebase Metrics

# Lines of code (adjust extension for language)
find . -name "*.rs" -not -path "*/target/*" | xargs wc -l | tail -1
find . -name "*.py" -not -path "*venv*" | xargs wc -l | tail -1
find . -name "*.ts" -not -path "*node_modules*" | xargs wc -l | tail -1

# File count
find . -name "*.rs" -not -path "*/target/*" | wc -l

# Test count
cargo test 2>&1 | grep "test result"
# or: pytest --co -q 2>&1 | tail -1
# or: npm test 2>&1 | grep "Tests:"

Capture: total lines, file count, test count and pass/fail.

Architecture

# Directory tree (depth 3)
find . -type d -not -path "*/target/*" -not -path "*node_modules*" \
  -maxdepth 3 | sort

# Key config files
cat Cargo.toml  # or package.json, pyproject.toml

Capture: project structure, dependency count, crate/package organization.

Build and Runtime

# Build output (note timing)
time cargo build --release 2>&1 | tail -5

# Binary/artifact size
ls -lh target/release/*.wasm dist/*.html 2>/dev/null

Capture: build time, artifact sizes.

Conversation Context

These come from the session itself, not from commands:

• Initial goal: what the user asked for
• Constraints: time, tech stack, compatibility requirements
• Key decisions: why X over Y at each fork
• Pivots: where the plan changed and why
• Blockers hit: what went wrong and how it was resolved
• Tools used: parallel agents, specific skills invoked

Output Format

Compile extraction results into a structured brief:

## Session Brief

**Goal**: [one sentence]
**Duration**: [approximate]
**Starting state**: [what existed before]

### Metrics
- Lines written: X
- Files created/modified: Y
- Tests: Z passing

### Key commits
1. [hash] [message]: [significance]
2. ...

### Decisions
1. [decision] because [reason]
2. ...

### Pivots
1. [what changed] because [what happened]
2. ...