agentleFS
mcovillemcoville/Novel-Editing-Automation/skills/proofread/SKILL.md

proofread

Skill1 starsChanged 25 days agoMITView on GitHub

Proofread a fiction manuscript or a formatted proof — the final pass before publication. Catches typographical errors, dropped and duplicated words, punctuation and spacing slips, lost formatting, conversion damage between the edited manuscript and the typeset file, and front/back matter problems, without making new editorial decisions. Produces an errata list for the typesetter, a query list for anything needing a decision, and document checks. Use when the author asks for a proofread, final proof, last-pass check, manuscript check before formatting, ebook or print proof check, or a correction list before publishing.

26 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use humanize, deploy and 2 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • eherrerosjSkill

    humanize

    Remove signs of AI-generated writing from text. Use when editing or reviewing text to make it sound more natural and human-written. Based on Wikipedia's comprehensive 'Signs of AI writing' guide. Detects and fixes patterns including: inflated symbolism, promotional language, superficial -ing analyses, vague attributions, em dash overuse, rule of three, AI vocabulary words, negative parallelisms, and excessive conjunctive phrases. Triggers on: 'humanize', 'make this sound human', 'remove AI writing', 'de-AI', 'sound more natural', 'less robotic', 'too AI-sounding', or when reviewing text that reads like AI output.

    Also in 3 projects that use this

  • VercelSkill

    deploy

    Deploy applications to Vercel. Use when the user says "deploy", "deploy to Vercel", "push to production", "deploy my app", or "go live".

    Also in 3 projects that use this

  • Microsoft AzureSkill

    verify

    End-to-end app testing pipeline for browser-based web apps on cloud browsers via Azure Playwright Workspaces: verify the live app, author tests for working flows, heal failing tests, then re-run with video and produce one consolidated report. Three phases (app verification, test authoring, test healing) plus a scoped final sanity run; each phase emits a sub-report. Use when asked to "verify my app", "make sure my app works and has good test coverage", "do a full QA pass", "add tests where I'm missing coverage", "fix failing tests and add new ones", "smoke test before deploy", "QA my deployment", or any combined verify-and-test ask. Requires Azure CLI (`az login`) and a Playwright Workspace resource ID — bootstraps configs on first invocation. Browser-based web apps with Playwright only — not for unit/API tests, native mobile/desktop, load/perf, or full accessibility audits.

    Also in 3 projects that use this

  • SentrySkill

    review

    Fixture review skill.

    Also in 3 projects that use this

The file

Show its rules and text

We split this skill into the rules it gives an agent

15 rules. 0 are common, 6 are distinctive, and 9 are very specific to this project.

  • 0

    Common

    Most of the 20 edited versions we read keep these.

  • 6

    Distinctive

    This author's own choices. Worth a look.

  • 9

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    If you can't, at minimum run this pass in a different session or a different model from the one that copyedited.

    line 21
  2. Distinctive:

    The style sheet is law: Every existing style decision stands, even the ones you would not have made.

    line 27
  3. Very specific:

    Never rewrite a sentence: If the prose is poor, that is not a typo — flag it for line-edit and move on.

    line 30
  4. Distinctive:

    Work the text, not your memory of it: Do not skip a passage because a prior pass covered it.

    line 32
  5. Distinctive:

    Never invent a second layout.

    line 59
  6. Very specific:

    Verify the gate: If copyedit/queries.md has open queries, stop.

    line 81
  7. Distinctive:

    Read the style sheet completely, including the Do Not Change list.

    line 89
  8. Very specific:

    Run the pattern checks in references/proofreading-checks.md.

    line 96
  9. Very specific:

    Only when a formatted artifact exists.

    line 104
  10. Very specific:

    Read the text with one category of error in mind per pass, not everything at once — the technique in references/reading-techniques.md.

    line 110
  11. Distinctive:

    Do not read for story. Do not stop to admire or fix prose.

    line 112
  12. Very specific:

    Write errata.md — numbered corrections, located, with original and corrected text.

    line 120
  13. Very specific:

    Write queries.md — anything needing a decision.

    line 121
  14. Very specific:

    Write checks.md — each check passed, failed, or not applicable.

    line 122
  15. Very specific:

    Write summary.md from assets/templates/summary.md.

    line 123

“Common” is measured: kept by at least 6 in 10 of the 20 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Proofread

The last pass. Find what is still wrong and report it — without making new editorial decisions.

Scope: Typographical errors, dropped and duplicated words and lines, punctuation and spacing slips, lost or altered formatting, comparison damage between the edited text and the formatted file, consistency with the existing style sheet, and front and back matter completeness. Not prose improvement (line-edit); not grammar or style change (copyedit); not structure (developmental-edit).

Definition of done: the author can hand the errata list to a typesetter and know exactly what to change, where to change it, and why — with every remaining judgment call separated into queries, and a second-pass collation confirming the corrections landed.

Read This Before Using the Skill

Reading for meaning is exactly what hides typos. A language model repairs teh, form/from, and a doubled the as it goes, because it reads intent, not letters. Treat this skill as a mechanically reliable proofreader — systematic pattern searches, source comparison, category-by-category sweeps — and not as a substitute for a human final reader.

Practical consequences:

  • For the pass before publication, use a human proofreader if you can.
  • If you can't, at minimum run this pass in a different session or a different model from the one that copyedited. A proofreader who shares the copyeditor's blind spots is not a fresh reader.
  • Expect plausible-word errors to survive — a missing article, a wrong-but-grammatical preposition, a swapped homophone in an idiomatic phrase. Say so in the report rather than implying the text is clean.

Non-negotiables

  1. No new editorial decisions. The copyedit is finished. You correct; you do not improve.
  2. The style sheet is law. Every existing style decision stands, even the ones you would not have made. A change that contradicts it is a query, not a correction.
  3. Text must be frozen. Proofreading a file that is still being edited produces errata for text that no longer exists. Confirm the freeze, and re-proof anything that changed afterwards.
  4. Three buckets only: a mechanical correction, a query, or a re-edit request routed upstream. Nothing else.
  5. Never rewrite a sentence. If the prose is poor, that is not a typo — flag it for line-edit and move on.
  6. Nothing is changed silently in the source. Corrections go to the errata list and the annotated proof.
  7. Work the text, not your memory of it. Do not skip a passage because a prior pass covered it.

Inputs

  • The manuscript or formatted proof files
  • Required: the copyedit/style-sheet.md, and copyedit/clean/ or copyedit/tracked/ — the authoritative edited text
  • Optional: line-edit/, editorial-review/, characters/*.md, MANUSCRIPT.md, ORDER.md, chapters.json, chapter properties (assets/templates/chapter-note.md)
  • Optional: the formatted artifact — EPUB, PDF, print interior, or the author's exported .docx
  • Pass type: manuscript proof (default), proof against source, or final proof (collation)
  • Medium: manuscript, ebook, or print

Chapter properties. If chapter files carry YAML front matter (template: assets/templates/chapter-note.md), read it as author intent, not prose: never number it as a paragraph or quote it as text. type and chapter override filename classification and ordering; canon: false excludes a chapter; revision_stage below copyedited means the file is not ready — stop. A property that contradicts the text is a query, not a correction. Unknown properties are ignored, and properties are never written back to the source.

Output Contract

<project_folder>/proofread/
├── metadata.md
├── status.json
├── errata.md
├── queries.md
├── checks.md
├── summary.md
└── proofs/
    └── archive/

Never invent a second layout.

  • errata.md is the typesetter hand-off: numbered, located, and unambiguous.
  • queries.md holds anything requiring a decision, in the same format as copyedit/queries.md.
  • checks.md records the document-level and production checks, pass or fail.
  • proofs/ receives the annotated proof copies.

Pass Types

PassComparesCatchesRun
Manuscript proofFinal text against the style sheetTypos, dropped/duplicated words, punctuation, spacing, formatting slipsAfter copyedit
Proof against sourceFormatted file against the edited manuscriptConversion damage: lost text, broken markup, lost italics, wrong quote or dash characters, missing diacriticsAfter formatting
Final proof (collation)Corrected proof against the errata listWhether corrections landed, and what the corrections brokeAfter corrections

The third pass is not optional in print or ebook work. Corrections introduce errors; if nobody checks them, the last pass is the one that made things worse.

Workflow

0. Pre-flight

  1. Verify the freeze. Compare the source last-modified times against the copyedit completion. If anything changed, say so and confirm before proceeding.
  2. Verify the gate. If copyedit/queries.md has open queries, stop. Proofreading text that is about to change is wasted work.
  3. Identify the pass type and medium.
  4. Load and read copyedit/style-sheet.md — every answer you need about style is in it.
  5. Report the manifest and confirm scope.
  6. Validate ORDER.md / chapters.json if present (missing files, gaps, unlisted files). If both exist and disagree, ask which is authoritative.

1. Calibration

  1. Read the style sheet completely, including the Do Not Change list. That list is your protection against "correcting" the author's deliberate choices.
  2. Note what is not in the sheet. Anything the sheet does not settle is a query, not a decision.
  3. Identify the recurring search targets: character names, invented terms, place names, numerals conventions, dash and ellipsis style, quote style.
  4. Present your understanding of the conventions in a few lines and let the author correct you before you start.

2. Mechanical Sweep

Run the pattern checks in references/proofreading-checks.md. This is the part this skill does most reliably — exhaustive, systematic, and independent of whether you notice anything while reading.

Doubled words and punctuation, unbalanced quotation marks, mixed straight and curly quotes, double spaces, space before punctuation, missing space after punctuation, hyphen used where an en dash belongs, ellipsis inconsistency, stray [TK] and placeholders, chapter numbering sequence, repeated sentences and paragraphs.

Record every hit with a locator. These are almost always mechanical corrections.

3. Proof Against Source

Only when a formatted artifact exists. Compare it against the authoritative edited text, paragraph by paragraph, using references/conversion-errors.md.

This is the highest-value pass in the whole skill: text loss, scrambled paragraphs, dropped italics, missing diacritics, and substituted quote characters are invisible to a read-through but obvious in a comparison.

4. Read-Through Passes

Read the text with one category of error in mind per pass, not everything at once — the technique in references/reading-techniques.md. A pass for dropped words, a pass for punctuation, a pass for names and numbers.

Do not read for story. Do not stop to admire or fix prose. Every improvement that occurs to you goes in the re-edit requests, not into the errata.

5. Document and Production Checks

Work references/proofreading-checks.md: table of contents against actual chapter titles, chapter numbering, running heads and folios (print), chapter opener consistency, front matter, back matter, copyright page, ISBN, dedication, "also by" list, glossary cross-references, and ebook navigation, links, and metadata.

6. Collate and Report

  1. Write errata.md — numbered corrections, located, with original and corrected text.
  2. Write queries.md — anything needing a decision.
  3. Write checks.md — each check passed, failed, or not applicable.
  4. Write summary.md from assets/templates/summary.md.
  5. On a final proof pass, mark each errata item Landing / Not landing / Broke something else.
  6. Update status.json.

Errata Classes

ClassMeaningWhere
CorrectionUnambiguous error, mechanical fixerrata.md
QueryNeeds a decision; the sheet is silent or the intent is unclearqueries.md
Re-edit requestThe prose needs rewriting, not correctingerrata.md as a flagged item, routed to line-edit
Non-issueChecked and clearchecks.md

An errata item that requires judgment is not an errata item. Move it.

Key References (load on demand)

NeedFile
Scope, pass types, freeze and gate rules, collationreferences/proofreading-scope.md
Text, document, production, ebook, and print checklistsreferences/proofreading-checks.md
Comparing a formatted proof against the sourcereferences/conversion-errors.md
How to actually catch typos: targeted passes, fresh eyesreferences/reading-techniques.md

Templates (copy, then fill)

Outputs — these belong in proofread/.

OutputTemplate
metadata.mdassets/templates/metadata.md
status.jsonassets/templates/status.json
errata.mdassets/templates/errata.md
queries.mdassets/templates/queries.md
checks.mdassets/templates/checks.md
summary.mdassets/templates/summary.md

Author input files — these belong in the manuscript folder, alongside the chapter files. All are optional.

FileTemplate
MANUSCRIPT.mdassets/templates/manuscript.md
ORDER.mdassets/templates/order.md
chapters.jsonassets/templates/chapters.json
Chapter notesassets/templates/chapter-note.md

Edge Cases

  • Open copyedit queries → stop; the text is not frozen
  • No style sheet → do not invent one; query the conventions that matter, or run copyedit first
  • Source changed after proofreading → the pass is void for the changed sections; re-proof them
  • No formatted proof → run the manuscript pass only, and say what a proof-vs-source pass would add
  • A deliberately unconventional convention (unquoted dialogue, intentional fragments, dialect) → protected; never "fix"
  • Author asks you to fix prose while you're here → decline and route it upstream; mixed passes destroy the value of both
  • Second proof missing page breaks or running heads → note as not applicable rather than passed
  • Very long manuscript → work in blocks, but keep one errata list and number it continuously
  • Repeated errors of one kind → one errata entry with a count and locators, not fifty entries

Working With the Other Skills

  • copyedit — runs immediately before this. Its style sheet is the authority for every decision, and its clean/ or tracked/ output is the authoritative text you are checking. Nothing in this pass may contradict it.
  • line-edit — prose work, two passes earlier. A sentence that reads poorly is not a typo; route it back rather than fixing it here.
  • developmental-edit — structure, long before. If editorial-review/ carries open Critical notes, the text is nowhere near ready to proofread.
  • character-interview — declared character facts and voice. Useful for name and fact consistency checks, and a source of terms for the search lists.

What This Skill Does Not Do

  • Make new style or grammar decisions
  • Improve prose, rhythm, or word choice
  • Query or re-litigate what the style sheet has already settled
  • Proofread text that is still being edited
  • Guarantee a clean text — a machine read-through misses plausible-word errors, and the report says so
  • Replace a human final reader before publication

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.