Claude writes for any reader. This skill makes it write for yours.
humanizing-writing is a Claude Code skill that guides how Claude writes prose (docs, emails, posts, pull request descriptions) so it doesn’t read as machine-written. It works while Claude is writing, and it does not change AI-detector scores.
npx skills add AshwinSathian/humanize-writing-skillFree, MIT, version 2.1.0. Two other ways to install.
Rate limiting plays a crucial role in maintaining the stability and reliability of modern APIs. It's not just a defensive measure — it's a foundational component of good API design. By implementing rate limits, engineering teams can ensure fair usage, protect backend infrastructure, and foster a more predictable system for all consumers. Additionally, rate limiting helps mitigate the risk of cascading failures, which can occur when a single misbehaving client overwhelms shared resources. Furthermore, well-designed rate limiting strategies typically incorporate several key elements: clear error messaging, transparent limits, and graceful degradation. Despite the added complexity it introduces, rate limiting remains a testament to thoughtful, resilient system design, and its importance cannot be overstated in today's increasingly interconnected digital landscape.
119 words, in the style models wrote in 2023.
Rate limiting plays a crucial role in maintaining the stability and reliability1 of modern APIs. It's not just a defensive measure — it's a foundational component of good API design.2 By implementing rate limits, engineering teams can ensure fair usage, protect backend infrastructure, and foster a more predictable system3 for all consumers. Additionally,4 rate limiting helps mitigate the risk of cascading failures, which can occur when a single misbehaving client overwhelms shared resources5. Furthermore,4 well-designed rate limiting strategies typically incorporate several key elements: clear error messaging, transparent limits, and graceful degradation6. Despite the added complexity it introduces, rate limiting remains a testament to thoughtful, resilient system design, and its importance cannot be overstated in today's increasingly interconnected digital landscape.7
- 1Says it matters and not why.
- 2Denies a claim nobody made.
- 3One point, said three ways.
- 4Connectors that would fit any text.
- 5The mechanism, buried in sentence four. Lead with it.
- 6Three items, three different things. The list stays.
- 7A closing line with no fact in it.
Rate limiting exists because one misbehaving client can overwhelm resources that every client shares, and the failure then spreads to all of them. With a limit in place, that client's extra requests are rejected (HTTP 429) and the others keep working. A well-designed limit returns a clear error, publishes its limits, and degrades gradually. It also makes the API more complex.
61 words. The one addition is 429, the standard HTTP status for a rate-limited request. Every other fact was in the original.
At a glance
- What it is
- One SKILL.md of about 1,150 words that Claude Code loads when it writes a paragraph or more.
- Who it’s for
- Anyone who has Claude draft docs, READMEs, reports, emails, posts, or pull request descriptions.
- Version
- 2.1.0, released 9 October 2026.
- Price
- Free and open source under the MIT licence.
- Tested on
- Claude Haiku, Sonnet, and Opus, in English.
- What it won’t do
- Change an AI-detector score, or rework your own writing when you asked for a typo fix.
Why a list of banned words isn’t enough
Most humanizer tools come down to a word list: swap “delve” for something else, cap the em dashes, done. That works until the list goes stale, and it goes stale quickly. Wikipedia’s list of AI vocabulary is now sorted by model era, and its list for mid-2025 onward is four words long.
What replaced the old words? In July 2026 The Economist had ChatGPT, Claude, Gemini, and Grok rewrite its own articles, and compared 55,940 sentences with human journalism and novels. The signal now sits in long words, long sentences joined with “and”, and thin punctuation. The em dash has narrowed to Claude alone.
2023
- “delve”, “tapestry”, “testament to”
- “Moreover”, “In conclusion”
- “In today’s fast-paced world”
- The em dash, read as a sign of any model
2026
- Long, noun-built sentences chained with “and”
- Metaphor where a plain statement would do
- One-line closers and fragments for effect
- “Not X but Y”, and lists of three
We found this out the awkward way. Version 1.x of this skill told Claude to vary its sentence rhythm on purpose, and a model told to do that writes short sentences for effect — the closer, the fragment, the colon reveal. The skill had been taking text in the 2023 style and rewriting it in the 2026 one. Version 2.0.0 is the rewrite that followed.
Eleven rules, and one that never bends
Text reads as machine-written when every choice in it would suit any reader and any subject. The rules point Claude at this reader and this subject, in the places where the default shows most.
- Claims
- Make them specific and checkable: the number, the command, the file, the error text. Say each thing once.
- Words
- The plain verb and the common word. Where a figure of speech stands in for a fact, write the fact: “removing this check lets empty orders through”, and not “this check is load-bearing”.
- Sentences
- Length follows the content. Asides go in commas or parentheses. A doubtful claim gets one hedge, at the claim.
- Endings and structure
- Stop when the content stops. Lists are for what a reader scans or follows in order, and the rest is paragraphs.
The rule that never bends is the one against inventing. No made-up figures, quotes, incidents, or sources, however specific they’d make the draft sound. The others are defaults for expository prose, and the skill names ten cases where they give way: an explicit request from you, someone else’s text, your own voice, API reference, summaries, fiction and speeches, legal text, marketing copy, other languages, and anything shorter than a paragraph.
Tested blind, with the losses on record
Fresh Claude instances wrote three pieces — an explanation of database indexes, a blog section arguing for feature flags, a pull request description — with no skill, with version 1.1.1, and with the current rules. Model judges then read shuffled pairs with no labels and said which they’d rather publish. Sonnet and Opus wrote the first round, and Haiku wrote the second.
| Skill preferred over | Opus judge | Sonnet judge | Haiku judge |
|---|---|---|---|
| No skill, Sonnet and Opus writing | 5 of 6 | 5 of 6 | not run |
| No skill, Haiku writing | 3 of 3 | 3 of 3 | 3 of 3 |
| Version 1.1.1, Sonnet and Opus writing | 5 of 6 | 4 of 6 | not run |
| Version 1.1.1, Haiku writing | 3 of 3 | 2 of 3, one tie | 2 of 3 |
And where did it fall short? In the first round both judges preferred the no-skill pull request description, because the skill’s version was a “Summary” and “Changes” skeleton whose bullets repeated the summary. In the Haiku round, two of three judges flagged the skill’s feature-flag passage for stating the team’s current practice as fact — the kind of thing the rule against inventing is there to stop. A follow-up on four new tasks found the same slip in 2 of 9 passages, and a reworded rule didn’t clear the bar we’d set for it, so the rule stands and the advice is to check what a draft says about your own team.
Eighteen pairs is a small sample, and the judges are Claude models. No AI detector was run.
Your voice outranks the rules
Since 2.1.0, when Claude drafts in your voice from a writing sample or a voice profile, your habits win. If you use dashes, rhetorical questions, or “not X but Y”, the draft does too, at about your rate. The repository has one worked profile, mine, built from about 55,000 words I wrote without AI assistance. It describes habits as counts and quotes none of the writing.
It doesn’t get all the way there. In a test of that profile the drafts moved towards my use of “we” and of questions, but their sentences stayed shorter than mine (15 words on average against 17 to 18), and they used no dashes where I use five or six per 1,000 words.
Install
Three ways, and none of them needs an account or a review.
With skills.sh
npx skills add AshwinSathian/humanize-writing-skillAs a Claude Code plugin
/plugin marketplace add AshwinSathian/humanize-writing-skill
/plugin install humanizing-writing@humanize-writing-skillAs a symlinked clone
git clone https://github.com/AshwinSathian/humanize-writing-skill.git
ln -s "$(pwd)/humanize-writing-skill" ~/.claude/skills/humanizing-writingTo check it’s working, give Claude a short, obviously AI-toned paragraph and ask for something similar. The skill fires on prose of a paragraph or more. It isn’t meant to fire on a one-line commit subject or a chat reply.
Questions people ask first
Does it get text past AI detectors such as GPTZero or Pangram?
No, and we'd rather you read that here than find out later. Current detectors are trained classifiers. Xu et al. (2026) found that GPTZero and Pangram often pass text from base models as human and flag text from the instruction-tuned versions of the same models, which suggests they track the marks of instruction tuning itself. A style guide read by an instruction-tuned model doesn't change that tuning. Pangram also reports catching the output of nineteen humanizer tools more than 90% of the time, though that is the vendor's own figure. If you need a detector score, this is the wrong tool. It's built for the person who reads the text.
How is it different from blader/humanizer and other humanizer skills?
Two things, mainly. The widely used ones (blader/humanizer, avoid-ai-writing, stop-slop, no-ai-slop) are rewrite tools you run over a finished draft, and this one applies while Claude is writing. It also has a Scope section that says where the rules stop: API reference, legal text, fiction, marketing copy, someone else's writing, your own voice. And it's weaker than blader's in one clear way — blader reports a blind preference test of 16 out of 16, and ours is 18 pairs over two rounds, judged by Claude models.
Does it ban "delve", em dashes, or other words?
No. Word lists go stale. Wikipedia's list of AI vocabulary for mid-2025 onward is four words long, and the same page records that "delve" fell sharply in 2025. The rules here are about claims, sentence shape, and endings. An em dash is fine where a comma would hide the break, and a precise term such as "idempotent" always stays.
This site was written with the skill
Every page here was drafted by Claude with the skill loaded and my voice profile applied. Each figure was checked against a file in the repository, and the sources sit in the margin beside the claims.
How close did it get to the profile? These are the counts for the paragraphs on this site’s five written pages, from the same script the validation used. The script reports numbers and gives no verdict.
| Measured on 10 October 2026 | This site | My essays |
|---|---|---|
| Mean sentence length | 16.2 words | 18 words |
| Sentences of five words or fewer | 1 in 8 | 1 in 9 |
| Dashes per 1,000 words | 3.1 | 6 |
| “Moreover”, “Furthermore”, and the like | none | not counted |
So the sentences are still shorter than mine and the dashes fewer, which is the miss the profile’s own test found.
Two essays cover the thinking at more length: why word lists fail (August 2026), and what changed in 2.0.0 (October 2026).
The skill makes judgement calls, and some will be wrong. If it mangles something of yours, open an issue with the before and after text. That’s more useful than a star.