Company blog posts are where a lot of real news breaks now, but they're written to sell, not to inform. distro-blog-post turns one into an original, reader-first news story: it strips the booster voice, leads with the actual news, and hands you a draft for sign-off.

It's the blog-post cousin of distro-release-rewrite, with two deliberate differences. It attributes to "a blog post" rather than a press release, and it goes deeper than a wire brief — because a blog post rarely gives a reader the context to know why the news matters.

To close that gap, the skill researches the backstory of the companies involved, writes a nut graf that spells out the bigger topic in plain terms, and tells the reader whether this is a signature move or one of many similar deals on either side.

Renamed: this skill was previously published as distro-blog-rewrite. The name is now distro-blog-post; the old trigger phrase still works. If you installed the earlier version, install this one and delete distro-blog-rewrite from your skills list so the two don't compete.

What's new in this version

  • Renamed from distro-blog-rewrite to distro-blog-post.
  • Hard stop on partial fetches: if the full article body can't be retrieved, the skill escalates to the browser tools and then stops rather than drafting from a summary or snippet.
  • Byline is the writer's name alone. No "assisted by Claude" suffix — AI disclosure lives entirely in the note at the bottom.
  • The disclosure note drops the parentheses and is written in first person, describing the actual workflow.

What you'll need

A vanilla Claude with web search for the backstory research, plus browser tools as a fallback when a publisher blocks or degrades bot fetches. Filing the finished draft to a Distro newslode is optional and uses the Distro Publisher MCP — but drafting, the default, needs nothing beyond web access.

What it does

  • Fetches the full blog post, escalating to the browser tools when a plain fetch returns a summary, snippet or paywall stub — and stops rather than drafting from a paraphrase.
  • Verifies every direct quote appears verbatim in the original before using it.
  • Researches each company or project named: what it is, its origin, funding and launch history, and whether the news is a one-off or one of many.
  • Writes a wire-service story with a required nut graf that pulls the camera back to the bigger picture.
  • Folds in a sourced backstory/context block, breaking long grafs up for readability.
  • Attributes to "a blog post," distances the prose from marketing language, and keeps shaky metrics out.
  • Applies Distro house style and closes with the "HOW AI WAS USED IN THE PRODUCTION OF THIS PIECE" disclosure.
  • Treats filing to a newslode as a separate, optional step.

Install the skill

Ask Claude:

"Please fetch the distro-blog-post skill from Distro Skills and give me a .skill file I can install."

Claude will pull this story, extract the SKILL.md from the fenced block below, and package it as distro-blog-post.skill. The file will appear in your chat with a Save skill button — click it to install directly. That registers the skill with your Claude app so it shows up in your skills list and triggers on matching requests.

Requires the Distro Reader or Distro Publisher MCP connected so Claude can pull the story.

Claude Code users: you have a direct path — ask Claude to drop the unzipped folder into ~/.claude/skills/distro-blog-post/ and restart the session. No packaging step needed.

No Distro MCP connected? Copy the SKILL.md contents from the fenced block below into a file called SKILL.md inside a folder called distro-blog-post, zip it (folder as zip root), and upload through Settings → Capabilities → Skills → Upload skill.

The skill source

This is the canonical SKILL.md:

---
name: distro-blog-post
description: >-
  Use this skill when the user (Brad / Saucy) hands over a company or project BLOG
  POST and asks to write it up as an original news story. Triggers on "use the
  blog-post skill on this," "use the blog-rewrite skill on this" (the skill's former
  name), "write this blog post up," "do a story off this post," or any request
  pairing a blog-post URL with a story-writing goal. Sibling
  of distro-release-rewrite, but for blog posts: it attributes to "a blog post" and
  goes deeper than a wire brief, researching the companies' backstory, adding a nut
  graf that spells out the bigger picture, and telling the reader whether the news
  is a one-off or one of many. Produces a ~400–650-word first draft shown in chat
  for sign-off; filing to a newslode is a separate, optional step. Do NOT use for
  press releases (distro-release-rewrite), link-reposts (distro-link-post), X
  threads (x-post-story), research reports (distro-report-writeup), or podcasts
  (lodecast-publishing).
---

# Distro Blog-Post Skill

This skill turns a **company or project blog post** into an original news story.
It is the blog-post cousin of `distro-release-rewrite`. The key differences: a blog
post is attributed as "a blog post" (not a press release), and the deliverable is
richer than a tight wire brief — Brad wants backstory, a nut graf, and a sense of
where the news sits in each company's arc.

Producing that first-draft story is the whole job. Filing it to a newslode is a
**separate, optional step** (see "Filing" below).

Always apply `distro-house-style` on top of this skill before showing or filing.

## When this applies

The user provides a company/project blog-post URL (e.g., a Substack, a corporate
`/blog/` page, a project's Mirror or Ghost post) and asks for a writeup. A typical
command: "Use the blog-post skill on this: [URL]".

If the user supplies only a newslode but no URL, ask for the URL. You can't rewrite
a post you don't have.

## The flow

1. **Fetch the blog post — the FULL text, never a summary.** Start with
   `web_fetch`. Many publishers (Substack among them) block or degrade bot fetches,
   and `web_fetch` may quietly return a summary, a snippet, a paywall stub, or just
   the page metadata instead of the article. Treat any of those as a failed fetch.

   If you did not get the complete article body, escalate to the Chrome browser
   tools: `tabs_context_mcp`, then `navigate` to the URL, then `get_page_text` to
   pull the article text. Close the tab when you're done.

   **If Chrome also fails, stop and tell the user.** Do not draft the story from a
   summary, a snippet, an excerpt, search-result text, or metadata. A rewrite built
   on a paraphrase invents quotes and misstates figures, which is worse than no
   draft. Say what you tried and what came back, and let Brad decide.

   Once you have the full text, verify every direct quote you plan to use appears
   verbatim in it.
2. **Research the backstory.** This is what separates a blog rewrite from a release
   rewrite. Run web searches to gather, for each company/project named:
   - what it is, in one plain-English epithet;
   - founding/origin, funding, and launch history;
   - whether this deal/integration is a one-off or **one of many** (look for a
     pattern of similar announcements on either side).
   Prefer neutral secondary sources (Messari, reputable coverage) over the
   company's own marketing. Every researched fact must be sourced per house style.
3. **Ask for the byline** if not already known (see "Byline").
4. **Draft the story in chat.** Show the proposed headline, description, body, and
   the AI-disclosure note. **Stop here** unless the user explicitly asks to file it.

## Story structure

Wire-service inverted pyramid, but with a nut graf and a backstory block folded in.
Target **roughly 400–650 words** in the body (excluding the disclosure note). Longer
than a release rewrite, because the context is the point — but every graf earns its
place.

### Headline
- Sentence case. 70 characters max (house style). Name the companies and the news.
- Capitalize lowercase-styled brand names at the start (house style rule 2).

### Description / preview
- ~120 characters. Lead with a source attribution prefix (e.g., "peaq:") and one
  sentence on what's new.

### Lede (graf 1)
- Company + epithet + "on [day] said/unveiled/announced" + the news, in one clean
  sentence. Assume the reader has never heard of either company; give each a short
  descriptor that matches its actual architecture, not its marketing framing.

### Attribution graf (graf 2)
- Where the **blog-post link** goes, woven in: "...according to a
  [blog post](URL)." Place it after the first concrete claim drawn from the post.
  Once established here, later "the company said" is implicitly from the post.

### Nut graf (the "so what")
- **This is required and is the heart of a blog rewrite.** In one short graf, pull
  the camera back and spell out the bigger topic the news is an instance of — the
  thing a smart reader should take away about why it matters. Say it in plain,
  concrete terms, even a vivid image if it fits, without overdramatizing. (For the
  peaq/Virtuals story, the nut graf was: giving a physical robot "a mind for hire
  and a purse to pay for it" — a software agent that takes up residence in the
  hardware and transacts through it.) Name the real-world stakes, not the hype.

### Backstory / context block
- A few short grafs (house style rule 3: break them up) on who the players are and
  how they got here: origin, funding, scale, and — importantly — whether this is a
  **one-off or one of many**. Readers want to know if this is a signature deal or
  the latest in a series on either side. Source every fact inline.

### Mechanics / demo graf
- How the thing actually works, in plain language, including any demo or figures the
  post offers. Keep numbers you can source; drop shaky marketing metrics.

### Quote (optional)
- If the post carries a usable quote from a named exec, use one, splitting the
  attribution after the first sentence. If there's no quote, don't fabricate one.

### Closing graf
- Availability, rollout, caveats, fine print. End factual, not on a sales flourish.

## Voice and style rules

These govern the prose and override anything in brads-voice that conflicts.

- **Reporter hat, not stenographer.** Pull facts; drop the blog's marketing voice.
  A blog post is even more promotional than a press release, so distance yourself
  from booster language and attribute claims of importance/novelty to the company.
- Professional, neutral, informed. Active voice, concrete verbs, short sentences.
- **No em dashes.** Spaced en dashes only, sparingly (house style).
- Hyphenate on-chain, off-chain, self-custodial, co-founder.
- Don't editorialize about whether the thing is good or transformative — that's the
  company's claim. Don't use "leverage," "utilize," "empower," "unlock" (unless
  quoting). Don't pad with "in today's rapidly evolving landscape."
- Don't invent facts not in the post or in clearly-cited public sources.

## Byline

Default: **the user's name alone** (e.g., `Bradley Keoun`). If the user's name
isn't known from the conversation, ask.

Do **not** append "assisted by Claude" or any similar suffix. The byline belongs to
the writer, who is the one using AI-assisted tools to produce the story. Disclosure
of AI's role is handled entirely by the AI-disclosure note at the bottom of the
piece (see below). Only add a suffix if the user explicitly asks for one.

## AI-disclosure note (house style rule 5)

At the very bottom, after an `<hr>`, in italics, labeled exactly:

> *HOW AI WAS USED IN THE PRODUCTION OF THIS PIECE: ...*

**No surrounding parentheses**, and written in **Brad's first person** ("I drafted...",
"I filed...", "I checked..."), not in third person about him. The byline is his; this
note is him describing the tools he used.

Describe the actual workflow: this skill, whether the post was read via `web_fetch`
or the Chrome browser tool, the background research, the newslode filed to via the
Distro Publisher MCP connector, and the verbatim quote check against the original
post. Not "EDITOR'S NOTE."

## Filing (separate, optional step)

Drafting is the default end of the flow. Only if the user explicitly asks to file:

1. Resolve the newslode name to a numeric `publicationId` by calling
   `distro_content_list({source: "publication", limit: 50})` and matching the
   publication name (fuzzy, case-insensitive). If ambiguous or brand-new (no
   articles yet), ask for the ID.
2. File with `distro_content_publish`, `status: "draft"`, `contentFormat: "html"`,
   `author: "[User]"` (no "assisted by Claude" suffix). Do **not** set
   `sourceName`/`sourceUrl` — this is an original rewrite; the blog link lives in
   graf 2.
3. After filing, report the content ID and offer: "Want me to flip it to published,
   or review and edit in the Distro editor first?"

### HTML formatting when filing
Wrap each graf in `<p>...</p>`. Inline links use the Distro editor's anchor
attributes: `target="_blank" rel="noopener noreferrer nofollow" class="tiptap-link"`.
After the final graf, add `<hr>` then the disclosure note in `<em>` inside a `<p>`.

## Known quirks
- `distro_content_update` requires HTML, not markdown.
- `distro_content_delete` has a known server-side bug; delete via the Distro UI.
- Brand-new newslodes won't appear in the lookup until they have one article.

When to use

  • Someone hands you a company or project blog post and wants a news story off it.
  • You want the backstory, nut graf, and one-of-many context, not just a wire brief.

When not to use

  • Press releases (use distro-release-rewrite), plain link-reposts (distro-link-post), X threads (x-post-story), research reports (distro-report-writeup), or podcast episodes (lodecast-publishing).

Feedback

This is v2. Edge cases or suggestions → reply or ping Bradley Keoun.