Press releases are how companies announce things. Reporters rewrite them into news stories — pulling the facts, cutting the marketing voice, adding context, and attributing claims back to the company. The distro-release-rewrite skill turns that workflow into a one-line command.

Hand it a press-release URL and it drafts a 4–5 graf story under 200 words in wire-service style and shows it to you for sign-off. That draft is the deliverable. You do not need to name a newslode — the skill won't ask for one. (You can name one on your own initiative, but it's never expected or required.)

Filing the draft to a Distro newslode is a separate, optional step. If you want it filed, just say so; the skill resolves the publication ID and files it as a draft, then offers to flip it to published. A plain drafting run need not touch the Distro connector at all.

It's generic — not tied to any specific newslode — so any Distro user can install it and point it at their own publications.

What you'll need

  • To draft: nothing. Fetching the release and writing the story doesn't require the Distro connector at all.
  • To file: the Distro Publisher MCP connected, so the skill can resolve newslode names and file drafts. Only needed if you ask it to file.
  • For filing, at least one article already published on the target newslode (the lookup uses recent articles to find publication IDs; brand-new empty newslodes need the ID supplied directly).

What it does

  • Fetches the press release from the URL you provide
  • Asks for the byline if it doesn't already know it (default: [Your name], assisted by Claude)
  • Drafts a tight 4–5 graf story (under 200 words) in wire-service style:
    • Sentence-case headline
    • Lede with company + descriptor + "on [day] unveiled" + the news
    • Press-release link woven into graf 2 via "according to a press release"
    • One quote, attribution split after the first sentence (omitted if the release contains none)
    • Closing graf with caveats, availability, fine print
  • Adds an italic editor's note at the top disclosing the agentic workflow that produced the piece
  • Shows you the full draft in chat — and stops there by default
  • Only if you ask: resolves the newslode, files as a draft on distro_content_publish, and offers to flip to published

Install the skill

Ask Claude:

"Please fetch the distro-release-rewrite 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-release-rewrite.skill. The file will appear in your chat with a Save skill button — click it to install directly.

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

Claude Code users: ask Claude to drop the unzipped folder into ~/.claude/skills/distro-release-rewrite/ and restart the session.

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-release-rewrite, 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-release-rewrite
description: Use this skill when the user asks to rewrite a press release as an original news story. Triggers on requests like "use the Distro release-rewrite skill on [URL]," "rewrite this press release," or any request that pairs a press-release URL with a rewrite goal. This skill's job is to draft a tight 4–5 graf wire-service-style rewrite (under 200 words) and show it in chat for sign-off. The user does NOT need to specify a target newslode — drafting is the deliverable. Filing the draft to a Distro newslode is a separate, optional step that only happens if the user explicitly asks for it.
---

# Distro Release-Rewrite Skill

This skill turns a press release into a short, original news story (4–5 grafs, under 200 words). Producing that first-draft story is the whole job. It is generic — it works for any release the user hands you.

Filing the resulting draft to a Distro newslode is a **separate, optional step**, not part of the default flow (see "Filing is a separate step" below).

## When this skill applies

The user provides a press-release URL (PR Newswire, Business Wire, GlobeNewswire, a company blog, etc.) and asks for a release-rewrite.

A typical command:

> "Please use the Distro release-rewrite skill on this link: [URL]"

The skill's job is to produce the **first-draft story** from the release. The user does **not** need to specify a target newslode, and you should **not** ask for one. A user *could* name a newslode on their own initiative in the prompt, but that's not expected or required — and even then, treat drafting and filing as two separate shots.

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

## The flow

1. **Fetch the press release.** Use `web_fetch` on the URL provided.
2. **Ask for the byline** if not already established in the conversation. See "Byline" below.
3. **Draft the story in chat.** Show the proposed title, description, body, and source-attribution placement so the user can see the full piece. **This is the end of the default flow.** Stop here unless the user explicitly asks you to file it.

Everything below the next section ("Filing is a separate step") only applies if the user asks you to file or publish the draft.

## Filing is a separate step

Writing the draft and filing it to a newslode are two different shots. The default behavior of this skill is to write the draft and stop. Do not ask which newslode to file to, and do not file anything, unless the user explicitly requests it.

Theoretically, a run of this skill need not involve the Distro connector at all — it's just drafting. The Distro tools only come into play when (a) the user asks you to file or publish the resulting draft, or (b) the skill itself hasn't been saved to the user's Claude Desktop yet and needs to be installed.

If the user does ask you to file the draft, they'll typically name the newslode at that point. Then, and only then:

1. **Resolve the newslode name to a publication ID.** See "Resolving the newslode" below.
2. **File as a draft on Distro** using `distro_content_publish` with `status: "draft"`. See "Publishing call" and "HTML formatting."
3. **Offer to flip to published.** After filing the draft, explicitly offer: "Want me to flip it to published, or do you want to review and edit in the Distro editor first?" Default expectation is the user will edit in Distro and publish manually — but offer the shortcut.

## Resolving the newslode

(Only relevant once the user has asked you to file the draft.)

The `distro_content_publish` tool requires a numeric `publicationId`. There is no dedicated "list publications" tool, so resolve the newslode name like this:

1. Call `distro_content_list` with `source: "publication"` and `limit: 50`. This returns articles from publications the authenticated user owns. Each article in the response includes a `publication` object with `id` and `publication` (name) fields.
2. Scan the results for a publication whose name matches the user's request (case-insensitive, fuzzy — e.g., "Liqquidity's Newslode" should match "liqquidity's newslode" or even "Liqquidity").
3. If exactly one match: use that ID.
4. If multiple matches or no match: ask the user to clarify or supply the publication ID directly.
5. If the target newslode is brand new and has no articles yet, the lookup will fail. In that case, ask the user for the publication ID directly.

If the user has provided the publication ID directly (numeric), skip the lookup.

## Byline

Default byline for press-release rewrites assisted by this skill: **`[User's name], assisted by Claude`**.

If the user's name isn't already known from earlier in the conversation, ask. Don't assume.

The "assisted by Claude" suffix is a transparency norm for AI-assisted content — keep it unless the user explicitly tells you to drop it.

## Editor's note (transparency disclosure)

Include an editor's note at the very top of the body, in italics, in parentheses. It should describe the actual workflow that produced the piece. Adapt it to the user's specific tooling, but the standard form is:

> *(EDITOR'S NOTE: The first draft of this story was written on [Claude Desktop / Claude Code / claude.ai] using a custom skill designed to handle press-release rewrites. I then used Distro Publisher, our MCP server, to file a draft directly to [newslode name], and then used the DistroVerse editing interface to make some edits, and I personally checked all the facts prior to publication.)*

If the piece is only being drafted and not filed, trim the note accordingly (drop the Distro-filing clauses). The note doubles as a live demonstration of the agentic-press workflow.

## Story structure

### Length and shape

- **4–5 grafs, under 200 words** in the body (excluding the editor's note). Tight is the goal — if a draft creeps over 200, cut.
- **Wire-service inverted pyramid:** lede → context/details → "why it matters" attributed to the company → quote → availability/caveats.

### Headline

- **Sentence case.** No exceptions.
- **Concrete and specific** — name the company and the news in plain English. Avoid colons as crutches.
- Example: "MoonPay rolls out Mastercard debit card for AI agents"

### Description / preview

- **~120 characters or fewer.** This is the feed preview.
- Lead with the source attribution prefix ("MoonPay:") followed by a single sentence summarizing what's new.
- Example: `MoonPay: New "MoonAgents Card" lets agents spend stablecoins directly from an on-chain wallet at any merchant that takes Mastercard.`

### Lede (graf 1)

- **Wire-service style:** company + descriptor + "on [day] unveiled/announced/said" + the news, in one sentence.
- Use **"unveiled"** or **"announced"** over "said it will" — tighter, more active, fits the register.
- Assume readers don't know the company. Always include a brief epithet — "MoonPay, a crypto payments platform," "Visa, the card-payments network," "Aethir, a decentralized GPU network." Prefer descriptors that match the actual architecture, not the company's marketing framing (e.g., a centralized onramp is a "platform," not a "network").
- Pull the descriptor from the boilerplate at the bottom of the release if needed, or from prior coverage on the same newslode.

### Graf 2: context and source attribution

- This is where the **press-release link** goes. Weave it into the natural flow with: "...according to a [press release](URL)." Place after the first concrete factual claim that came from the release (partners, mechanics, scope).
- Don't put the link in the lede. The lede should be clean news.
- Don't repeat the attribution in later grafs. Once you've established in graf 2 that this is sourced from a press release, every subsequent "the company said" is implicitly "in the press release."

### Grafs 3–4: mechanics and the company's pitch

- Explain how the thing works in plain language.
- Explain **why the company says it matters** — but attribute it to them, in their words. Don't editorialize. Phrases like "the company said" or "according to [Company]" do the work.
- Use scare quotes sparingly around marketing terms that need distancing (e.g., the card "extends" the company's existing infrastructure).

### Quote

- One quote, ideally from the CEO or product lead named in the release.
- **Split the attribution after the first sentence or natural clause** — don't make readers wait through a three-sentence block before learning who's talking. Wire-service convention.
- Example structure: `"First sentence of quote," said [Name], [Title]. "Second sentence. Third sentence."`
- If the release contains no quote, don't fabricate one. Omit it.

### Closing graf: caveats, availability, fine print

- Wallet custody, refund/revoke mechanics, geographic rollout, identity-verification requirements, pricing — whatever the release flags as the practical fine print.
- Keep it factual. Don't end on a flourish or a sales-pitch echo.

## Voice and style rules

These are the editorial principles that govern the prose. They override anything in the brads-voice skill that conflicts.

### Tone

- **Professional, neutral, informed.** Not a cheerleader. Skeptical but curious.
- **Reporter hat, not stenographer.** You're rewriting the release, not reproducing it. Pull facts; drop the marketing voice.
- Active voice. Concrete verbs. Short sentences.

### Em dashes — avoid

Readers associate em dashes (`—`) with AI-generated writing, even with disclosure. Default to commas, periods, or parentheticals instead. **Don't use em dashes in this skill's output.**

### En dashes — sparingly, with spaces

When a dash genuinely fits (parenthetical aside, mid-sentence pivot), use a **spaced en dash**: ` – ` (space, en dash `–` U+2013, space). Not `—` (em dash). Not `--` (double hyphen). Once or twice per piece, max.

### Hyphenation

- **on-chain** (hyphenated, not "onchain")
- **off-chain** (hyphenated)
- **self-custodial** (hyphenated)
- **co-founder** (hyphenated)

### Attribution

- For things the company asserts (importance, novelty, "first of its kind"), attribute clearly: "the company said," "according to [Company]," "[Name] said."
- For factual mechanics confirmed by the release (how the product works, who the partners are), attribute once in graf 2 via the press-release link, then state subsequent facts plainly.

### Don't

- Don't use em dashes.
- Don't editorialize about whether the product is good, novel, or transformative — that's the company's claim, not yours.
- Don't use marketing verbs like "leverage," "utilize," "empower," "unlock" (unless quoting).
- Don't pad with filler like "in today's rapidly evolving landscape."
- Don't write listicles or use bullet points in the body.
- Don't add information that isn't in the release (or in clearly-cited public sources).

## Publishing call

(Only when the user has signed off and asked you to file.)

When the user signs off on the draft, file with `distro_content_publish`:

```
distro_content_publish({
  publicationId: <resolved ID>,
  title: <sentence-case headline>,
  preview: <~120-char description with "Source:" prefix>,
  content: <HTML body, see below>,
  author: "[User's name], assisted by Claude",
  status: "draft",
  contentFormat: "html"
})
```

**Important: do NOT set `sourceName` or `sourceUrl`.** This is a release-rewrite (an original news story based on the release), not a link-style post. The metadata fields stay empty. The press-release link belongs in the body, woven into graf 2 via "according to a press release."

## HTML formatting

Pass the body as HTML, not markdown — `distro_content_update` only handles HTML cleanly, and using HTML at publish time keeps the editing path consistent.

Wrap each graf in `<p>...</p>`. The editor's note goes in `<em>...</em>` inside the first `<p>`, followed by `<br><br>` and then the lede. Example:

```html
<p><em>(EDITOR'S NOTE: ...)</em><br><br>Lede sentence...</p>
<p>Graf 2 with <a target="_blank" rel="noopener noreferrer nofollow" class="tiptap-link" href="[release URL]">press release</a> link...</p>
<p>Graf 3...</p>
<p>Graf 4 with <a href="...">quote and attribution</a>...</p>
<p>Graf 5 closing...</p>
```

The press-release link should use the same anchor attributes the Distro editor produces: `target="_blank"`, `rel="noopener noreferrer nofollow"`, `class="tiptap-link"`.

## After filing

After `distro_content_publish` returns successfully, tell the user:

1. The content ID and that it was filed as a draft.
2. That they can review and edit in the Distro editor.
3. **Offer the shortcut:** "Want me to flip it to published, or do you want to review and edit in the Distro editor first?"

If the user says publish, call `distro_content_update` with `status: "published"`. If they say they'll edit first, stop there.

## Example invocation

> User: "Please use the Distro release-rewrite skill on this link: https://www.prnewswire.com/news-releases/example-release"

Steps:

1. `web_fetch` the URL.
2. Confirm the byline if not already known.
3. Draft the story in chat with proposed title, description, and body. Show the user. **Stop here** — don't ask for a newslode, don't file anything.

If the user later says "file that as a draft to DeAI News," that's a separate shot:

1. `distro_content_list({source: "publication", limit: 50})` to find the DeAI News publication ID.
2. `distro_content_publish` with `status: "draft"` and the resolved `publicationId`.
3. Report the content ID. Offer to flip to published.

## Known issues and quirks

- **`distro_content_update` requires HTML, not markdown.** If the user asks for revisions after filing, send updates as HTML to preserve paragraph breaks and link formatting.
- **`distro_content_delete` has a known server-side bug** (as of this skill's writing). If a draft needs to be removed, advise the user to delete it via the Distro UI rather than via the tool.
- **Brand-new newslodes won't appear in the lookup** until they have at least one article. For these, ask the user for the publication ID directly.

When to use this skill

  • Turning a press release (PR Newswire, Business Wire, GlobeNewswire, company blog) into an original news story
  • Stories that need a wire-service inverted pyramid: lede, context, why-it-matters, quote, fine print
  • When the deliverable should be tight: 4–5 grafs, under 200 words

When not to use this skill

  • Linking to a press release without rewriting it — use distro-link-post instead. That's a one-graf hot take with the original publisher's headline shortened, not an original story.
  • Original reporting that goes well beyond the release (interviews, analysis, multi-source synthesis) — use distro_content_publish directly without this skill's constraints.
  • Republishing the release verbatim with attribution — that's not what Distro is for; link to it.
  • Email-based stories — use distro-email-ingest instead.

Feedback

This is v1.2 — drafting and filing are now separate shots; the skill no longer asks for a newslode by default. Edge cases or suggestions → reply or ping Brad.