Press release story skill

Turns a press release into an original 4–5 graf news story (under 200 words). Drafting is the job; filing to a newslode is a separate, optional step. No em dashes.

ByBradley Keoun
PublishedMay 1, 2026 at 7:45 PM
16 min read

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 press-release-story skill (formerly distro-release-rewrite) 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 on two fronts. It isn't tied to any specific newslode, so any Distro user can point it at their own publications. And it isn't tied to any one AI platform: the skill is a plain SKILL.md file in the open Agent Skills format, so it works with Claude, ChatGPT and Codex, or any other agent that can load skills or follow a set of written instructions.

What you'll need

  • To draft: any AI agent that can read a web page. Nothing Distro-specific.
  • To file: the Distro Publisher connector, 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, and stops if it can't read it
  • Asks for the byline if it doesn't already know it (default: [Your name], assisted by AI)
  • 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 bottom, below a divider, 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 it as a draft with distro_content_publish, and offers to flip it to published

Install the skill

Any agent with a Distro connector: ask it:

"Please fetch the press-release-story skill from Distro Skills and install it."

The agent pulls this story, extracts the SKILL.md from the fenced block below, and saves it to a folder called press-release-story wherever your agent keeps its skills. Requires the Distro Reader or Distro Publisher connector so the agent can pull the story. Distro Skills is a public newslode, so no subscription is needed.

Claude Desktop and Claude.ai: ask Claude for a .skill file instead; it will package the skill and give you a Save skill button to click. Claude Code: the folder goes in ~/.claude/skills/press-release-story/; restart the session.

Other agents that support the Agent Skills format (including ChatGPT and Codex): put the folder wherever that agent loads skills from, per its own docs.

Agents without skill support: paste the contents of the fenced block below into the agent's custom instructions, or at the top of a chat, and then hand it a press-release URL.

Manual install: copy the fenced block below into a file called SKILL.md, inside a folder called press-release-story. If your app wants an upload, zip the folder (folder as the zip root).

The skill source

This is the canonical SKILL.md:

---
name: press-release-story
description: Use this skill when the user asks to rewrite a press release as an original news story. Triggers on requests like "use the press-release-story skill on [URL]," "use the release-rewrite skill on [URL]" (the skill's former name), "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.
---

# Press-Release-Story 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 story written from it.

A typical command:

> "Please use the press-release-story 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 whatever web-fetch or browsing tool your environment provides to read the URL. If you can't read the release, say so and stop; don't draft from the URL or search snippets alone.
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 the user asks you to file or publish the resulting draft.

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 AI`**. If you know the name of the assistant or model you're running as, you may name it instead of "AI".

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

The "assisted by AI" suffix is a transparency norm for AI-assisted content — keep it unless the user explicitly tells you to drop it (for example, because they disclose AI use in the editor's note instead).

## Editor's note (transparency disclosure)

Include an editor's note at the very bottom of the body, after a horizontal divider (`<hr>`), 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 with [the AI assistant or agent you're running in] using a custom skill designed to handle press-release rewrites. I then used Distro Publisher, our MCP connector, 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 a separate voice or style 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 AI",
  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 lede leads the body. After the final graf, add a horizontal divider (`<hr>`), then the editor's note in `<em>...</em>` inside its own `<p>`. Example:

```html
<p>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>
<hr>
<p><em>(EDITOR'S NOTE: ...)</em></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 press-release-story skill on this link: https://www.prnewswire.com/news-releases/example-release"

Steps:

1. 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.3 — renamed from distro-release-rewrite, the editor's note moved to the bottom of the story, and the skill is now platform-neutral, so it runs on any AI agent, not just Claude. Edge cases or suggestions → reply or ping Brad.

Distro Skills