agentleFS
AnastasiyaWAnastasiyaW/claude-code-config/skills/writing/humanize-english/SKILL.md

humanize-english

Skill213 starsChanged 3 days agoMITView on GitHub

Edit English drafts for clear, natural language while preserving facts, uncertainty, technical meaning, citations and genre. Use when: humanize this text, remove AI-style filler, improve English prose, or edit an English article before publication. Not an authorship detector or a promise to bypass one. For Russian use humanize-russian; for thesis/evidence and structure use article-structure-review.

We split this skill into the rules it gives an agent

7 rules. About 0 are common, 7 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈7

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Keep the user's intended voice and the destination's format.

    line 18
  2. Distinctive:

    Never invent a count, quote, interview, personal experience, experiment, failure, comparison or source to make prose more vivid.

    line 24
  3. Distinctive:

    Add specificity only when the supporting evidence supplies it.

    line 26
  4. Distinctive:

    Remove empty intensifiers and duplicated ideas.

    line 55
  5. Distinctive:

    Do not supply a result that the source does not establish.

    line 58
  6. Distinctive:

    Every changed factual assertion still maps to the supplied material or a source actually checked for this task.

    line 81
  7. Distinctive:

    No invented testimony or detector-evasion claim was added.

    line 86

≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “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

Clear, Natural English Editing

Improve the reader's understanding, not a detector score. A good reference can have repeated terminology, regular tables, definitions and no anecdote. Keep the user's intended voice and the destination's format.

Facts Are Not Style Material

  • Preserve supplied numbers, units, dates, versions, names, citations, negation, uncertainty and claim scope. Do not silently update a historical date.
  • Never invent a count, quote, interview, personal experience, experiment, failure, comparison or source to make prose more vivid.
  • Add specificity only when the supporting evidence supplies it. If no measurement exists, retain uncertainty or remove an unsupported claim. An unsupplied number is not an improvement over a vague quantity.
  • Label illustrative scenarios as hypothetical. Do not present them as a real case study or treat their invented values as proof of a product claim.
  • Preserve identifiers, executable code and technical obligations. Words such as may, must, can and will are not interchangeable style alternatives.
  • Reuse provided facts without asking the user to repeat them. Research a material factual gap when research is in scope; otherwise identify the gap without manufacturing an answer or blocking supported edits.

Match the Genre

GenreUseful editingAvoid forcing
technical referenceexact terms, clear conditions, scannable structureslang, story openings, rhetorical questions, sales CTA
explanation/tutorialprerequisites and action/result sequencean untested command described as verified
analysisseparate observation, inference and limitsstronger causal claims than the evidence supports
personal narrativethe author's supplied experiences and voiceinvented first-person testimony
marketinga supported benefit and relevant next actionfabricated testimonials, percentages or guarantees

Contractions, fragments, humour, analogies and direct address are options, not quotas. Use them when they fit the audience and improve comprehension. Parallel lists and consistent terminology can be desirable in documentation.

Editing Procedure

  1. Identify the reader's task, genre, source material and protected facts from the existing request and draft. Do not add an unnecessary intake questionnaire.
  2. Remove empty intensifiers and duplicated ideas. Use direct verbs when meaning is preserved; keep connectors that express real causality or contrast.
  3. Clarify who acts, on what, under which conditions and with what result. Do not supply a result that the source does not establish.
  4. Fix awkward rhythm where it hinders reading. Do not maximize variation, enforce a paragraph pattern or replace terms to appear less predictable.
  5. Compare input and output for semantic changes. Check quantities with their units, denominator, time frame and uncertainty, not just the numeral.
  6. Return the edited text and any necessary factual caveat. Once the edit is sufficient, continue the remaining requested publication workflow rather than starting another stylistic pass automatically.

Examples: Same Facts, Clearer Prose

Supplied textFaithful edit
In order to load the file, the user must select Open.To load the file, select Open.
The tool may reduce processing time; no benchmark is available.The tool may save processing time, but no benchmark is available.
Some testers reported failures. The sample size was not recorded.Some testers reported failures; the sample size was not recorded.
On 2026-09-01, 12 of 40 runs failed with version 2.1.With version 2.1, 12 of 40 runs failed on 2026-09-01.

These are editing fixtures, not results from a deployed product. Unknown sample size stays unknown; a date, denominator and version do not disappear for fluency.

Verification

  • Every changed factual assertion still maps to the supplied material or a source actually checked for this task.
  • Conditions, uncertainty, negatives, numbers, units, dates, versions and code are preserved unless an evidence-backed factual correction was requested.
  • The result helps its intended reader without an unrequested genre change.
  • No invented testimony or detector-evasion claim was added.

A no-change verdict is valid for an already clear passage. Do not add numbers, questions, opinions, deliberate errors or fake admissions to satisfy a score.

Gotchas

  • Detector score as evidence: it establishes neither authorship nor factual accuracy. Do not promise an undetectable edit.
  • Replacing every vague quantity: guessing a plausible percentage fabricates evidence when the sample size is unknown.
  • Forced informality: slang can make a reference harder to understand, particularly for readers using English as an additional language.
  • Synonym churn: repeating a technical term is safer than creating a false distinction through alternate names.
  • Example contamination: a skill example is not an event that happened to the user or author.

Troubleshooting

SymptomCheckCorrection
polished but unsupported claimsource scope and conditionsrestore supported meaning or remove the claim
bureaucratic phrasingaction and actoruse a direct sentence without changing obligations
repetitive textrepeated meaning versus necessary termscut redundancy, keep precise terminology
reference sounds like an advertisementrequested genreremove promotion and invented narrative
detector flags the passageactual writing and detector limitationsrepair evidenced defects, not a guessed authorship score

Sources and Maintenance

Reviewed 2026-09-06. Owner: the existing writing-skill maintainers. Change through canonical Git, focused before/after fixtures, independent review and the supported installer; retain the prior revision and installation backup for rollback. Refresh sources when guidance changes or a factual/genre regression is observed, not by automatically rewriting working prose on a schedule.

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.