academic-humanizer: an editing pass for AI-assisted papers and NSF/NIH proposals

The problem: AI drafts read generic, and generic humanizers flatten the precision

The README is explicit about the failure mode it targets. AI-assisted drafts, in the authors' experience, come out "generic and verbose," with openers like "In recent years...", inflated phrasing, and over-long sentences, and they drift from the author's own voice. That is a familiar complaint. The more specific claim is the second one: existing humanizer tools are built for blogs and marketing, so running one on a paper or an NSF proposal "flattens the precision along with everything else." Hedging that is doing real work, passive voice where the field expects it, defined symbols, and the exact strength of a verb relative to the data are all things a general-purpose de-AI filter will happily rewrite.

The audience is narrow and identifiable. It is researchers who already use AI for drafting and who submit to venues and funders where the wording carries weight: the README's own badges name NSF CAREER and NIH R01, and the example set includes a general pass, an NIH Specific Aims page, and a funded NSF CAREER summary. If you write blog posts, this is not for you. If you write papers and grant proposals and you care that "prove" does not silently become a synonym for "show," it is aimed at you.

Six layers, and the audit-to-rewrite loop in SKILL.md

The mechanism is a layered rule set, not a model. The README lists six: a general AI-tell catalog, academic-specific tells, preservation of scholarly conventions, claim-to-evidence matching, voice and venue calibration, and a funding-proposal mode for NSF/NIH structure, first-page primacy, and claim-to-feasibility. The audit-then-rewrite loop that applies them is defined in SKILL.md, which is the only file the README tells you to point your agent at.

The ordering matters more than the list. Layer 1 is reused from blader/humanizer, a general-purpose MIT-licensed humanizer for blog, casual, and encyclopedic text; the academic layers sit on top of it. So the general tells are filtered first and the academic constraints act as a second gate. Layer 3 is the one that keeps the tool from being destructive: it preserves evidence-tied hedging, passive voice where it fits, first-person "we," definitions, symbols, and every citation. Layer 4 is the constraint people will actually feel day to day: no verb stronger than the data, so "prove" becomes "show empirically," and vague magnitudes become attributed ranges. Layer 5 is what makes it personal rather than universal, and the README says so plainly: "The rules here reflect one group's voice."

Two things are worth flagging. First, the six layers are described in prose, and the README does not publish the rule count, the prompt length, or how conflicts between layers resolve. If you want to know whether Layer 4 outranks Layer 3 when a strong verb is also evidence-tied hedging, you have to read SKILL.md. Second, the before/after example is illustrative, not measured. The README shows a paragraph of "remarkable success" and "cutting-edge techniques" collapsing into four short sentences about adaptation, soft supervision, and cross-domain knowledge. That is a demonstration of intent, not a benchmark, and no accuracy or acceptance-rate figure appears anywhere in the material.

Install: a git clone into the Claude skills directory

There is no package manager step. The README gives one command:

git clone https://github.com/AIScientists-Dev/academic-humanizer ~/.claude/skills/academic-humanizer

That places the repository where Claude Code looks for skills. The README states it is "a plain SKILL.md plus examples," so the same directory also works as a skill or system prompt for Codex and MorphMind, and the instruction for those is simply to point your agent at SKILL.md. There are no retrieved releases, so the clone is the install path and the default branch is main. The badge in the README says version 0.3.2, which is the only version marker I can confirm; there is no changelog in the supplied material, so I cannot tell you what changed between 0.3.1 and 0.3.2.

Invocation is a slash command with a paste or a file reference:

/academic-humanizer [paste a section, or point at main.tex] # optionally: "match my voice from prior_paper.pdf; target venue: ICLR"

The optional line is where the personalization happens: a prior paper for voice matching and a target venue for calibration. Grant mode is a separate mode rather than a flag, and the README does not give a config key for switching it. It says the mode keeps the vision a paper would trim and concentrates effort on the first pages, "since that's what reviewers score."

What it will not do, and where it is the wrong tool

The README's ethics section is unusually direct, and it doubles as the limitation list. The tool does not generate findings, invent data, or change citations, and it is "not designed to evade AI-use detection." Using it does not remove your disclosure obligation, and the README tells you to follow the venue's policy. If your reason for wanting a humanizer is to get past a detector, this is the wrong tool and the authors say so.

The harder limitation is calibration. Layer 5 depends on you supplying prior work and a venue, and Layer 1 is inherited from a general humanizer built for blogs and encyclopedic text. That catalog will not know your field's conventions. In some subfields, "we" is standard; in others it is contested. Passive voice is a tell in a blog post and a norm in a methods section. The README acknowledges this by telling you to fork and adapt: point it at your past papers, keep the checks that fit, adjust the rest. Out of the box, on a field whose conventions differ from the authors', it can push your prose toward one group's voice rather than yours.

Two more boundaries. It is an editing pass, not a verifier: it will not check that a citation supports the sentence it is attached to, only that the citation survives untouched. And it is not a submission-requirements tool. The README states that Layer 6 distills the "stable" structure of NSF and NIH proposals and directs you to the NSF PAPPG and the NIH Write Your Application pages for current, binding requirements such as page limits, formatting, and deadlines. Treat anything it says about structure as a starting heuristic, not as a substitute for the funder's own document.

Against blader/humanizer and ARMS: narrower scope, different job

The README names two related projects, and the comparison is honest about what each does. blader/humanizer is MIT-licensed and focuses on general AI-writing patterns for blog, casual, and encyclopedic text. academic-humanizer reuses its Layer 1 catalog and extends it for academic prose. The practical difference is what happens after the general tells are removed: blader/humanizer stops there, while this project adds claim-to-evidence matching and a preservation layer for scholarly conventions. Run the general one on a paper and the precision goes with the tells, which is the problem the authors set out to fix.

koaeraser/ARMS is a different kind of thing entirely. The README describes it as an autonomous pipeline for statistics and methodology papers, going from idea to a validated, revised manuscript, and says it informed the claim-evidence and numerical-precision emphasis here. So ARMS covers the whole research-writing pipeline; academic-humanizer is, in the authors' words, "the narrower piece: a single-purpose editing pass." If you want help developing an idea into a manuscript, this is not that. If you have a draft and want one pass over its language, the narrower scope is the point. Neither comparison is a quality ranking, and the README does not offer one.

Maintenance, licence, and what a fork actually costs

The licence situation needs care. The README's badge and its final section both say MIT, and the acknowledgments note that blader/humanizer is MIT too. But the repository metadata supplied for this review reports the licence as NOASSERTION, which means the licence could not be automatically identified from the repository contents. Those two signals disagree, and the disagreement is not something I can resolve from here. If you plan to reuse the rules or ship a modified version, read the LICENSE file in the clone and confirm the terms yourself. I am not giving legal advice, and the metadata mismatch is exactly the kind of thing to check before you build on it.

Maintenance cost is low in the ordinary sense and higher in the personalization sense. There is no build step, no dependency manifest, and no runtime: the artifact is a SKILL.md plus examples, so upgrading means pulling main. The real recurring cost is the calibration work the README asks for. Pointing the skill at a few past papers and pruning checks that do not fit your field is a manual pass, and you will want to repeat it when your venue or your funder's structure changes. Layer 6 is the one most exposed to drift, because NSF and NIH requirements change on their own schedule and the README already routes you to the source documents rather than promising the skill tracks them. If you fork, that maintenance is yours.

Editorial conclusion

Adopt it if you already draft in Claude Code or Codex and want a single editing pass that trims generic AI phrasing while leaving citations, numbers, and evidence-tied hedging untouched. Do not adopt it if you need a detector-evasion tool, a citation checker, or something that works without an agent runtime: there is no standalone binary and no release artifact. Before you rely on it, open SKILL.md and confirm that its Layer 1 tell catalog and Layer 6 NSF/NIH structure match the conventions of your own field and the current PAPPG, since the README itself points to the NSF and NIH pages for binding requirements.

Official sources

1. AIScientists-Dev/academic-humanizer on GitHub
2. Issues
3. Project website
4. README