Edit mode

Improve existing text with the smallest change that makes it follow the profile and removes slop. The meaning stays locked. The original text is the source for the meaning check.

1. Read and mark

Read the whole text once. Read the profile's brief and "Reading a rule" in schema-nonfiction.md. Then mark:

strong slop patterns (slop.md, sections A and E first) and phrases from the language file's lists;
places that break a rule that applies to this text (check applies and except), or a convention in the brief;
real errors: grammar, agreement, accents, punctuation.

With a shell, the mechanical checks find many of these: lint.py and measure.py check --rules <rules.md> --base <base.md> (commands in draft.md).

Also mark what must not change: facts, numbers, names, quotes, citations, technical terms, code, data. See meaning.md.

2. Decide how much to change

Stay conservative. Change sentences and words. Do not reorder sections, merge or split paragraphs, or rebuild the argument, unless the user asked for structural changes. Rules on architecture (2), argument (3) and paragraph order (4) that the text breaks are reported, not applied, in a light edit.
Never delete a claim to satisfy a rule. If a rule bans a sentence (for example a "never open with background" rule), rewrite the sentence so the claim survives, or move it, or leave it and report it. Cutting a claim needs the user's explicit request. This holds even when the claim seems weak or generic.
If the text is already good, say so and return it unchanged, or with only the real errors fixed. Do not swap words for synonyms to show effort.
Fix the marked spots first. Rewrite a whole sentence only when patching it would leave it awkward.
Keep the user's own quirks if the text is theirs. An odd but exact word is voice, not an error.
Do not translate unless asked. If asked, keep quotes in the original language or mark them as translations, and keep the citation.

3. Edit

Apply the rules in the order from SKILL.md section 4.

4. Review

Follow review.md, giving the reviewer the original text as the source, so it checks meaning too. For short texts, a review by yourself is enough. Fix VIOLATIONs that sit in the spots you changed or that a small edit can fix; list the structural ones for the user. At most two reviews.

5. Check meaning

Compare the edit with the original, claim by claim:

Is every claim still there, as strong or as uncertain as before? "May be associated with" must not become "causes".
Are numbers, units, names, negations, quotes and attributions identical?
Did you add any fact? Remove it.

A deleted sentence counts: if it held a claim, it is a change in meaning. A change in meaning is a critical failure, even when the new text follows the profile better. Then run the final check in SKILL.md section 6.

6. Return

Pasted text: the edited text, then up to 5 short lines on the main changes, plus any structural problems you reported but did not fix. Skip the notes if the user asked for the text only.
A file: change only the prose in the file. Leave code blocks, inline code, YAML front matter, link targets, tables of numbers and data as they are. Then give a short summary.
Inside another task (a commit message, a PR body, a document an agent is writing): return the final text only.