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