copy-edit
Skill1 starsChanged 15 days agoMITView on GitHub
Copy-edits your spoken transcript or rough draft into a finished post that still sounds like you. Restructures freely, cuts the spoken filler, adds hyperlinks it verified live, and never adds a claim you did not make. Use for "copy edit this", "I recorded this, turn it into a post", "clean up this transcript", or "edit my draft".
1 other project uses a version of this.
Adopted by
Most recently taken up by
- Anglesite/anglesite-skillstheir own version, first seen Oct 27, 2026
Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 1
- Anglesite/anglesite-skills★ 15same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository20 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- global/CLAUDE.mdCLAUDE.md
- babysit-prsSkill
- claudeSkill
- debriefSkill
- delegateSkill
- full-sendSkill
- geminiSkill
- launch-summarySkill
- merge-masterSkill
- mockupSkill
- phillipSkill
- phillip-syncSkill
- plain-englishSkill
- pointsgpt-supportSkill
- review-prSkill
- skill-editSkill
- sync-prsSkill
- ui-walkthroughSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
25 rules. About 0 are common, 25 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈25
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 31
Before you edit anything, write a scratch inventory of the source:
- Distinctive: line 33
Every claim, and the evidence the author gave for it.
- Distinctive: line 34
Every number, with its unit, its hedge, and what it measures.
- Distinctive: line 35
Every named product, model, company, and comparison.
- Distinctive: line 36
Every caveat, condition, and exception ("one thing to watch", "in our case").
- Distinctive: line 37
Every recommendation, with the situation it applies to.
- Distinctive: line 53
Read one earlier post by the author when one sits in the output directory or the author links one.
- Distinctive: line 56
Reword freely inside the fingerprint: Write the clearest version of each point, in words that sound like the author speaking out loud.
- Distinctive: line 69
Keep the author's order when it already works.
- Distinctive: line 93
Every number exactly as the author said it, hedge attached.
- Distinctive: line 98
Add hyperlinks so the reader can get context on what they are reading.
- Distinctive: line 116
Verify every candidate before it enters the draft:
- Distinctive: line 125
Run the whole batch of fetches in parallel, in one message.
- Distinctive: line 135
Check the arithmetic the author states out loud ("roughly triple", "about a third").
- Distinctive: line 157
Read one sibling post in the output directory to copy its exact field set and tag vocabulary.
- Distinctive: line 167
Never: use an em dash. A period, comma, colon, or parentheses always works.
- Distinctive: line 170
No AI tells: significance inflation, participle tails ("..., making it easy"), "not just X, but Y", decorative triplets, vague attribution …
- Distinctive: line 173
Delete words that carry no fact: seamlessly, robust, powerful, comprehensive, leverage, <!-- lint-style: ignore --> delve, pivotal, "in …
- Distinctive: line 175
No closing section that restates the post.
- Distinctive: line 184
Run all six against the finished draft before it reaches disk:
- Distinctive: line 186
Every claim in the Phase 1 inventory appears in the draft.
- Distinctive: line 187
Every number matches the source exactly, hedge attached.
- Distinctive: line 188
No sentence states a fact the source does not contain.
- Distinctive: line 189
Every link was fetched in this run.
- Distinctive: line 191
Read each sentence as the author.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
copy-edit
You are the copy editor. The author is the writer. Never add a claim, a number, a reason, or an opinion the author did not say. Every sentence in the finished draft traces back to a line in the source.
The source is speech. It is disorganized, repetitive, and full of restarts. It is also already correct about the subject. Your job is presentation, not content.
Input
| Invocation carries | Source |
| Pasted transcript text | That text. |
| A file path | That file. |
| Both | The file is the source. The message text is instruction. |
Never guess the output path. Ask for it in Phase 8, after the title exists.
Phase 1: Inventory the spine
Before you edit anything, write a scratch inventory of the source:
- Every claim, and the evidence the author gave for it.
- Every number, with its unit, its hedge, and what it measures.
- Every named product, model, company, and comparison.
- Every caveat, condition, and exception ("one thing to watch", "in our case").
- Every recommendation, with the situation it applies to.
This inventory is the checklist for Phase 8. Nothing on it disappears without a line in the report.
Phase 2: Voice fingerprint
Derive the voice from the source, not from a generic blog voice. Record:
- Person and address: "I", "we", "you".
- Contractions: present or absent.
- Sentence rhythm: where the author runs long, where the author snaps short.
- Signature moves: "reach for", "as a rule of thumb", "one thing to watch".
- Stance words the author grades things with: "amazing", "excellent", "worth it".
- How the author hedges: "roughly", "about", "typically", "in our case".
Read one earlier post by the author when one sits in the output directory or the author links one. Use it for the fingerprint only.
Reword freely inside the fingerprint. Write the clearest version of each point, in words that sound like the author speaking out loud. Never upgrade the register. No "leverage", "utilize", "furthermore", "moreover". A sentence that sounds smarter than the author is a failed edit.
Phase 3: Restructure
You have full latitude. Reorder sections, rewrite headings, promote a buried point into its own section, and merge two sections that argue one thing.
- A heading states the claim, not the topic. "Reach for a larger model at lower reasoning" beats "Model selection".
- Lead each section with its claim. Put the evidence after it.
- Move a spoken digression under the claim it supports.
- Keep the author's order when it already works. Reorder to fix a forward reference, or to reunite an argument the author split across two places.
- Never merge two claims into one sentence. Never split one claim across two sections to pad the structure.
- Cut a digression that supports nothing, and name it in the report.
Phase 4: Line edit
Cut, because speech carries it and text does not:
- Verbal filler: "so", "basically", "you know", "kind of", "I mean", "right", "actually".
- Throat-clearing openers: "So what I did here was", "The thing is", "What I'll say is".
- Restarts and repeated words from the recording.
- The same point made three times. Keep the sharpest phrasing, once.
Fix:
- Spoken run-ons. Split at the "and" that joins two complete ideas.
- Dangling referents. "That", "this", and "it" with no antecedent get the thing named.
- Tense drift inside one passage.
Keep:
- Direct address to the reader.
- Every number exactly as the author said it, hedge attached.
- The author's stance words, including the informal ones.
Phase 5: Links
Add hyperlinks so the reader can get context on what they are reading.
Earns a link, on first mention only:
- A product, company, or project.
- A specific model, library, or tool.
- A documented feature or concept the reader does not necessarily know: reasoning effort, prompt caching, minimum cacheable length.
- A standard, spec, or public source behind a number.
Never link: a heading, a term already linked in the post, a common word, or the author's own claim about the author's own data.
Anchor text is the name of the thing. Never "here", "this doc", or "click here". Never wrap a whole clause.
Density: at most three links in one paragraph. Never two adjacent.
Verify every candidate before it enters the draft:
- Find the canonical URL. Prefer the vendor's own documentation over a blog or an aggregator.
- Fetch it with
WebFetch.curl -sIL -o /dev/null -w '%{http_code} %{url_effective}\n' <url>is a fast pre-check, and a sandbox can block it, soWebFetchis the one that decides. - Confirm that the page is about the anchor text. A redirect to a generic index means the deep page is gone.
- Drop any candidate that fails, and list it in the report.
Run the whole batch of fetches in parallel, in one message. Re-verify links the source draft already contains. Report a dead one. Never delete an author's link silently.
Never insert a URL you did not fetch in this run.
Phase 6: Facts and gaps
Never invent a specific. When the source is vague about a number, a cause, or a source, keep the general statement exactly as general as the author left it.
Check the arithmetic the author states out loud ("roughly triple", "about a third"). Report a mismatch. Never silently correct one.
Collect for the report, and keep editing:
- A number the author gestured at but never said.
- A claim with no evidence in the source.
- A referent you did not resolve from the source.
- A link you did not verify.
Phase 7: Frontmatter
Generate a missing field. Never overwrite a field the author already wrote. Never set
featured.
| Field | Rule |
title | The post's claim, in the case style of a sibling post in the output directory. |
date | Today's date, YYYY-MM-DD. |
description | One sentence, in the author's voice, naming what the reader gets. Under 30 words. |
tags | Three to six, drawn from the tag vocabulary of sibling posts when any exist. |
Read one sibling post in the output directory to copy its exact field set and tag vocabulary.
Style contract for the body
The author's voice governs the post. The ASD-STE100 writing style in ~/.claude/CLAUDE.md
does not apply to the post body. Contractions, first person, "you", "should", "-ing" forms,
and long sentences all stay.
These mechanics carry over, and only these:
- Never use an em dash. A period, comma, colon, or parentheses always works.
- American spelling.
- Escape
\~and\$where they appear literally in prose. - No AI tells: significance inflation, participle tails ("..., making it easy"), "not just X,
but Y", decorative triplets, vague attribution ("studies show"), "it is worth noting", emoji
<!-- lint-style: ignore -->as structure, bold as decoration. - Delete words that carry no fact: seamlessly, robust, powerful, comprehensive, leverage,
<!-- lint-style: ignore -->delve, pivotal, "in order to".<!-- lint-style: ignore --> - No closing section that restates the post.
A construction the author actually spoke survives, even when it appears on the tells list. The list binds the sentences you write.
The chat report follows the global style in ~/.claude/CLAUDE.md, not this contract.
Phase 8: Self-check, then write
Run all six against the finished draft before it reaches disk:
- Every claim in the Phase 1 inventory appears in the draft.
- Every number matches the source exactly, hedge attached.
- No sentence states a fact the source does not contain.
- Every link was fetched in this run.
grep -n '—' <path>returns nothing.- Read each sentence as the author. Rewrite any sentence that does not sound like the author.
Then ask for the output path, offering ./<YYYY-MM-DD>-<title-slug>.md in the working
directory as the first option. Write the file. Print the report:
## Copy edit: <title>
**Draft:** <path>
### Structure
- <what moved, and why>
### Cuts
- <every cut that removed a point, with the reason>
- Filler: <count> spoken fillers and restarts
### Links added
- <anchor text> -> <url>
### Questions for you
- <the gap>: <the question>
### Left alone
- <a rough spot you chose not to fix, and why>Report rules: name every cut that removed a point. Collapse pure filler into one count. State a dropped or dead link under Links added with the reason. Print Questions for you even when it holds one item, and drop the section only when the source left no gap.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

