メニュー
Converts a Claude Code session into a blog post, case study, or Reddit post. Use when publishing dev blog content or community posts from real sessions.
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/athola/claude-night-market --skill session-to-postコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
Turn hunches into accepted results: worthiness score, evidence bar, research-to-rules. Use when vetting ideas. Not for QA; use night-market-validation-and-qa.
Generates and self-executes a diff-derived test plan for a PR. Use when validating PR changes before merge. Do not use for code review; use sanctum:pr-review.
Curate the web-capture index. Use when the capture backlog grows, captures sit unprocessed at seedling/pending, or to surface stored research during work.
SKILL.md を表示中
| name | session-to-post |
| description | Converts a Claude Code session into a blog post, case study, or Reddit post. Use when publishing dev blog content or community posts from real sessions. |
| globs | **/*.md |
| alwaysApply | false |
| category | artifact-generation |
| tags | ["blog","marketing","session-capture","case-study","storytelling","developer-experience","reddit"] |
| tools | [] |
| complexity | medium |
| model_hint | standard |
| estimated_tokens | 3100 |
| progressive_loading | true |
| modules | ["modules/session-extraction.md","modules/narrative-structure.md","modules/reddit-format.md"] |
| dependencies | ["scribe:slop-detector"] |
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.
scribe:doc-generator)scribe:tech-tutorial)scribe:slop-detector)sanctum:doc-updates)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 and 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 |
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.
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.
Load the session-extraction module for the full checklist.
Gather raw material from what actually happened:
git log --oneline --since="<session_start>" --stat
git diff --stat <start_commit>..HEAD
cargo test # or the project's test command
find . -name "*.rs" -not -path "*/target/*" | xargs wc -l
Every session post answers three questions:
Look for:
Choose format first:
| Format | Module | When |
|---|---|---|
| Blog post | narrative-structure | Dev blog, company blog, personal site |
| Case study | narrative-structure | Marketing, tool demonstrations |
| Social thread | narrative-structure | Twitter/X, Bluesky, LinkedIn |
| Reddit post | reddit-format | Community engagement, r/programming etc. |
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:
For blog posts and case studies:
Skill(scribe:slop-detector) on the draftSkill(imbue:proof-of-work) on all claimsFor Reddit posts (additional gates):
--- at the end?Write the post to the requested location (default:
docs/posts/).
Report:
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 testoutput]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.
docs/posts/ (or specified path)SOC 職業分類に基づく