Skill: athola/nm-scribe-session-to-post (version 1.0.2)

--- name: session-to-post description: | Convert a Claude Code session into a shareable blog post or case study capturing decisions, process, and outcomes version: 1.9.5 triggers: - blog - marketing - session-capture - case-study - storytelling - developer-experience metadata: {"openclaw": {"homepage": "https://github.com/athola/claude-night-market/tree/master/plugins/scribe", "emoji": "\ud83e\udd9e", "requires": {"config": ["night-market.scribe:shared", "night-market.scribe:slop-detector"]}}} source: claude-night-market source_plugin: scribe --- > **Night Market Skill** — ported from [claude-night-market/scribe](https://github.com/athola/claude-night-market/tree/master/plugins/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 - 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: 1. **Git history** — commits since the session started: ```bash git log --oneline --since="<session_start>" --stat ``` 2. **File inventory** — what was created and changed: ```bash git diff --stat <start_commit>..HEAD ``` 3. **Test results** — concrete evidence of what works: ```bash cargo test # or the project's test command ``` 4. **Metrics** — scope and scale: ```bash 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): ```markdown # 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.

path: modules/narrative-structure.md
content: ---
module: narrative-structure
category: writing-quality
dependencies: []
estimated_tokens: 450
---

# 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.

```markdown
# [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.

```markdown
# [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]`
  — "Porting a Game Engine to Rust in One Session"
- `How We [Achieved Result] with [Tool/Technique]`
  — "How We Hit 180 Tests in 3 Hours with Parallel Agents"
- `[Number] [Things] I Learned [Doing X]`
  — "5 Things I Learned Rewriting C as Rust for WebAssembly"
- `From [State A] to [State B]: [How]`
  — "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


path: modules/session-extraction.md
content: ---
module: session-extraction
category: data-gathering
dependencies: []
estimated_tokens: 400
---

# Session Extraction Checklist

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

## Git History

```bash
# 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

```bash
# 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 + pass/fail.

## Architecture

```bash
# 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

```bash
# 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:

```markdown
## 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. ...
```


Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: clean | SkillSpector: clean (LOW)