Night Market Skill — ported from claude-night-market/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:
- 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.
