Session To Post
Install when you turn an agent or build session brief into a credible dev blog post or case study with proof, metrics tables, and honest scope left.
Overview
Session-to-post is an agent skill most often used in Grow (also Launch distribution, Build docs) that applies blog and case-study templates to turn session briefs into proof-backed technical posts.
Install
npx skills add https://github.com/athola/claude-night-market --skill session-to-postWhat is this skill?
- Default blog post template with opener, starting state, phased build sections, verification, results table, and what's l
- Separate case study format aimed at marketing and prospect-facing proof
- Verification section mandates test output, measurements, and scry-style terminal or browser recordings
- Results table pattern: before/after metrics with concrete numbers not adjectives
- Writing-quality module (~450 estimated tokens) with narrative-structure category
- estimated_tokens: 450
- two post formats: blog post and case study
Adoption & trust: 1 installs on skills.sh; 304 GitHub stars; 3/3 security scanners passed (skills.sh audits); trending (+100% hot-view momentum).
What problem does it solve?
You finished a substantial build session but only have chat logs—no structured post with metrics, verification, and a credible what's-left section.
Who is it for?
Indie developers and small teams documenting migrations, agent-assisted builds, or tool evaluations on personal or engineering blogs.
Skip if: Pure SEO landing copy with no technical narrative, or posts when you lack any real before/after numbers or verification artifacts.
When should I use this skill?
You have a session brief or build recap to publish as a blog post or case study with structured sections and proof.
What do I get? / Deliverables
You get a publication-ready outline or draft following Night Market narrative patterns, with sections for proof, results tables, and embedded recordings where assets exist.
- Blog post or case study markdown draft from session input
- Results table and what's-left checklist aligned to actual session state
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Publishing session learnings is a grow-phase content motion that compounds distribution and trust after you have built something worth showing. Content subphase fits narrative templates, blog and case-study structures, and embed patterns for terminal and browser recordings.
Where it fits
Draft a post documenting phased migration decisions while test counts and LOC are still fresh from the session.
Publish a case study variant to show prospects how your tool performed on a real workload.
Ship a weekly build recap with verification GIFs and a results table to grow newsletter or blog audience.
Pair release notes with a longer blog narrative that shows tests passing before you announce broadly.
How it compares
Use instead of ad-hoc chat summarization when you need a fixed dev-blog arc with verification and honest backlog—not a generic social thread.
Common Questions / FAQ
Who is session-to-post for?
Solo builders and tiny teams who ship in public and want session work reframed as trustworthy technical writing with metrics and proof.
When should I use session-to-post?
Use it in Grow for content and lifecycle storytelling; in Launch for distribution after a ship milestone; and in Build docs when capturing implementation decisions right after the session.
Is session-to-post safe to install?
It is a writing template skill without mandatory network calls; review the Security Audits panel on this Prism page and never fabricate metrics the skill expects you to supply honestly.
SKILL.md
READMESKILL.md - Session To Post
# 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.]  ## How We Verified It [Show the proof. Test output, before/after measurements, screenshots. This is where recordings from scry belong.]  ## 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]` 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 --- module: reddit-format category: writing-quality dependencies: [] estimated_tokens: 530 --- # 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