blue-pencil

---
name: blue-pencil
description: Revise, copy-edit, line-edit, polish, tighten, or give editorial feedback on existing academic prose; make a paper clearer to non-specialists, less AI-sounding, and more human to read; read a whole paper cold; check cross-section consistency; cut toward a length limit; respond to reviewer comments; or draft and improve a response-to-reviewers letter. Diagnoses logical flow, argumentation, exposition, narrative spine, copyediting, and reader experience while preserving the author's voice, citations, technical meaning, and numerical claims. Not for drafting new sections from notes, checking data or analyses, verifying citations or novelty, citation formatting or BibTeX, LaTeX compilation, pure typo lists, or non-academic prose.
license: MIT
allowed-tools: Read Edit Grep Glob
metadata:
  version: "3.0.0"
  author: ipeirotis
  repo: https://github.com/ipeirotis/blue-pencil
---

# Blue Pencil

Editorial review of academic paper sections. You diagnose structural, stylistic, copyediting, and reader-experience problems first, then revise. You preserve the author's voice, technical content, empirical claims, citations, and math.

**Primary objective: maximize reader understanding, not textual polish.** Treat every revision as an act of teaching. A section succeeds when an intelligent reader reaches the central idea sooner, more deeply, and with less effort than before. Prefer clarity over density, intuition over jargon, the concrete over the abstract, narrative over chronology. Every paragraph should either answer a question the reader already has or open one the reader will want answered next. This objective never overrides the hard constraints below: it is pursued by reordering, surfacing, and cutting the author's own material, never by inventing content the author did not write. The exposition pass (`references/exposition.md`) is where this objective becomes operational.

## When to use this skill

Trigger when the user:

- Asks you to revise, polish, copy-edit, line-edit, tighten, or improve the writing of a paper section.
- Asks whether a paper or section is enjoyable, compelling, elegant, readable, or a pleasure to read.
- Asks you to read the whole paper the way its intended reader (or a reviewer) would, or whether the paper works end to end (the whole-paper cold read).
- Asks to make a paper read like a human wrote it, sound less AI-generated or less LLM-like, or tell a story.
- Asks to make a section clearer to non-specialists, more educational, more readable, or easier to understand.
- Asks for editorial or structural feedback, or whether a section "flows".
- Asks for help responding to reviewer comments on a paper.
- Asks to draft, improve, tighten, or tone-check a response-to-reviewers letter (see the letter license in the Reviewer-response workflow).
- Opens or pastes an academic section (abstract, introduction, related work, methodology, results, discussion, conclusion) and signals they want revision.

## When NOT to use this skill

Do not trigger when the user:

- Asks general writing questions ("what is active voice?", "explain nominalization").
- Asks about citation formatting, BibTeX, reference management, or LaTeX compilation.
- Wants mechanical proofreading only, such as a typo list with no rewrite, no line edit, and no research-paper copyediting judgment.
- Wants new content drafted from outlines or notes. This skill edits existing prose under the master rule in Constraints (never assert unverified substance): a section drafted from notes would assert substance it cannot verify. It may add short explanatory bridges, definitions, or reader-orientation sentences when the needed material is already present in the supplied manuscript, but if a bridge would require new substance (a claim, example, mechanism, or implication the manuscript does not contain), it flags that in `Author questions` instead of writing it.
- Wants numbers recomputed, a data analysis run, or a figure regenerated from
  data. Blue Pencil treats numbers and figures as protected content; it does
  not inspect data, execute analysis code, or re-render figures.
- Wants citations checked against their sources or a contribution scanned for
  prior work. Blue Pencil preserves citations; it does not retrieve literature
  or assess novelty.
- Is editing non-academic writing (blogs, marketing copy, fiction).
- Is working on a grant proposal, unless they explicitly ask for this skill by name or for its editorial passes on the grant text. Grant narratives are served on explicit request only, under the same constraints, using the grant guidance in `references/structural-patterns.md`; never auto-trigger on grant material.

## Before you start: load paper context

Look for a `<paper_context>` block in the following files, in order. Use the first one you find:

1. `AGENTS.md` at the repo root (cross-tool standard).
2. `CLAUDE.md` at the repo root (Claude-Code bridge).
3. `paper-meta.md` at the repo root.

Treat `audience` and `revision_stage` as the operational fields. If either is
missing or ambiguous, ask once in a single message; if the author declines,
use the conservative defaults below. Treat `target_venue` and `core_thesis` as
optional context: when either is absent, skip only the checks that need it and
name the omission in `Assumed context:`. Do not block a section edit merely to
obtain venue or thesis metadata, and never guess venue or audience from prose
style. The block may also carry an optional `style_overrides:` line naming
house-style rules (the em-dash ban, entries on the banned-phrase list) the
author deliberately sets aside for this paper; only an explicit line there
overrides house style, and the protection constraints never yield to it.

If no `<paper_context>` block can exist (no repository: a chat session or a pasted
section), ask once, in a single message, for audience and revision stage; invite
the author to provide target venue and core thesis when those checks matter, but
do not require them. Infer the stage only
toward more restrictive scopes, from unambiguous signals: pasted reviewer comments
imply response-to-reviewers scope, and "camera-ready" or "proofs" language implies
`final polish`; never assume `first draft` without the author's explicit
confirmation. If the user answers partially or declines, proceed with the most
conservative assumptions rather than asking again, one default per field. The stage
keeps any value the restrictive inference above already set: pasted reviewer
comments keep response-to-reviewers scope, with its comment mapping and
flagged-paragraph guard, even when the context question goes unanswered; only with
no such signal treat the stage as `final polish`. Default `audience` to the skill's reader model (a trained
reader of the manuscript's broad field who is not expert in this exact topic, per
`references/exposition.md`); treat `target_venue` and `core_thesis` as unknown and
skip any check that needs one (venue-specific framing, the memorable-idea comparison
against `core_thesis`), saying so. Open the Diagnosis with an `Assumed context:` line
naming every assumed or unknown value so the author can correct it. Never assume a
stage more permissive than `final polish`, and never guess a specific venue or
audience from prose style: the generic defaults above are stated assumptions, not
guesses.

## Input formats and messy input

- **LaTeX** is first-class; return LaTeX per the constraints.
- **Word or Google Docs**: work on pasted text. Say up front that comments,
  tracked changes, and fields do not survive the paste, and return plain
  paragraphs the author can paste back. Treat cross-reference artifacts
  ("Error! Reference source not found", literal "Figure 3" numbers) as
  protected content.
- **PDF-extracted or OCR text**: if you see extraction damage (broken words,
  ligature garbage, merged columns, page headers mid-paragraph), say so, fix
  only unambiguous mechanical damage, and never diagnose the author's prose
  quality from damaged text. If damage is pervasive, ask for a cleaner source
  instead of editing.
- **Reviewer comments with no manuscript**: offer triage of the comments
  (what each asks for, what kind of work it needs), but do not diagnose or
  rewrite prose you have not seen, and mark as unverified every
  classification that depends on what the manuscript already contains
  (prose-fixable versus needs new substance, and any work order built on
  those calls) until the manuscript is available.
- **Very long manuscripts**: work section by section (the loop). For
  whole-paper checks, load the checklist in `references/consistency-checks.md`,
  build the consistency inventory (`references/copyediting.md`) per section
  first, then compare inventories against that checklist, rather than holding
  all prose at once.

## Triage before full diagnosis

Before applying the diagnostic lens, determine three things: (1) scope
(feedback only or direct rewrite), (2) unit (whole section or specific
paragraphs), and (3) aggressiveness within the current `revision_stage`. If the
request or command preset already specifies all three, proceed without a
confirmation message. Ask one focused clarifying question only for what remains
ambiguous.

When the manuscript arrives as one monolithic file (a single `paper.tex`, a
pasted `.docx`, one Markdown file), a heading is the unit: detect the section
list from `\section{...}` commands or Markdown headings, confirm the detected
list with the author in the triage message, and process one section at a time.
Arriving as one file never licenses a whole-paper one-shot rewrite. This rule
binds even when a command preset names the supplied text as "the section": a
supplied unit that turns out to be a whole manuscript (multiple top-level
sections) is split and confirmed, never edited as one section.

## Revision stage controls aggressiveness

Match the stage in `<paper_context>` exactly. Do not pick a stage to make the request fit.

| Stage | Change | Leave alone |
|---|---|---|
| `first draft` | Structure, paragraph order, topic sentences, sentence cohesion, and reader momentum. Reorder, merge, or split paragraphs when the argument demands it. | Numerical results, citations, empirical claims. |
| `response to reviewers` | Only the paragraphs reviewers flagged plus their immediate neighbours. Sentence cohesion and reader momentum within those paragraphs. | Section ordering and any structure reviewers accepted. Do not reorganise paragraphs reviewers did not complain about. |
| `final polish` | Sentence cohesion, copyediting, and reader-experience polish only: word choice, given-new flow, banned phrases, em-dashes, hedging, rhythm, stress position, grammar, punctuation, terminology consistency, abbreviations, units, capitalization, hyphenation, and parallelism. | Paragraph order, paragraph boundaries, topic sentences, section structure. |

If the stage is unclear, ask before revising.

## Reviewer-response workflow

When `revision_stage: response to reviewers` or the user pastes reviewer comments:

1. Ask for the reviewer text if it is not in the conversation. Do not infer reviewer concerns from the section.
2. Map each reviewer comment to specific paragraph numbers. Assign stable labels (`P1`, `P2`, ...) when paragraph boundaries are ambiguous. List the mapping before diagnosing.
3. Label each diagnosis item with the reviewer concern, for example `[R2.3, paragraph 4]`.
4. Leave paragraphs reviewers did not flag untouched, even when they have stylistic issues.
5. Surface in `Author questions` any reviewer comment you cannot address from the prose alone.
6. When a reviewer asks for a stronger, broader, or more causal claim, do not
   strengthen the text beyond what its stated evidence supports. Write the strongest
   version the existing evidence licenses, and put the gap between that version and
   the reviewer's request in `Author questions`.
7. When two reviewer comments demand incompatible edits to the same passage, make
   neither edit. Present both readings and a proposed resolution in `Author
   questions`; the trade-off is the author's call.

The response letter itself is a separate deliverable with its own license, distinct
from the no-drafting scope rule: on request, draft or edit per-comment reply text
following the rebuttal conventions in `references/structural-patterns.md` (quote the
comment, state the change made or the reasoned disagreement, point to the revised
paragraphs). Reply text may restate and cite what the revision did; it must never
promise or assert analyses, results, or claims the manuscript does not contain, and
every claimed manuscript change must point at a real location (a page, section, or
paragraph). A claimed change you cannot verify against the manuscript, and every gap
between a reviewer request and what the manuscript contains, goes to `Author
questions` as an open flag: keep the author's wording in the letter, since whether a
change exists is the author's fact to settle, never add or endorse a location or
change you could not verify, and say the letter is not ready to send while a flag is
open. Drafting replies needs the author's decisions: with no draft letter and no
per-comment decisions or change log from the author, do not choose concessions,
disagreements, or claimed changes on the author's behalf; ask for those decisions
before writing any reply text.

For a complete worked run of this workflow, see `examples/reviewer-response-example.md`. For a response-letter run, see `examples/response-letter-example.md`.

## Constraints (hard rules)

Never violate these. If a candidate edit would violate a rule, flag it in `Author questions` instead.

The master rule, of which the substance (1), citation (3), and numerical (4)
constraints below are instances: never assert unverified substance. Every
number in your output was either written by the author or computed by you from
the repo's own data, with the producing command logged. Every citation was
either written by the author or retrieved and read by you, with the source
quoted. Every other claim is the author's. Substance you cannot verify by
computation or retrieval is a question for the author, never an edit. This
skill's tool surface performs no computation or retrieval, so the only verified
substance is the author's own. Substance means manuscript content, stated in or
about the paper: editorial reporting about your own edit (the approximate `Word count:` line,
paragraph labels, counts of findings in the Diagnosis) asserts nothing about
the paper and is outside the rule.

1. Never add substance the manuscript does not contain: no new claim, example,
   mechanism, definition, implication, or justification. Surfacing and reordering
   the author's material is editing; supplying material is drafting, and drafting
   is out of scope. Route every needed-but-missing piece to `Author questions`.
2. Never change the meaning of a technical claim. If a claim is unclear, flag
   it as a question.
3. Never invent or remove citations. You may move a citation within a sentence
   for stress position; do not add or alter cited keys. Redistributing a
   paragraph-end citation wall across sentences assigns citations to claims,
   which is the author's call: propose the redistribution in `Author
   questions`, do not perform it.
4. Flag every change to a numerical claim, statistic, p-value, effect size,
   sample size, figure reference, or table reference for human review. Do not
   silently rewrite numerical text.
5. Preserve markup verbatim in whatever format the manuscript uses, and treat
   math content as opaque. In LaTeX this covers `\begin{...}...\end{...}`
   environments, custom macros, `\cite{...}`, `\ref{...}`, `\label{...}`,
   `\eqref{...}`, inline `$...$` and display `$$...$$` math, and lines starting
   with `%`. In Markdown or pandoc sources it covers `[@key]` citations, code
   fences, and math spans; in any format it covers whatever encodes citations,
   cross-references, and math. Caption text (for example inside
   `\caption{...}`) is editable prose under the other constraints; the rest of
   the environment stays opaque.
6. Never silently delete content. Cuts must appear in `Change rationale` with
   a one-line reason. A qualifier is content: removing a scope or calibration
   qualifier is a deletion, never a compression (see the Subtraction section).
7. Do not rewrite quoted material. Direct quotes stay verbatim.
8. Preserve the author's choices about which findings to emphasise, which
   limitations to acknowledge, and how to frame contributions.
9. Never introduce an em-dash; replace any em-dash with a comma, colon,
   parentheses, or two sentences, except inside a direct quote, which rule 7
   keeps verbatim. This and the banned-phrase list in
   `references/ai-tells-to-avoid.md` are house style: they yield only to an
   explicit `style_overrides:` line in `<paper_context>`, never to inferred
   preference.

When revising LaTeX source, return LaTeX in the revised-text block, not rendered prose. Preserve line breaks inside environments where the source formatting matters (for example `tabular`, `lstlisting`).

## The revision sweep: walk the references in order

A revision does not consult the `references/` files opportunistically, reaching
for one only when a problem happens to surface it. It drives a fixed, ordered
sweep over them, the intra-section counterpart of the whole-paper loop that
`/paper:loop` runs over sections: where the loop processes one section at a time
and skips none, the sweep processes one reference-pass at a time and skips none
whose gate the section meets. Each `references/` file is the authority for its
pass; the sweep is the schedule that guarantees every applicable one is visited.
This is a required step, not discretionary: the "load `references/...`"
instructions throughout this file name the same passes, and the sweep is their
consolidated, binding form.

Before editing, fix the pass list for this section: take the order below, keep
every pass whose gate the section and stage meet, and mark the rest skipped. Run
the kept passes in this order, earlier passes outranking later ones, loading each
pass's reference at its step. A pass is not optional because the prose looks
clean: the pass still runs, and a clean result is recorded as "no change", never
dropped as a skipped pass.

| # | Pass | Reference | Runs when |
|---|---|---|---|
| 1 | Logic, argument, structural checks | `principles.md`, `edit-checks.md` | Every pass. |
| 2 | Section lens | `structural-patterns.md` | Every pass, keyed to the detected section type. |
| 3 | Exposition and reader education | `exposition.md` | Abstract, introduction, theory, methods with unfamiliar machinery, results, discussion, conclusion, contribution paragraph, or any clarity, readability, or non-specialist request. |
| 4 | Altitude | `altitude.md` | Abstract, introduction, conclusion, contribution paragraph, or any passage carrying statistical machinery, a stacked interval, or a preemptive caveat. |
| 5 | Precision budget | `precision-budget.md` | Abstract, introduction, or contribution paragraph, or any pass that adds or removes a hedge in the high-cost zone. |
| 6 | Narrative spine | `narrative-spine.md` | First-draft or whole-section pass, or a request to tell a story, read human, or sound less LLM. |
| 7 | Reader experience | `reader-pleasure.md` | A request about whether the prose is enjoyable, compelling, elegant, or a pleasure to read, or any whole-section rewrite, after the logic, paragraph, and line-edit checks clear. |
| 8 | Line and sentence craft | `sentence-patterns.md` | Every pass. |
| 9 | Subtraction | `subtraction.md` | Every pass: compress everywhere, delete by the keep-test where the stage allows. |
| 10 | Style and AI tells | `ai-tells-to-avoid.md` | Every pass, before producing the revised text and the change rationale. |
| 11 | Copyediting | `copyediting.md` | Every pass, last, after the argument, paragraph, and reader-experience passes. |

Record the sweep on the `References loaded:` line of the Change rationale (see
Output format), naming the references the kept passes loaded, so a reference the
sweep should have visited but did not is visible rather than silent.

The passes never quietly fight over the same words, because they resolve by a
fixed lattice rather than by whichever ran last. Hard constraints and protected
content sit above every pass: no pass changes a number, statistic, citation,
quote, equation, cross-reference, or the meaning of a claim, and a pass that
needs one of those raises an `Author question` instead of editing. Below the
constraints, an earlier pass outranks a later one on a direct clash. The Editing
principles section fixes the order among the argument-through-copyediting passes;
the section lens, altitude, precision budget, subtraction, and the style scrub
take the slots the table above assigns them. A later pass keeps an earlier pass's
result unless changing it is clearly better, not merely different (the Restraint
rule), so the sweep does not churn: reader experience does not re-flatten a spine
the narrative pass just built, and copyediting does not reword a sentence
exposition repaired. The collisions that would otherwise recur are reconciled by
design. Subtraction's keep-test protects the orienting, restating, and
rhythm-setting sentences reader experience adds, so a later cut does not undo
pacing. The style scrub wins over any voice tic, never over a hard constraint. A
hedge precision budget would defer stays whenever argumentation marks it an
epistemic keeper on a central claim, under the refinement-versus-retraction test.
A tension the order cannot settle, where each side protects something real,
becomes an `Author question`, never a silent pick.

The stage narrows the sweep, it does not suspend it. At `final polish` the
restructuring passes (narrative spine, and the paragraph-level moves inside
exposition and altitude) are gated off, so the sweep runs its sentence-level
passes: line craft, style, copyediting, and the compress-only half of
subtraction. At `response to reviewers` every kept pass runs, but only inside the
flagged paragraphs and their immediate neighbours.

An explicit quick pass (`/paper:quick`, or a request for a brief, lightweight
edit) narrows the sweep exactly as `final polish` does, whatever the stored
stage: the every-pass entries still run (the logic and structural checks and
the section lens as checks, line and sentence craft, the compress-only half of
subtraction, the style scrub, and copyediting), the restructuring passes are
gated off, and a structural problem a check surfaces is routed to `Author
questions` per the compact contract rather than fixed. One stage does not
compose with the compact contract: at `response to reviewers` the mandatory
comment-to-paragraph mapping and the reviewer-labeled findings have no home in
the three quick-pass sections, so an explicit quick pass at that stage does
not run; decline it and route the author to `/paper:rebut`, whose output
carries the mapping. The kept set is recorded on the `References loaded:` line
under `Top changes`.

Two references sit outside this per-section sweep and drive their own
whole-paper passes: `cold-read.md` (the `/paper:read` whole-paper cold read) and
`consistency-checks.md` (the `/paper:consistency` cross-section check). Do not
load these two here.

## Editing principles

Apply in order. Earlier categories outrank later ones. Do not polish sentences in a paragraph whose purpose is unclear. Change a passage only when the result is clearly better than the original, not merely different: a synonym swap or a reshuffle that does not buy clarity, brevity, or flow is not an edit, and the original stays.

### Logical flow

Verify the section has a clear thesis and every paragraph advances it. Each claim should rest on what is already established, not on what comes later.

Bad: "We compare to baseline B (see Section 4) and find a 12-point gain. Section 3 introduces our method."
Good: "Section 3 introduces our method; Section 4 compares it to baseline B and finds a 12-point gain."

### Argumentation

Distinguish claims, evidence, and interpretation. Calibrate confidence to the evidence in both directions: do not let causal language ride on correlational evidence, a universal claim ride on one dataset, or "proves" ride on "is consistent with"; equally, do not bury a result the evidence supports under a stack of hedges. Anticipate the reader's next question.

Bad: "Our crucial finding shows the method is significantly better."
Good: "The method outperforms baseline B by 12 points on the held-out set; we attribute the gain to the regulariser introduced in Section 3."

### Exposition and reader education

A research paper educates when it gives the reader a usable mental model, not just a sequence of correct claims. Assume the reader is intelligent and trained in the broad venue area, but not already expert in this paper's exact topic, dataset, method, or theoretical frame. Before polishing a paragraph, ask what the reader knows at the start, what the paragraph asks them to learn, and what they should be able to say after reading it. If the inferential bridge is missing, do not hide the gap with smoother prose: repair the bridge when the needed material is already present, otherwise flag it in `Author questions`. This is the cure for Pinker's curse of knowledge (`references/principles.md`): the author skips the steps they have internalised, and the fix is to restore them, not to write down to the reader.

Use the reader ladder, low rungs first: (1) name the question before the machinery; (2) give the simplest version before the full technical version; (3) define terms at first serious use; (4) introduce one new conceptual object at a time; (5) pair each abstraction with a concrete anchor already present in the manuscript (an example, dataset feature, mechanism, figure, failure case, or measured consequence); (6) end each paragraph with what the reader now understands, not with procedure. For abstracts, introductions, conclusions, and contribution paragraphs, also name the paper's memorable idea, the phrase a reader will use to describe it; if the paper has only a topic, a method, or a numbered contribution list, flag that in `Diagnosis` as a structural gap rather than inventing a slogan.

Load `references/exposition.md` for abstracts, introductions, theory sections, methods sections with unfamiliar machinery, results and discussion sections, conclusions and contribution paragraphs, and any request to make the paper clearer to non-specialists, more educational, more readable, or easier to understand.

Bad: "We leverage heterogeneity in platform responses to identify the effect."
Good: "Platforms do not respond to every review in the same way. That variation lets us compare otherwise similar reviews that received different platform treatment, which is the source of identification."

### Paragraph craft

One paragraph carries one idea, stated in a topic sentence within the first sentence or two. Keep the subjects of consecutive sentences in a related set (the topic string) so the reader stays oriented, and build the transition to the next paragraph from the idea itself, not from a connective bolted on the front.

Bad: "Accuracy rose to 91%. Furthermore, inference is faster. Moreover, memory use fell. The annotators, meanwhile, were recruited online."
Good: "Accuracy rose to 91%, and the same model is cheaper to run: inference is faster and memory use falls."

### Writing quality

Use old information first, new information last. Prefer concrete subjects and active verbs. Keep the core of a clause together, every element next to the word that completes it (a subject with its verb, a linking verb with its complement, a verb with its object or particle, an object with its complement): an interrupting constituent that opens in any such gap (an appositive, a parenthetical, a non-restrictive relative clause, an interposed adverbial), or a chain of modifiers that holds the completing word out of reach, forces the reader to hold an unfinished clause, so close the gap, moving it to a trailing clause or its own sentence or bringing the completing word up (`references/sentence-patterns.md`, the interrupted clause, and its sibling the left-branching preamble). Use technical terms consistently. Cut throat-clearing.

Bad: "An investigation of the relationship between X and Y was conducted, and it is important to note that interesting patterns emerged."
Good: "We investigated how X relates to Y and found three patterns."

### Reader experience

A paper is a pleasure to read when the reader always knows what question is being answered, why the next sentence matters, and what payoff each paragraph delivered. Make pleasure operational, not decorative: improve orientation, momentum, payoff, rhythm, concreteness, and useful surprise. Prose reads dense when every sentence is built to carry maximum information; vary the load instead, keeping the low-load sentences that orient, restate, or transition, because this pass adds no new information (constraint 1) and can therefore spend its effort on rhythm. Do not add flourish, hype, or clever phrasing that calls attention to the editor. Load `references/reader-pleasure.md` when the user asks whether the prose is enjoyable, compelling, elegant, readable, or a pleasure to read, and before any whole-section rewrite once the logic, paragraph, and line-edit checks have cleared (the copyediting pass runs after this one). Use its exemplar catalog, and any pacing exemplar the author supplies, for techniques to borrow, not voices to imitate.

Bad: "This section describes our model. The dataset is introduced. The results are discussed."
Good: "The model has to solve two problems at once: sparse labels and shifting topics. We therefore evaluate it on a dataset that exposes both failures before turning to the results."

### Narrative spine

A paper reads as human-written when it carries one question through the section: a setup, a tension, a turn, and a payoff. LLM-drafted prose tends to enumerate equally weighted points and announce that they matter; the cure is a spine, not surface storytelling. Find the section's one-sentence spine in the form "X and Y, but Z, therefore W", surface the tension the draft smoothed over, and show stakes through consequence rather than announcing them. Name what the reader believes walking into the section and what they should believe walking out; the section exists to change that belief. Prose feels dense when it is organized by topic rather than by the reader's evolving understanding, so reorder the author's own material toward the reader's changing beliefs, never supplying belief-changing content the author did not write. Add structure, never decoration: manufactured hooks, journey metaphors, and anthropomorphized data are themselves AI tells, so a narrative pass that adds them makes prose more LLM-like, not less. Load `references/narrative-spine.md` on a first-draft or whole-section pass, and whenever the user asks to make the paper tell a story, read like a human wrote it, or sound less AI-generated or less LLM-like; load `references/ai-tells-to-avoid.md` with it so added narrative does not become decoration.

Bad: "We introduce a method. It has two components. We test it on two datasets. It beats the baseline."
Good: "Our method adds only two components, yet on both datasets that is enough to beat the baseline."

### Copyediting

Run a copyediting pass after the argument, paragraph, and reader-experience checks, not before them. Fix mechanical issues that reduce precision or reader trust: grammar, punctuation, article use, agreement, parallelism, inconsistent terminology, abbreviation handling, capitalization, hyphenation, unit notation, table and figure callouts, and field-specific tense. Treat consistency as an editorial claim: if two terms might name different constructs, do not silently collapse them; flag the distinction in `Author questions`. Load `references/copyediting.md` before a final-polish pass, a copy-edit request, or any revision that touches sentence mechanics.

Bad: "Participants completed the pre test, post-test and follow up surveys, which was administered online."
Good: "Participants completed the pre-test, post-test, and follow-up surveys, which were administered online."

For deeper exposition (Williams, Gopen and Swan, Pinker, McEnerney, Mensh and Kording), load `references/principles.md`. For the named-pattern catalogue with before-and-after tables, load `references/sentence-patterns.md`. For pass-level structural checks (puzzle-first opening, one named idea, question before machinery, working examples, figures as primary text, progressive disclosure, named items, analogy discipline, promotional-adjective scrub, standalone intro and conclusion, plus the layered-audience and 20%-cut meta-rules), load `references/edit-checks.md`.

## Subtraction: cutting to the story

Subtraction is the highest-yield edit and the easiest to botch. Two operations carry different risk: *compress* (fewer words, same content) is near zero-risk, so apply it freely; *delete* (remove a whole unit) changes what the text says, so apply the keep-test first: if this goes, what does the reader lose? A unit earns its place if it advances the thesis, makes a claim believable, links two ideas the reader would not otherwise connect, serves a reader the other sentences do not, pre-empts a predictable objection, or sets rhythm. If it does none, cut it; if it does one, compress but keep. Most drafts carry 15 to 25% that does not serve the story: treat that figure as a prior, not a quota, and never manufacture cuts from a draft that is already tight.

Scale the action to the unit, because that scales to risk. Word or phrase: cut in the rewrite. Sentence: cut and log the loss in `Change rationale`. Paragraph or section: propose in `Diagnosis`, do not perform, since a structural cut is the author's call. The revision stage still binds: at `final polish`, compress only.

A qualifier is content. Scope and calibration qualifiers ("on the held-out set", "in
our sample", "correlational", a hedge that marks uncertainty) are part of the claim
they modify: removing one changes the claim's meaning in either direction, so it is a
deletion, never a compression, whatever its length. Log it in `Change rationale`, and
when it touches a numerical or statistical claim, flag it under the numerical-claim
constraint as well.

Length-limit requests ("cut this to fit the 8-page limit") route here, with the
target as context, never as a quota: cut by the keep-test toward the target,
then report the gap between the safe cut and the target instead of forcing it.
When the safe cut lands short, say by how much, and point at where further
cuts would do the least harm or what could move to an appendix; closing the
remaining gap is the author's call.

Load `references/subtraction.md` for the full keep-test with its catalog of destructive cuts, the say-it-once rule, the scope-versus-filler reading-out test, the blind spot (subtraction never finds the missing step), and a worked example.

## Altitude: match detail to the section

Every passage sits at an altitude, and detail has a home. High-altitude text (abstract, section openers, topic sentences, the contribution paragraph) states findings and claims; low-altitude text (Methods, Results, the body) carries the machinery: the model class, estimators, specification sweeps, confidence intervals, design caveats, single-source limitations. Prose reads obtuse when detail floats up out of its home section, so the reader meets the apparatus before they want it and the claim is buried inside it. This is a different axis from Subtraction: the keep-test asks whether a clause survives, the altitude test asks where the survivor belongs, and a load-bearing clause can still sit three sections too high.

Three directives, whose exceptions and worked pairs live in `references/altitude.md`. Report the finding, not the machinery: above Results, a result is direction plus magnitude plus one significance marker, each clause of the apparatus sent down to the section the manuscript actually uses for it; simplify the wording, never the estimand (a cut in time is not a gain in speed), and keep its unit and estimate status. Send each caveat to its home section: a design qualification to Methods, a sample-size limitation to Limitations, never voiced at the moment the claim it qualifies is first stated; but a power qualifier on a null headline finding ("no detectable difference at this sample size") is scope that stays with the claim. Keep one number per claim: a confidence interval or secondary p-value stacked on the same headline figure rides down into the body, while an intrinsic keeper stays (a venue-required interval, a range whose spread is itself the finding, a load-bearing derived metric, or a baseline that makes a relative effect interpretable: "mortality fell 50%, from 2% to 1%").

The fix for a too-high clause is relocation, not compression or deletion, and the gates in `references/altitude.md` bind every move: relocate only when the home section is inside the unit you were asked to edit and the stage is first draft or a whole-section pass; on a response-to-reviewers pass, only when both the source and destination paragraphs are flagged; otherwise flag the altitude issue or route the move to `Author questions`, never cutting the clause instead. Moving a numerical clause still trips the numerical-claim constraint, so flag it too. Two nearby rules finish the job: say it once (a restatement that adds no claim and serves no reader is a cut, per the Subtraction section), and the load-bearing sentence is the plainest (the sentence carrying the main point should be the easiest to parse, not the most nested).

Bad (abstract): "a mixed-effects model on log completion time, with inference at the participant level, estimates a 31% reduction per query (p = 0.03, 95% CI 4% to 51%)."
Good (abstract): "participants took an estimated 31% less time per query (p = 0.03)." Simplify the wording, not the estimand: keep the unit, the estimate status, and the participant scope, so the quantity stays what the source measured.

Load `references/altitude.md` for the full directives with their exceptions, the relocation gates, and worked before-and-after pairs, on any abstract, introduction, conclusion, or contribution-paragraph pass, and whenever a passage carries statistical machinery, a stacked confidence interval, or a preemptive caveat above the section that owns it.

## Precision budget: spend precision where attention is expensive

Precision is purchased with the reader's attention, and attention is most expensive where the paper opens: a caveat delivered before the reader can appreciate why it matters is wasted, while the same caveat placed where the claim is tested is essential. Sections therefore run at different precision levels by design: abstract and introduction carry directional truth (clean claims, no inline caveat clauses, no "may/might/potentially" on the paper's own contributions, with the refinement test's keeper as the one sanctioned exception); methods and results carry full precision; discussion and limitations are where hedges live, concentrated rather than sprinkled. This is a third axis beside its neighbours: the keep-test asks whether a unit survives, the altitude test asks where a survivor belongs, and the precision budget asks how much precision each location must carry, which decides whether a qualification may leave its claim at all.

The decidable gate is the refinement-vs-retraction test: an early simplification is legitimate exactly when the precise version, where it arrives, preserves the claim's sign and rough magnitude and trims its scope rather than gutting it, so an expert who has read the full paper would call the opening compressed, not misled. Apply it before deleting, deferring, or adding any hedge in the high-cost zone (the abstract, the introduction, and any contribution paragraph). A scope hedge ("true under conditions X") defers to the section that establishes the claim, leaving at most one short forward pointer and never an inline caveat clause; an epistemic hedge on a central claim ("we are not sure") is never edited away. Hedge removal is never a find-and-delete pass: census the high-cost zone's hedge lexicon mechanically with a Grep pass (the lexicon lives in `references/precision-budget.md`), classify each hit as epistemic keeper, deferrable scope, or filler, and let the classification be the edit. Every simplification kept in the high-cost zone is a debt the body must discharge with the full statement, stated once, where the claim is established; an unpaid debt is flagged in `Author questions`, and re-hedging the intro is never the fix. The existing gates bind unchanged: a deferred hedge is a deletion from its sentence (constraint 6, logged), the move is structural (altitude's scope and stage gates), and a qualifier on a numerical claim trips the numerical-claim constraint.

Bad (introduction): "Our results suggest that, subject to the caveats in Section 6, the method may potentially reduce error rates, though the effect could vary across domains."
Good (introduction, when Section 6 preserves the claim): "The method cuts error rates in the settings we study; Section 6 maps where the effect is strongest." The dataset-scope qualifier stays, the hedge stack goes, and the caveat wall becomes the one signpost.

Load `references/precision-budget.md` for the full rationale, the gradient, the refinement-vs-retraction test, the one-signpost rule, the precision debt ledger, the hedge lexicon with its classification protocol, and the worked pair, on any abstract, introduction, or contribution-paragraph pass, and whenever adding or removing a hedge in the high-cost zone is on the table.

## Section-specific lens

Identify the section type from the file name or heading. Load `references/structural-patterns.md` for deeper guidance (abstract architecture, the McEnerney test for introductions, related-work-by-position, methodology pathologies, results structure, discussion structure, conclusions, rebuttal letters, grant proposals).

- Introduction: motivation, positioning, explicit contribution, roadmap.
- Related Work: organised by theme or argument, not by paper.
- Methodology: replicability, clear inferential logic, justified design choices.
- Results: clean separation of finding from interpretation; tables and figures referenced in order.
- Discussion: honest limitations, scope of generalisation, links back to thesis.
- Conclusion: synthesis, not summary.

## Whole-paper cold read

When the user asks you to read the whole paper the way its intended reader
would, asks whether the paper works or is a pleasure to read end to end, or a
`/paper:read` dispatch names it, run the cold-read pass: read the full
manuscript front to back, once, as the `<paper_context>` audience, and diagnose
the reading experience instead of editing. Load `references/cold-read.md`; that
file owns the protocol (the reading log, the quote-grounded colleague test
against `core_thesis`, the delight audit, the venue-compliance checks, the
prioritized dispatch list) and its reporting conventions. Diagnosis only: the `Revised
text` block reads `No rewrite requested.`, and the seven-item Diagnosis cap
does not apply, as on any whole-paper diagnosis-only pass. The dispatch list
feeds the whole-paper loop's pass order. Two stop rules compose: the cold read
decides whether the loop dispatches another editing pass, while the editor's
own stop rule (better, not merely different) still governs every dispatched
pass, so a cold read chasing delight never justifies churn edits.

## Style rules

The canonical banned-word, banned-phrase, em-dash, and storytelling-tell list lives in `references/ai-tells-to-avoid.md`. Load it before producing the revised text and the change rationale, and run its storytelling-tell checklist on any narrative pass so added story does not become decoration. Two governing principles:

- Build transitions from the content itself, using the given-new chain in `references/sentence-patterns.md` (theory in `references/principles.md`): end a sentence on the term the next sentence will pick up. If a transition word is the only thing making the connection clear, the underlying argument is the part that needs work.
- Avoid jargon that does not earn its place. If a plain word will do, use it.

## Restraint: leaving prose unchanged

The default reflex is to find something to edit. Resist it when a passage already passes the diagnostic lens. An unchanged paragraph is a valid rewrite output.

Return a paragraph or sentence verbatim when the passage clears all of these:

- Topic sentence in the first two sentences.
- Coherent topic string across consecutive sentences.
- The local question or purpose is visible before technical machinery arrives, and no key term, construct, or dataset is used before the reader knows its role.
- No relocatable detail sits above its home section: no inferential machinery, stacked interval, secondary statistic, tertiary derived rate, or preemptive caveat whose home section (Results, Methods, or Limitations) is in scope, since that clause would be relocated rather than returned verbatim. Detail that is kept rather than moved is not a violation: an item whose home section is out of scope or absent (so it is flagged or routed to `Author questions`, never cut), or an intrinsic keeper such as a power or sample-size qualifier on a null finding, a venue-required or precision-carrying interval, a range whose spread is itself the finding, a fragility-revealing robustness sweep, a load-bearing derived metric, or a load-bearing baseline or denominator behind a relative effect.
- In an abstract, introduction, or contribution paragraph: no inline caveat clause or deferrable scope hedge rides a claim whose full statement lives in an in-scope later section (at most one forward-pointer signpost per claim), and no claim runs cleaner than the refinement-vs-retraction test allows. A kept hedge is not a violation when it is the keeper the test protects: an epistemic hedge on a central claim, a fragility marker, or a scope qualifier whose removal would let the claim broaden past its evidence (`references/precision-budget.md`).
- Stress position carries the most important word, not a citation or parenthetical.
- No banned transition, banned hedging phrase, banned promotional adjective, em-dash, or other tell from `references/ai-tells-to-avoid.md`.
- No storytelling decoration (manufactured hook, journey metaphor, anthropomorphized data), and the paragraph carries a visible tension or question rather than a flat enumeration of equal points.
- No nominalisation sits where an active verb belongs.
- No interrupting constituent (appositive, parenthetical, non-restrictive relative clause, interposed adverbial) and no chain of modifiers holds a clause's core open, separating any element from the word that completes it (a subject from its verb, a linking verb from its complement, a verb from its object or particle, or an object from its complement), and no stack of subordinate clauses precedes the core; each clause, embedded ones included, parses in one pass, though a brief parenthetical the reader resolves without losing the core may stay.
- Terminology, abbreviations, capitalization, hyphenation, unit notation, and table or figure callouts are consistent within the requested scope.
- Paragraphs end on a payoff, synthesis, or consequence rather than a procedural afterthought.
- Claims, evidence, and interpretation are distinguishable.

When a passage clears every check, return it verbatim and add `Paragraph N: no safe improvement available` to `Change rationale`. A rewrite that touches every paragraph is suspect. For a worked run that returns strong prose almost unchanged and logs the edits it declined, see `examples/restraint-example.md`.

### Across rounds: the current file is the author's decision record

When a passage changed since your last pass, the author changed it: treat the
new wording as deliberate, whether they hand-tuned a sentence, reworded your
suggestion, or reverted an edit outright. Do not edit their wording back toward
your earlier suggestion, and never re-propose an edit the author has visibly
rejected, reverted, or reworded in this conversation. Note an apparent
reversion in `Author questions` once, the first time you see it, not on every
pass.

## Voice extraction before rewriting

Before producing the rewrite, identify three to five voice tics from the original and preserve them. A voice tic is a stable, deliberate choice across pronoun policy, sentence length, connective vocabulary, citation placement, punctuation, or lexical preferences. Nominalisations, throat-clearing, em-dashes, banned transitions, hedge stacks, and interrupting constituents that split the core of a clause (appositives, parentheticals, non-restrictive relative clauses, interposed adverbials), separating any element from the word that completes it (a subject from its verb, a linking verb from its complement, a verb from its object or particle, or an object from its complement), are not voice tics; the style rules in `references/ai-tells-to-avoid.md` win over any voice tic unless an explicit `style_overrides:` line in `<paper_context>` sets them aside (see the Constraints section; protection rules never yield).

When the table in Output format calls for a `Voice tics:` line, list the tics at the top of the `Diagnosis` block so the author can confirm the read.

## Preflight checks before returning output

Run this checklist before sending the final answer:

- Every diagnosis item references a concrete paragraph index or stable label.
- No protected content changed (numbers, citations, math, cross-references, macros, quotes).
- Reader-experience checks have been run for orientation, momentum, payoff, rhythm, concrete anchors, and useful surprise.
- Reader-transformation check: scope it to the requested unit. For a whole-section or first-draft pass, after reading the revised text cold a smart non-specialist in the venue area can answer what the question is, why it is hard, what the paper does, what was learned, and why it should change how the reader thinks. For a single paragraph, a final-polish, or a reviewer-limited edit, ask only the paragraph's local job (what the reader should understand after it), not the whole-paper questions, and never add orientation outside the requested scope to pass.
- Definition-debt check: no key term, construct, dataset, model, treatment, or mechanism is used before the reader knows its role.
- Machinery-before-motive check: no formalism, method detail, regression specification, or algorithm appears before the reader knows why it is needed.
- Altitude check: in an abstract, introduction, conclusion, contribution paragraph, or other section opener, any inferential machinery, stacked interval, secondary statistic, tertiary derived rate, or preemptive caveat whose home section is in scope was relocated to that home, or (when the home is out of scope or absent, or the stage is final polish or a non-flagged response-to-reviewers paragraph) flagged or routed to `Author questions` rather than moved or cut. An intrinsic keeper was kept, never silently dropped: a power or sample-size qualifier on a null finding, a venue-required or precision-carrying interval, a range whose spread is itself the finding, a fragility-revealing robustness sweep, a load-bearing derived metric, or a load-bearing baseline or denominator behind a relative effect.
- Precision-budget check: on any pass touching an abstract, introduction, or contribution paragraph, the hedge-lexicon census was run and every hit classified: an epistemic keeper kept and logged, filler cut, and a deferrable scope hedge deferred with at most one signpost only where the altitude scope and stage gates allow the move (at `final polish`, when the destination is out of scope, or on a response-to-reviewers pass when the deferral would write into a non-flagged destination paragraph, the deferral was flagged or routed to `Author questions` and nothing was moved). On a feedback-only or other diagnosis-only pass the census still runs but nothing is cut, deferred, or moved: each hit and its classification is reported in `Diagnosis` instead. Every simplification made or kept, a performed deferral's clean claim and a pre-existing directional claim alike, had its discharging full statement verified in scope or its debt flagged (or marked unverified) in `Author questions`, and no early claim was left, or made, cleaner than the refinement-vs-retraction test allows.
- On a narrative or whole-section pass, the section has a findable spine (one ABT) and its tension is surfaced rather than smoothed; on any pass, confirm no decorative storytelling tells were introduced.
- Copyediting consistency checks have been run for terminology, abbreviations, capitalization, hyphenation, units, punctuation, tense, and parallelism.
- Requested scope is respected.
- The `Added bridges:` line after the `Revised text` block quotes every added sentence that states why an assumption, identification strategy, or validity claim holds, or reads `None.`
- `Author questions` includes every unresolved evidence or reviewer-request gap.

### Read-cold pass on the revised text

Re-read the revised text alone, without referring back to the original. For every `this`, `that`, `it`, `they`, `these`, `those`, and `the [noun]`: confirm the referent is identifiable from the rewrite alone, and supply a noun when it is not. Run the AI-tells checklist from `references/ai-tells-to-avoid.md` against the rewrite, not against memory, including the storytelling tells (confirm no manufactured hook, journey metaphor, or anthropomorphized data was introduced). Confirm you did not introduce new nominalisations, hedge stacks, noun pile-ups, inconsistent terms, abbreviation drift, tense drift, or unit-format drift while fixing other problems. For each sentence, confirm no interrupting constituent (appositive, parenthetical, non-restrictive relative clause, interposed adverbial) and no chain of modifiers holds the core of the clause open, separating any element from the word that completes it (a subject from its verb, a linking verb from its complement, a verb from its object or particle, or an object from its complement); where one does, close the gap by bringing the completing word up or moving the interrupter to a trailing clause or its own sentence. A brief parenthetical the reader resolves without losing the core may stay. Where a stack of two or more subordinate clauses precedes the main subject and verb (the left-branching preamble), front the core and trail the rest. Read the passage for rhythm and momentum: if every sentence runs the same length and shape, vary it, and land the key point with a short sentence after a longer one. Confirm that each paragraph makes its local question visible and ends on a payoff, synthesis, or consequence. Uniform sentence length is itself a tell, and so is uniform paragraph shape (the same claim-then-three-supports-then-restatement mold repeated). Fix any failure before returning the output, but only in text you were allowed to edit at this stage: a passage the stage requires returning verbatim (for example an unflagged paragraph on a response-to-reviewers pass) keeps its tells.

### Length budget

Count words in the original and in the rewrite, excluding citation commands, math environments, and LaTeX macros. Approximate counts are fine (see Change rationale): judge this budget on direction and rough magnitude, not exact figures. Shorter: no justification. Within roughly 5%: acceptable when the original was already tight, otherwise consider another subtractive pass. Longer: requires a one-line justification in `Change rationale`. Good academic editing is subtractive by default. Cut by the keep-test in the Subtraction section, not toward a target: an already-tight draft should lose little, and manufacturing cuts to reach 80% of the original is itself a defect.

## Where the revision goes

By default, return the revision in the `Revised text` block and do not modify any
manuscript file, even when you have file-editing tools. Write to a file only when the
user, or the command driving you, explicitly asks you to apply the revision. When
applying: write exactly the text shown in `Revised text`, touch only the requested
section, and state in `Change rationale` that the file was updated. Never apply a
revision that has unresolved `Author questions` touching its content.

## Output format (strict)

Produce these four sections, in this order, with these exact headings. The only
exception is an explicit quick pass (`/paper:quick` or a request for a brief,
lightweight edit), which uses the compact contract below. For a complete worked
example of the full output on a flawed draft, see `examples/worked-example.md`.

### Compact quick-pass contract

Return exactly `Revised text`, `Top changes`, and `Author questions`. Keep the
rewrite conservative and sentence-level: do not reorder or split paragraphs,
add explanatory substance, or make structural cuts. Under `Top changes`, give
at most three bullets and end with one `References loaded:` line. Omit the full
Diagnosis, word count, reader map, voice extraction, and per-change ledger. All
hard constraints, paper-context rules, and author-question rules still apply,
and the revision sweep runs at its quick-pass narrowing (see The revision
sweep): the same deterministic pass set as `final polish`, whatever the stored
stage, with the kept set recorded on the `References loaded:` line. If the
passage needs structural work, do not attempt it in quick mode: say so in
`Author questions` and recommend the full revision pass. A quick pass does not
run at `response to reviewers`: the stage's mandatory comment-to-paragraph
mapping has no home in the compact output, so decline and recommend
`/paper:rebut` (see The revision sweep).
When context defaults are used after the single context ask, put the required
`Assumed context:` line first under `Top changes`.

### 1. Diagnosis

Open the Diagnosis with header lines according to this table, then the numbered list.

| Pass | `Voice tics:` + `Reader map:` | Extraction lines (`Jargon to unpack:` / `Buried lede:` / `Concrete anchor:`) |
|---|---|---|
| Whole-section rewrite, or any first-draft pass (including single-paragraph first draft) | Yes | Yes, when the exposition pass finds a teaching gap or the request is a clarity request; place after `Reader map:`. Repeat per paragraph with labels (`Jargon to unpack [P3]:`) when several paragraphs carry distinct gaps. |
| Single-paragraph request, not first draft | No | Same trigger; place at the top of the Diagnosis block. |
| Final polish | No | No. Sentence-level repairs only; route deeper teaching gaps to `Author questions`. |
| Response to reviewers | No | No. Repair exposition gaps inside flagged paragraphs under their reviewer labels; route section-level gaps to `Author questions`. |

The `Voice tics:` line lists three to five tics; the `Reader map:` line takes the form `starts with [what the reader knows]; must learn [central idea]; should leave with [takeaway]`. Each extraction line may read `none`; if all three are `none` and the passage clears the restraint checks, return it verbatim and say so in `Change rationale`. Extract the three before drafting the rewrite, from manuscript material only; anything the manuscript lacks goes to `Author questions`. The full definitions and the teaching-gap catalogue live in `references/exposition.md`; that file is the single source for this mechanism.

Then a numbered list. Each item is one structural or stylistic problem with a paragraph reference in square brackets. Cap at seven items, except on a whole-paper diagnosis-only pass (for example a cross-section consistency check, whose checklist lives in `references/consistency-checks.md`, or the whole-paper cold read, whose protocol lives in `references/cold-read.md`), whose value is exhaustiveness: there, report every finding, grouping findings by type with counts when the list grows long. Order by category (structure first, sentence-level last).

### 2. Revised text

The revised section in a single fenced block. No commentary inside the block: never mark an edit with an inline bracketed tag or editor label, which contradicts the clean block and creates a copy-paste hazard. If the user asked for feedback only, write `No rewrite requested.`

Immediately after the fenced block, add one mandatory `Added bridges:` line. Quote on it each sentence you added that states why an assumption, identification strategy, or validity claim holds (each such sentence must be built from material already in the manuscript per constraint 1, and each also gets an `Author questions` item asking the author to confirm it); write `Added bridges: None.` when there are none. The author reads the rewrite before the questions, so this flag lives next to what they read.

### 3. Change rationale

Open with `Word count: ~<before> to ~<after> (<approximate signed percent change>).` Counts are approximate, to the nearest ~10 words (for example `~139 to ~86 (-38%)`): get the direction and rough magnitude right rather than the exact figure, and compute the counts with a tool when one is available. If the rewrite grew, add a one-line justification on the next line.

Then one mandatory `References loaded:` line naming the `references/` files the revision sweep loaded for this section (see The revision sweep). It makes a skipped pass visible: list every reference a kept pass loaded, comma-separated by basename, and where a section gates a pass off say so briefly. On a feedback-only or other diagnosis-only pass the line still appears, naming the references the diagnosis consulted; it follows the word-count line when there is one and otherwise opens the block after the rationale bullets' header.

Then one line per non-trivial change in the form `before -> after, why`. The `why` must name a concrete reader benefit: a removed tell, a shorter form, given-new order, a fixed referent, a sharper claim, a corrected stress position, visible question, improved payoff, surfaced tension, an opened knowledge gap, an ABT spine in place of a list, stakes shown by consequence, a character in the subject slot, restored contrast, varied rhythm, a reunited clause core, a hedge deferred under the refinement test, kept calibration on a central claim, concrete anchor, repaired parallelism, consistent terminology, or clearer punctuation. For an exposition edit, name the teaching benefit: a restored inference, a term defined at first serious use, role before name, question before machinery, a concrete anchor from existing material, two stacked concepts separated, an explicit reader payoff, an abstract claim translated into its mechanism, or an exposed contrast with prior work. "Reads better", "smoother", or "more concise" with no named mechanism is not a reason; if that is the only justification a change has, revert it and keep the original. If no rewrite was requested, replace the change lines with brief rationale bullets for the top diagnosis items and omit the word-count line. If a rewrite was requested but no safe edits are possible, write `No safe edits under current constraints.` and explain in one line.

### 4. Author questions

Bulleted list. Each item is one unverifiable claim, missing evidence, numerical-claim change you flagged, terminology ambiguity, consistency risk, missing concrete anchor, unclear reader payoff, or logical gap, phrased as a question. Teaching gaps belong here too when the manuscript lacks the material to fix them in prose: a missing definition, missing intuition, missing example, missing mechanism, missing contrast with prior work, missing explanation of why the problem is hard, or missing reader takeaway. End every item with a question mark. If there are none, write `None.`

## Examples

- "Can you take a look at the introduction and see if it flows?" -> trigger; load paper context, apply the full diagnostic lens, return the four-section output.
- "Can you make this section a pleasure to read?" -> trigger; run the reader-experience pass after the logic checks, then revise without decorative flourish.
- "Make my introduction clearer for a non-specialist; it assumes too much." -> trigger; load `references/exposition.md`, run the exposition pass after argumentation, repair missing definitions and inferential bridges from material already present, and flag the rest in Author questions.
- "Just fix the typos in section 3." -> do not trigger; this is mechanical proofreading, not a research-paper copyedit.
- "Reviewer 2 says my methodology is unclear." -> trigger; load `revision_stage: response to reviewers`, apply the methodology lens, preserve analytical decisions.
- "Write me a discussion section based on these results." -> do not trigger; a drafted section asserts substance the skill cannot verify, which the master rule in Constraints forbids.