/anti-defensive-writing

name: anti-defensive-writing
description: "Remove audit, defensive, self-critical, developer-facing and commitment writing from manuscripts, Supplementary Information, legends, table notes, data/code statements and figure content. Preserve numbers, definitions, reproducibility facts, mandated statistics, null results and conditions that determine reported values. What is load-bearing depends on the target venue: an ML conference needs the no-leakage sentence a journal pass might cut. Use after claim hierarchy is settled and before sentence polishing, when a draft reads like an audit report, rebuttal, self-critique or repository README, or on requests to de-audit, cut hedging, remove developer notes or promises, 去审计、审计味、防御性写作、自我批评、自我限制、评判式写作、去包装、太多免责、写得太怂、太啰嗦、让语气更肯定、面向开发人员、代码路径、文件名、事前承诺. Also prevents these voices from being added during editing."
license: MIT

Anti-Defensive Writing

A research paper argues from evidence. It does not keep an audit log of its own project, argue with an imagined reviewer, criticize itself, document its repository, or make promises. This skill removes those voices from every part of the paper, Supplementary Information included, and keeps everything a reader needs to understand, trust and reproduce the work.

The paper should feel controlled because the design is clear, not because the authors keep saying that it is controlled.

Read **What stays** before deleting anything, and **Local integration** for where this skill sits in the `paper-workflow` chain.

Rule zero: do not add it

Most audit and defensive text is added during editing, not during drafting: an edit fixes an ambiguity, answers a co-author or reviewer comment, or adds provenance "to be safe". While editing any text:

• Add no qualifier, disclaimer or provenance note unless the sentence would otherwise be literally

false.

• Fix an ambiguity with a precise definition, not with a caveat. "Labels A to D denote four dataset

regimes" beats a sentence explaining what the labels should not be taken to mean.

• A request for a small change gets a small change: one sentence, not a protective paragraph around it.
• Do not weaken a claim in advance because a control or baseline is not yet in the draft. Whether a

claim needs qualifying is decided when that evidence arrives.

The six voices

Each voice has recognition cues and one fix. A cue is a candidate, not a verdict; classify it with the procedure below before changing it.

1. Audit voice: the project's process leaking into the paper

The text reports how the work was run and checked instead of what it found. Typical cues:

• process status: locked, frozen, hashed, scored once, fixed in advance, deterministic assignment,

identical comparison arms restated, configuration hashes;

• verification talk: verified rather than assumed, the numerical check that, to verify, sanity check,

leakage-safe, implementation verification, the pipeline was confirmed to;

• provenance qualifiers in Results: post hoc, added after the original evaluation, historical locked

recomputation, primary arm of the original design;

• internal vocabulary: phase and gate names, PASS or FAIL verdicts, retired metric names (files,

folders and code names are the developer voice, below);

• checker language presented as a finding: "no additive cost is resolvable".

Fix. State the design fact once, as a fact ("The evaluation split was held out from model selection"), in the section where the reader needs it. Move reproducibility detail to Methods or SI. Delete governance language outright.

2. Defensive voice: writing to an imagined reviewer

The text negotiates with a critic who is not in the room. Typical cues:

• negations of unmade claims: does not establish, does not imply, is not a, should not be read as,

we do not claim, this is not to say, not intended to;

• reflexive contrast: rather than, instead of, not X but Y, where the contrast is not the argument;
• reassurance repeated at every mention: no leakage, prespecified, independent of the answer, why an

artifact cannot explain the result;

• instructions to the reader: for completeness, to be clear, it should be noted, so that the

instability is visible rather than asserted, so a reader can see where the line falls;

• counterfactual paragraphs: "Had the target been X, the reference would need Y. This statement is

specific to Z; it does not relabel W";

• compound sentences that pack a claim together with every exception and control a reviewer might

raise.

Fix. Say what the object is and what the result shows: positive scope. If a limit changes a reported number or a reporting decision, keep it once, where it acts, in positive form. Split a reviewer-defence compound sentence into its claims.

3. Self-critical voice: the paper judging or apologizing for itself

The text evaluates its own shortcomings instead of reporting facts. Typical cues:

• confessions of absence: could not be identified, not exposed, not identifiable, not available, no

record exists;

• self-grading: not directly comparable, unstable, only a small fraction, remains at null, failed to,

unfortunately, we acknowledge;

• listing what the study did not use: datasets, runs, methods or resources that played no part;
• retreat framed as justification: "we keep it linear because deep models do not yet outperform

linear baselines";

• limitations placed in Results, legends or SI notes, or itemized at length in the Discussion;
• verdict columns in tables: a "Qualification" or "Status" column that grades each row ("positive

interval", "interval crosses zero", "within tolerance", "exploratory; small subset").

Fix. Report the fact neutrally, or drop it if no reader needs it ("All data were obtained from the X collection"). Describe what was used, not what was not. Recast a defended choice as the design decision it was ("A linear map is the reference estimator, so that supervision can be separated from capacity"). Where the