If you publish to a Distro newslode, you eventually want a second set of eyes before a draft goes live. The distro-copyediting-skill gives you a professional news-organization copy desk on demand. Hand it a story – a draft, a published piece, or text in the chat – and it reads it the way an editor would.
Version 2.0 is a bigger change than the number suggests. The first release was a proofreader: it found the typos, the AP slips and the awkward sentences, handed you a grouped list, and left the fixing to you. This one works the way a copy desk actually works. It opens the sources your story cites and checks the load-bearing claims against them, walks you through every finding one at a time so you can approve, reject or reword it, and then applies only what you approved – in a single surgical pass that touches nothing else.
That last part matters more than it sounds. The skill never writes back a cached copy of your draft, because you are usually still editing it in the DistroVerse editor while the review is running. It re-fetches the live story right before it writes, changes just the approved spots, and leaves the rest byte-for-byte intact.
It still knows the house style. It follows AP, but where Distro deviates from AP the house rule wins – most importantly the spaced en dash ( – ) instead of the em dash. It will not flag your en dashes or nag you to "fix" them.
What you'll need
The Distro Publisher MCP connected, so Claude can pull drafts and write the approved edits back. Distro drafts aren't publicly readable, so the skill retrieves them through the content tools rather than the public story reader. For a published story, the Distro Reader MCP is enough if you only want the flags.
What's new in v2.1
- A stale-slug check on drafts. A story's URL slug is set from whatever the headline was when it was first filed, and it doesn't follow later hed rewrites. While a story is still a draft, the skill compares the slug to the current headline and flags it when the slug carries a different claim – a dropped company name, a reversed verb. It's cosmetic and free to fix before publication, costly after, so the skill raises it only on drafts.
- Punctuation inside a quotation belongs to the source. House style stops at the quotation mark. If a source used a serial comma and house style drops it, the skill flags it as verbatim rather than silently "fixing" a direct quote.
What was new in v2.0
- Accuracy against your own cited sources is now the top-priority bucket. The skill opens the links in your story and checks what they actually say – watching for mechanism errors, relationship upgrades ("bought" where the source says "partnered"), scope creep and stretched attribution. It quotes the source's own wording so you can judge the gap yourself.
- One finding at a time. No more grouped dump. Each finding gets a number, the quoted text, the rule and an exact suggested fix, and then it waits for your keep / fix / reword before moving on.
- Edits applied at the end, in one write. The skill re-fetches the live story, asserts every replacement string matches exactly once, re-reads the spliced result as plain text to catch stray spaces around inline links, and then does a single update.
- Partial quotes get a scope check. If you trimmed a quotation, it pulls the original and asks whether the trim narrows or widens the claim. Trimming is often right – it should just be a decision rather than an accident.
- Headline and dek character counts are computed, not eyeballed, for the current text and for every option offered.
- It withdraws its own bad suggestions. If a proposed fix turns out to introduce a problem, it says so instead of defending it.
- It reports the status it actually sees. If you think you published and the API says
draft, you hear about that before you hear about commas. - More house style and AP. The no-subject-name-prefix rule for deks on original stories, plus lowercase "internet," "longtime," possessives on names ending in s, and hyphenation consistency across the piece.
What it does
- Fetches the live story fresh – draft or published – and again right before applying anything, so concurrent edits in the DistroVerse editor never get clobbered.
- Sorts findings into five buckets, most severe first: accuracy against sources, clear errors, AP and house style, judgment calls, and verbatim text.
- Catches spelling, grammar, subject-verb agreement, doubled words, broken or duplicated punctuation, and broken links.
- Checks AP style: OK (not "Ok"), no Oxford comma, colons and semicolons outside quotation marks, number style, and more.
- Respects Distro house style – notably the spaced en dash instead of the em dash, and no subject-name prefix on original-story deks.
- Flags but never silently "fixes" verbatim or reproduced text (quoted prompts, source quotes, tweets, error messages), including punctuation inside a quotation, and suggests "[sic]" or a note instead.
- On drafts, flags a URL slug that still reflects an older headline, while it's still free to change.
- Stops after the flags if you say you'd rather do the fixing yourself.
Install the skill
Ask Claude:
"Please fetch the distro-copyediting-skill from Distro Skills and give me a
.skillfile I can install."
Claude will pull this story, extract the SKILL.md from the fenced block below, and package it as distro-copyediting-skill.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-copyediting-skill/ 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-copyediting-skill, 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-copyediting-skill
description: "Use this skill whenever the user (Bradley Keoun / \"Brad\" / \"Saucy\") asks to copy edit, proofread, line edit, or \"check\" a story, draft, post, headline, or any piece of writing destined for a Distro publication (Coding Journal, Hardcore Tech, Liqquidity's Newslode, The January Strategy, DeAI News, DistroVerse, Fed Feed, etc.). Triggers on requests like \"copy edit this story,\" \"proofread this draft,\" \"check this for typos/AP style,\" \"clean up the grammar in this post,\" or any request pairing a Distro story/URL/draft with an editing-for-correctness goal. Apply eagerly even if the user doesn't say the words \"copy edit.\" Acts as a professional copy editor for a news organization, working an interactive, approve-as-you-go process: it checks the story against its own cited sources, does a copyedit pass, presents findings ONE AT A TIME for keep/fix, then applies the approved edits in a single surgical pass at the end."
---
# Distro copyediting skill
Act as a professional copy editor for a Distro news publication. The workflow has
three phases, in this exact order:
1. **Copyedit pass** — read the live story and find problems in five buckets.
2. **Review one-by-one** — present each finding individually so the user can
approve, reject, or reword it. Do NOT dump a grouped list.
3. **Apply at the end** — after every finding is decided, apply the approved
edits in ONE surgical write.
Default posture: **do not change anything until the user has approved it.** You
are proposing edits, not rewriting the piece. Never rewrite sentences that work.
---
## Phase 0 — Retrieve the live story (fetch fresh)
Always edit against the **current live version**, never a cached copy.
- If the user names or links a draft, resolve it to a `contentId` and pull it
with `distro_content_get`. (Drafts aren't publicly readable, so
`distro_story_read` returns "Story not found" for an unpublished draft; use
`distro_content_get` / `distro_content_to_markdown` instead. For a published
story you can use `distro_story_read` with the URL.)
- To find a draft's `contentId`: `distro_content_list` with the right
`publicationId`, match the title.
**Why fresh matters:** the author is often editing the same draft in the
DistroVerse editor at the same time. Editing from a stale copy — or writing back
a cached full draft — can silently clobber their concurrent edits. Fetch
immediately before you review, and fetch again immediately before you apply.
**Report the status you actually see.** The `status` field in the fetch is the
truth. If Brad said he published the piece and the API returns `draft`, say so
before you start on commas — a publish that silently failed is a bigger problem
than anything in the copy. Same goes for a title or dek that doesn't match what he
thinks he saved.
### Draft-only check: does the slug still match the headline?
A story's `slug` is generated from whatever the headline was when the story was
first filed. Rewrite the hed — which happens constantly, and which this skill
itself often causes — and the slug keeps the old wording. Nobody notices, because
the slug isn't visible in the editor.
**While `status` is `draft`, the slug is free to change. Once the story is
published, changing it breaks any URL already shared.** So this is a check with a
closing window, and the window closes the moment Brad says "publish."
So: whenever the fetch returns `status: "draft"`, compare the `slug` to the
current `title`. If the slug clearly reflects an older headline, raise it as a
finding — low severity, near the end of the list, but before the apply step and
well before publication. Say plainly that it is cosmetic, that it only affects the
URL, and that it is free to change now and costly to change later.
Don't flag ordinary slug shortening (a slug is a trimmed, hyphenated version of a
hed and will never match it word for word). Flag it when the slug carries a
different claim than the hed does — a company name the headline dropped, a verb
the rewrite reversed, a framing that is no longer the story's.
If the story is already `published`, mention it only if Brad asks: the URL is out
in the world and a new slug is usually a worse trade than a stale one.
---
## Phase 1 — The copyedit pass
Read the whole piece and collect findings in five buckets, most severe first:
1. **Accuracy against the cited sources** — the story asserts something its own
linked sources don't support. This is the most valuable thing a copy editor
does, and no spell-check catches it. Open the sources the story cites and check
the load-bearing claims against them. Watch especially for:
- **mechanism errors** — what gets slashed, who pays whom, which token is
earned versus spent, what a protocol actually does;
- **relationship upgrades** — a story that says "bought," "rents" or "paid"
when the source only says "partnered." Announcements routinely cover barter,
credits, equity or unpriced deals;
- **scope creep** — one program described as if it were the whole company;
- **stretched attribution** — a clause sourced to "CoinMarketCap says" that
covers more or less than what CoinMarketCap actually said.
Quote the source's own wording in the finding so Brad can judge the gap himself.
2. **Clear errors** — spelling, grammar, subject-verb agreement, dropped or
garbled words, doubled words, broken/duplicated punctuation, broken links
(e.g., a headline pasted into an `href`). Unambiguous; these should be fixed.
3. **AP style + Distro house exceptions** (see checklist below).
4. **Judgment calls** — wordiness, redundancy, awkward phrasing, a dangling
participle, one word doing too much work across the piece, repeated sentence
openers, a subhead that doesn't match its section, headline/dek vs. body
mismatch. Suggest, don't insist; explain the why.
5. **Verbatim text — flag, don't change** — typos or quirks inside a direct
quote, a reproduced prompt, a tweet, an error message. Point them out
separately and note they appear verbatim; suggest the writer keep as-is, add
"[sic]," or add a note. The writer decides.
**Also check partial quotes for scope.** When the writer trimmed a quotation,
pull the original and ask whether the trim narrows or widens the claim.
"multi-chain deployment starting on Base" reads more Base-exclusive than the
full "multi-chain deployment starting on Base and other EVM networks." Flag it,
offer the full quote or an ellipsis, and let the writer decide. Trimming is
often the right editorial call — it should just be a decision rather than an
accident.
**Punctuation inside a quotation is the source's, not the house's.** House
style stops at the quotation mark. If the source used a serial comma and house
style drops it, the source's comma stands — silently "fixing" it alters a
direct quote. Flag it, note that it is verbatim, and let the writer decide.
### Style / spelling parameters
Distro follows **AP style** with a small set of **house exceptions**. House
exceptions always win where they conflict with AP.
**House exceptions (most important first):**
- **Dashes: use a spaced en dash ( – ), NOT an em dash.** This is the single most
important house rule. Do **not** flag a spaced en dash as an error, and do
**not** suggest converting en dashes to em dashes. A spaced *em* dash is the
deviation from house style.
- **Deks carry no subject-name prefix on original stories** (house style rule 8).
"Theoriq: The protocol is..." gets flagged. A source-attribution prefix on a
link post ("CoinDesk:") is correct and stays.
**AP items that come up most often in Distro copy:**
- **internet** — lowercase.
- **OK** — never "Ok," "okay," or "o.k."
- **longtime** — one word, no hyphen.
- **No Oxford/serial comma** — "finance and tech companies," not "finance, and
tech companies." Use the serial comma only to avoid confusion.
- **Numbers** — spell out one through nine; figures for 10 and up. Figures
regardless for ages, percentages, dollars, dimensions, measurements. Spell out
a number that starts a sentence. Designations ("subnet 4") take figures.
- **Percent** — "%" with a figure (e.g., "67%"); match whatever is consistent in
the piece.
- **Possessives** — singular proper name ending in s takes only an apostrophe
("Voorhees'," not "Voorhees's"). Standard "its" vs. "it's,"
"their/there/they're" checks.
- **Colons and semicolons go OUTSIDE closing quotation marks;** commas and
periods go inside.
- **"because" vs. "since"** — "because" for causation, "since" for the passage of
time. Flag only when it reads oddly.
- **Titles** — quotation marks for book/song/show/article titles, not italics;
publication names take no quotes.
- **Hyphenation consistency** — on-chain, off-chain, open-source, self-custodial,
co-founder, etc. Keep the piece internally consistent.
When in doubt on an AP point, say so rather than inventing a rule.
---
## Phase 2 — Present findings one-by-one
Do **not** hand over a grouped list. Open with the cleanest possible summary and a
count ("I found six things worth your eye"), then walk them individually:
- Label each: **"Finding N of M."**
- Quote the offending text so it's easy to locate.
- Name the bucket / rule in one line.
- Give the **exact suggested fix**, and an alternative wording if useful.
- Ask **keep / fix / reword?** and wait for the decision before the next finding.
**When a finding touches the headline or the dek, count the characters
programmatically** and report the real number for the current text and for every
option you offer (house style rule 9). Eyeballed counts are wrong often enough to
burn a finding and nearly ship a bad hed. If you realize a count you already gave
was wrong, say so in the same breath as the correction.
Track each decision (approved as-proposed, approved with custom wording, or
rejected). Note when something is an intentional stylistic choice (voice, informal
tone, deliberate repetition) and leave it alone rather than "correcting" it.
**Withdraw your own bad suggestions.** If a fix you proposed turns out to introduce
a problem — a claim the sources don't support, a word the writer already rejected
earlier in the session — say so and replace it rather than waiting to be caught. An
editor who defends a bad suggestion is worse than one who never made it.
If the user says they just want the flags and will edit themselves, stop after
this phase — don't apply anything.
---
## Phase 3 — Apply the approved edits in one surgical pass
After the last finding is decided:
1. **Re-fetch** the live content with `distro_content_get` (it may have changed
while you were reviewing).
2. Apply **only the approved changes** as targeted replacements within that fresh
content — change just the approved spots, leave everything else byte-for-byte
intact. Never send a cached full draft that could overwrite concurrent author
edits.
- Do the replacements with a script that asserts each `old` string matches
**exactly once** and aborts otherwise. A silent zero-match or double-match is
how an approved edit goes missing or lands twice.
- Then re-render the result as plain text and read it before writing. Splicing
around inline `<a>` tags routinely leaves a stray space before a comma or a
doubled space. Fix those silently — they're mechanical, not judgment calls.
3. Write back **once** with `distro_content_update` (`contentFormat: "html"`).
Only touch the `preview` or `title` fields if a finding changed them.
4. Confirm what changed and what you intentionally left alone (e.g., a comma the
user chose to keep). A short table of finding number and outcome reads well.
Note any mechanical fixes you made without asking.
Batching into one write — rather than editing as you go — means fewer writes, less
chance of clobbering the author's in-editor work, and a clean single update.
---
## Output format reminder
- Lead with "here's what I found" + a count.
- Most severe first: accuracy against sources, then clear errors, then AP/house
style, then judgment calls.
- Verbatim/quoted text: flag separately, never silently fixed.
- Close by noting what you checked that was clean, and offer the next step
(e.g., a headline/dek-vs-body check).
Keep it tight — this is a working editor's markup, not an essay.
---
*Scope note: this version focuses on the process (copyedit → one-by-one review →
apply at end) plus the core AP + house-style parameters. Richer style guidance and
additional house editorial rules can be layered in later.*
When to use
- You've drafted a story for any Distro newslode and want a correctness pass before publishing.
- You want the claims in your story checked against the sources the story itself links to.
- You want an AP-style check that already knows Distro's house exceptions.
- You want to decide each edit yourself rather than get a story back that's already been rewritten.
When not to use
- You want a full rewrite or a voice/tone makeover – that's a writing task, not a copy edit.
- You want to publish or post the story – use the relevant Distro publishing skill instead.
Feedback
This is v2.1. Edge cases or suggestions → reply or ping Brad.