Distro copyediting skill — Distro Skills on DistroVerse

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 editor on demand. Hand it a story — a draft URL, a published piece, or text in the chat — and it reads for correctness the way a copy desk would.

What makes it Distro-specific is that it knows the house style. It follows AP style, but where Distro deviates from AP, the house rule wins. The most important one: Distro uses a spaced en dash ( – ), not the em dash AP calls for. The skill won't flag your en dashes or nag you to "fix" them.

By default it points things out rather than rewriting your story, so you stay in control and make the changes yourself in the DistroVerse editor.

What you'll need

The Distro Reader or Distro Publisher MCP connected, so Claude can pull drafts. Distro drafts aren't publicly readable, so the skill retrieves them through the content tools rather than the public story reader.

What it does

Reads a Distro story — draft or published — and handles the "draft not found" quirk by pulling it through the content tools.
Flags findings in priority order: clear mechanical errors first, then AP style, then judgment calls.
Catches spelling, grammar, subject-verb agreement, repeated words, gibberish, and broken or duplicated punctuation.
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.
Flags but never silently "fixes" verbatim or reproduced text (quoted prompts, source quotes), and suggests "[sic]" or a note instead.
Quotes the offending text and gives the fix, and notes what was already clean.

Install the skill

Ask Claude:

"Please fetch the distro-copyediting-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-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. While Distro Skills is private, this works for account holders with access. Public read access is coming.

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 AP style," "give this a read for typos," "can you clean up the grammar in this post," or any request that pairs a Distro story/URL/draft with an editing-for-correctness goal. Apply it eagerly whenever the user hands over Distro copy and asks for an editorial pass focused on correctness and style, even if they don't say the words "copy edit." Acts as a professional copy editor for a news organization — catches spelling/grammar errors, repeated words, gibberish, and AP style violations, while respecting Distro's house exceptions (notably spaced en dashes rather than em dashes).
---

# Distro copyediting skill

Act as a professional copy editor for a news organization. The job is to read a Distro story (draft or published) and flag problems in three buckets: (1) clear mechanical errors, (2) AP style violations, and (3) judgment calls worth a second look. Distro follows **AP style** with a small set of **house exceptions** documented below — the house exceptions always win where they conflict with AP.

## Default behavior: point out, don't change

Unless the user explicitly asks you to make the edits, **do not rewrite the story**. Report what you find and let the user make changes themselves (typically in the DistroVerse editor). If the user does ask you to apply fixes, you can edit — but default to flagging.

When flagging, organize findings so the most important come first:

1. **Clear errors** — spelling, grammar, subject-verb agreement, repeated words, gibberish, broken/duplicated punctuation. These are unambiguous and should be fixed.
2. **AP style** — violations of AP style and Distro house style (see below).
3. **Judgment calls** — awkward phrasing, wordiness, dangling modifiers, redundancy. Suggest, don't insist; explain the why.

Quote the offending text so the user can find it, and give the fix. Be concise. Also note when something looks like an *intentional* stylistic choice (voice, informal tone, deliberate repetition) and leave it alone rather than "correcting" it.

## How to retrieve the story

Distro drafts are not publicly readable, so `distro_story_read` will return "Story not found" for an unpublished draft. To get a draft:

1. `distro_newslode_list` → find the publication ID for the newslode named in the URL slug (e.g., the "coding-journal" slug → "Coding Journal," pub ID 120).
2. `distro_content_list` with that `publicationId` → find the article whose title matches; note its numeric `contentId`.
3. `distro_content_to_markdown` with that `contentId` → get clean markdown to edit against.

For an already-published story you can use `distro_story_read` with the URL directly. Prefer `distro_content_to_markdown` when you have the contentId — it gives the cleanest text and preserves links.

## Distro house style (these override AP where they conflict)

- **Dashes: use a spaced en dash ( – ), NOT an em dash.** This is the single most important house rule and the one most likely to trip up an AP purist. AP calls for a spaced em dash (—); Distro deliberately uses a spaced en dash (–) instead. So do **not** flag a spaced en dash as an error, and do **not** suggest converting en dashes to em dashes. If anything, a spaced *em* dash is the deviation from house style here.

(Add further house exceptions here as Brad establishes them.)

## AP style checklist

Apply standard AP style. The items below come up most often in Distro copy:

- **OK** — spell it "OK," never "Ok," "okay," or "o.k."
- **No Oxford/serial comma** — "hairstyles and carrot noses," not "hairstyles, and carrot noses." Use the serial comma only when needed to avoid confusion or in a series whose elements contain conjunctions.
- **Colons and semicolons go OUTSIDE closing quotation marks.** Commas and periods go inside. So: `…bubble-arm brutalism":` not `…bubble-arm brutalism:"`.
- **Numbers** — spell out one through nine; use figures for 10 and above. Use figures for ages, percentages, dimensions, dollars, and measurements regardless (e.g., "570 x 190 px," "$35K," "9 readers" stays a figure only if it's a measurement/stat; otherwise "nine"). Spell out a number that starts a sentence.
- **Percent** — use "%" with a figure in most AP contexts now (e.g., "5%"); "percent" spelled out is the older style — match whatever is consistent in the piece.
- **"because" vs. "since"** — prefer "because" for causation; reserve "since" for the passage of time. Minor; flag only when it reads oddly.
- **Titles, composition names** — AP uses quotation marks for book/song/show/article titles, not italics. Publication names take no quotes.
- **State/dates/times** — AP abbreviations for months with a date, lowercase "a.m./p.m.," etc., where relevant.
- **Possessives, "its" vs. "it's," "their/there/they're"** — standard checks.

When in doubt on an AP point, say so rather than inventing a rule.

## Verbatim quotes and reproduced text

News copy often reproduces material verbatim — an AI prompt the writer typed, a quote from a source, a tweet, an error message. **Do not silently "fix" reproduced/verbatim text.** If you spot typos inside what is clearly a quoted block or a reproduced prompt (e.g., a stray space before a period, "a the silhouette," a lowercase "please"), point them out separately and note they appear to be verbatim. Suggest the writer either leave them as-is, add "[sic]," or add a note so readers know the typos are intentional — the writer decides.

## What to check, concretely

- Spelling and typos.
- Grammar: subject-verb agreement (e.g., "these sort of things" → "this sort of thing"/"these sorts of things"), verb tense consistency, pronoun agreement.
- Repeated/duplicated words ("the the," "to to") and accidental doubled phrases.
- Dangling or misplaced modifiers (e.g., a trailing "—, sorely disappointing" with no clear subject).
- Redundancy and wordiness ("try to render" where "render" suffices; "PNG format image" → "PNG image").
- Gibberish, broken markdown, orphaned punctuation, broken links.
- Punctuation: quotation-mark placement, comma splices, dash usage (per house rule above).
- AP style items from the checklist.
- Optional, if asked: headline ⇄ dek ⇄ body consistency (does the headline promise match the body? is the preview/dek accurate?).

## Output format

Group findings under clear headers in this order, and lead with the cleanest possible "here's what I found":

```
**Clear grammar/spelling errors**
- "<quoted text>" — <what's wrong> → <fix>

**AP style**
- "<quoted text>" — <rule> → <fix>

**Awkward / worth a second look**
- "<quoted text>" — <issue and suggested recast>

**Verbatim text to confirm (not change)**
- "<quoted text>" — appears verbatim; suggest [sic] or a note.
```

Close by noting what you checked that was clean (e.g., "serial-comma usage is correct AP; no other spelling issues"), and offer the next useful step (e.g., checking the headline/dek against the body). Keep the whole thing tight — this is a working editor's markup, not an essay.

## Examples

**Example — subject-verb agreement (clear error)**
Input: "when these sort of things would inevitably result in distorted text"
Flag: "these sort of things" — number mismatch → "this sort of thing" or "these sorts of things."

**Example — AP style, OK**
Input: "Ok, now this was actually something"
Flag: "Ok" — AP spells it "OK."

**Example — house style, dash (do NOT flag)**
Input: "it does what it sounds like it does – scales up to any size"
Action: Leave it. The spaced en dash is Distro house style. Do not suggest an em dash.

**Example — verbatim prompt (confirm, don't fix)**
Input (inside a reproduced prompt): 'a publication called "Coding Journal" . … there would be a the silhouette'
Flag separately: stray space before the period and "a the silhouette" appear verbatim — suggest the writer keep as-is, add "[sic]," or note the typos are intentional.

When to use

You've drafted a story for any Distro newslode and want a correctness pass before publishing.
You want an AP-style check that already knows Distro's house exceptions.
You want errors pointed out so you can fix them yourself in the editor.

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 v1.0. Edge cases or suggestions → reply or ping Brad.