| name | copyediting |
| description | Use when copyediting blog posts, articles, essays, or long-form writing where the author's voice must be preserved — flags spelling, grammar, and technical errors as fixes, raises stylistic and clarity questions as suggestions, and never rewrites the prose |
Copyediting
Overview
Copyediting is not rewriting. The author has a voice — contractions, em-dashes, sentence fragments, idiosyncratic word choices, a certain rhythm. Your job is to catch what's wrong, raise what's unclear, and leave what's distinctive alone.
Core principle: Preserve voice. Fix errors. Surface suggestions separately. Never substitute your own prose for the author's.
The Three Buckets
Every issue you find goes in exactly one bucket. Mixing them is the #1 copyediting failure mode.
| Bucket | What it is | What you do |
|---|
| Fix | Objective error — spelling, grammar, broken syntax, factual/technical mistake, broken link, inconsistent terminology | State the fix. Be direct. |
| Suggest | Judgment call — possible ambiguity, awkward phrasing, weak transition, missing context, structural issue | Raise it as a question. Author decides. |
| Leave alone | Voice marker — intentional fragment, sentence-starting "And/But/So", contractions, em-dashes, repetition for effect, informal register, unusual rhythm | Do nothing. Do not mention it. |
If you're not sure which bucket something belongs to, it goes in Suggest, not Fix.
House Style
These rules are non-negotiable for this blog. They override the "match the author's pattern" instinct. Treat violations as Fixes:
- Oxford comma is required. "red, white, and blue" — not "red, white and blue". Missing serial comma in any list of three or more items is a Fix.
- Em-dashes and en-dashes take spaces on both sides. "this — that" — not "this—that". Unspaced dash is a Fix.
Critical constraint on dash spacing: Only enforce spacing where the author has already used a dash. Do not convert commas, colons, parentheses, or hyphens into em-dashes to apply the rule. The author's choice of punctuation mark stands; only its spacing is house style. If they wrote a comma, leave it as a comma.
Voice Markers to Protect
These are NOT errors. Do not flag them, do not "fix" them, do not mention them:
- Contractions (it's, don't, you're) — even in technical writing
- Sentence fragments used for emphasis. Like this.
- Sentences starting with And, But, So, Or, Because — standard in modern prose
- Em-dash use — including doubled ones, even where a comma would do (the use is voice; spacing follows House Style above)
- Repetition when it's clearly rhythmic or emphatic
- Direct address ("you") in technical writing
- First person ("I think", "I've found")
- Parentheticals (even nested ones)
- One-word paragraphs. Yes.
- Informal connectors ("anyway", "look", "here's the thing")
- Idiosyncratic word choices — if the word is real and means what they meant, leave it
- Long sentences that work, and short sentences that punch
When in doubt, ask: would changing this make the piece sound more like a generic AI wrote it? If yes, leave it.
What Counts as a Fix
Only flag as Fix if it's objectively wrong:
- Spelling: misspellings, wrong homophone (their/there/they're, its/it's when wrong, affect/effect when wrong)
- Grammar: subject-verb disagreement, broken parallel structure, dangling modifiers that genuinely confuse meaning, wrong verb tense, pronoun reference errors
- Punctuation that changes meaning: missing apostrophe in possessives, comma splices that create ambiguity, mismatched quotes/parens/brackets
- House style violations: missing Oxford comma in a list of 3+, em-dash or en-dash without surrounding spaces (see House Style above)
- Typos: doubled words ("the the"), missing words, transposed letters
- Inconsistency: term spelled two ways (JavaScript vs Javascript), capitalization inconsistency within the piece, formatting inconsistency (code vs prose treatment of identifiers)
- Technical errors: wrong command syntax, broken code samples, factually incorrect claims about libraries/APIs/standards, wrong version numbers, broken links
- Broken structure: heading levels skipping (H2 → H4), malformed markdown, code fence language tags wrong
What Counts as a Suggestion
Raise as Suggest when something might be improved but the author's choice could be intentional:
- Sentence might be ambiguous — could be read two ways
- A term is introduced without definition that a reader might not know
- A transition feels abrupt
- An example would help illustrate a claim
- A section is much longer/shorter than others without obvious reason
- A claim could use a citation or link
- The opening doesn't hook, the ending trails off
- A passive construction obscures who did what
- A long sentence could split if the author wants
- A word might be stronger / more precise — offer the alternative as a question
- A cluster of AI-writing tells — buzzword metaphors ("vibrant tapestry", "a testament to"), an exact-three list trailing a participial clause (", ensuring..."), "wasn't just X, it was Y", a formulaic closer ("In conclusion, the future looks bright"). Name the cluster, quote the spans, ask whether it's intentional — the write-better-prose skill's ai-tells.md is the catalog. One tell alone is noise; a cluster is worth raising even when an aside plays it for irony. Never rewrite the passage yourself.
Frame as questions or options, not instructions: "The phrase 'handle this' is vague — do you mean retry, log, or escalate?" not "Change 'handle this' to 'retry'."
Process
- Read the whole piece first. Get the voice. Don't mark anything yet.
- Second pass: mark only objective errors (Fixes).
- Third pass: note suggestions, questioning whether each is really a voice marker in disguise.
- Output the report in the format below.
- Do not produce a rewritten version of the piece unless the author explicitly asks.
Output Format
Use this structure. Reference by quoted phrase + location (heading or paragraph number), not by rewriting:
## Fixes
1. **§Introduction, ¶2** — "it's effect on performance" → "its effect on performance" (possessive, not contraction)
2. **§Setup, code block** — `npm intall` → `npm install` (typo)
3. **§Results, ¶4** — "the the results show" → "the results show" (doubled word)
4. **Throughout** — "JavaScript" and "Javascript" used interchangeably. Pick one. Standard is "JavaScript".
## Suggestions
1. **§Introduction, ¶1** — "handle the edge cases" — which edge cases specifically? A one-line example would ground this for readers who haven't hit them.
2. **§Approach, ¶3** — Long sentence (62 words) covering three ideas. Works as-is, but splitting after "...and then we measured the result" would let each idea breathe. Your call.
3. **§Conclusion** — The piece builds to a strong technical point but the closing paragraph restates the intro. Consider ending on the implication instead.
## Questions
1. **§Benchmarks, ¶2** — "10x faster than the baseline" — faster on what dimension (latency, throughput, cold start)? Worth specifying.
2. **§Setup** — Is the Node version requirement (18+) intentional, or does this work on 16?
Three sections, in this order. If a section is empty, write "None." — don't omit it. Don't invent issues to fill sections.
Technical Blog Specifics
For technical content, also verify:
- Code samples run as written (mentally execute them; flag anything that won't)
- Command flags exist and do what's claimed
- Library APIs match current versions — if author says "as of v3.2", check that's plausible
- Terminology consistency with the ecosystem (e.g., "props" not "properties" in React context)
- Acronyms expanded on first use unless audience clearly knows them (TCP, HTTP usually fine; less common ones — expand)
- Numbers and units — "10ms" vs "10 ms" — match the author's pattern within the piece
- Code/prose boundary — identifiers in
backticks, consistent throughout
Flag technical errors as Fixes (they're objective). Flag terminology preferences as Suggestions.
Common Mistakes
| Mistake | What goes wrong | Fix |
|---|
| Rewriting a sentence "to be clearer" | Author's voice is gone | Quote the original, raise a question, let them decide |
| Flagging contractions as informal | The blog is informal on purpose | Contractions are voice. Leave them. |
| "Fixing" sentences that start with "But" | This is standard modern English | Leave alone |
| Removing an Oxford comma | Violates house style | Oxford comma is required — flag missing ones as Fixes, never remove existing ones |
| Converting a comma to an em-dash to apply spacing rule | You're imposing punctuation, not enforcing house style | Only enforce dash spacing where the author already used a dash. Don't introduce new ones. |
| Listing 40 suggestions for a 600-word post | Author can't act on it, will ignore all | Prioritize. 5-10 high-value suggestions max. |
| Marking awkward phrasing as a Fix | It's a judgment call, not an error | Move it to Suggestions, frame as a question |
| Producing a "cleaned-up version" of the piece | Author wanted edits, not a ghost-write | Output the report only. Do not paste a revised draft. |
| Missing the technical error while polishing the prose | Wrong command, wrong API — the error that matters most | Verify technical claims FIRST, prose second |
| "The flow could be better" with no specifics | Not actionable | Either name the specific transition or drop the note |
| Silently correcting in your head | Author can't learn or push back | Every change must be visible in the report |
Red Flags — Stop and Reconsider
If you catch yourself doing any of these, you've drifted from copyediting into rewriting:
- Drafting a "better version" of a paragraph
- Removing a word because you wouldn't use it
- Combining or splitting sentences for "flow" without a specific clarity reason
- Changing "I think" to "It appears that"
- Replacing an em-dash with a comma (or vice-versa — punctuation choice is the author's; only spacing is house style)
- Removing an Oxford comma the author wrote
- Adding an em-dash where the author wrote a comma, "to apply the spacing rule"
- Thinking "this would read better if..."
All of these mean: stop, revert, and ask whether the original was actually wrong or just different from how you'd write it.
Scope of the Pass
Default to a light copyedit: errors + meaningful suggestions only. Do not:
- Restructure the piece
- Recommend cutting sections unless they're factually wrong or redundant
- Propose a different argument or angle
- Suggest a different title unless the current one misrepresents the content
If you think the piece needs structural work, say so at the top in one sentence and ask the author whether they want a structural review — don't unilaterally do one.
If the author explicitly asks for a rewrite — "de-slop this," "humanize it," "remove the AI-isms and rewrite," "make it sound less like AI" — that's not a copyedit. Switch to the write-better-prose skill, which rewrites while preserving voice; this skill's job ends at the report.
Quick Reference
- Read whole piece before marking anything
- Three buckets only: Fix, Suggest, Leave alone
- House style: Oxford comma required; dashes get spaces on both sides (only where author already used a dash)
- Voice markers → Leave alone (contractions, fragments, em-dashes, And/But starts)
- Objective errors → Fix (spelling, grammar, typos, technical wrongness)
- Judgment calls → Suggest as questions, not commands
- Output is a report, not a rewrite
- Quote the phrase, locate it, propose the change — don't paste a revised draft
- Cap suggestions at ~10; prioritize the ones that matter
