There is a familiar ritual when AI-generated writing sounds like AI: remove the em dashes, ban “delve,” tell the model not to say “it’s important to note,” ask it to vary sentence length, and finish with “write like a human.” Then you regenerate the answer and get essentially the same prose wearing different clothes.
The problem is bigger than a handful of suspicious words. Recent research on AI-assisted writing suggests that even after people manually edit LLM-generated drafts, the finished text can remain stylistically closer to machine-generated prose than to their own unaided writing. People are good at spotting obvious tells, but the deeper fingerprint comes from hundreds of smaller choices around rhythm, transitions, abstraction, sentence structure, explanation and emphasis.
That made me think we may be attacking AI writing at the wrong layer. Instead of asking “How do we make AI sound less like AI?”, a more useful question is “What should it sound like instead?”
There is a surprisingly good answer already sitting in public on the web.
Good writing systems already exist
Google has spent years deciding how developer documentation should work. Its style system covers terminology, procedures, global audiences, accessibility, examples, voice, links, UI language and a long list of small editorial decisions that together make technical documentation easier to use.
GitLab has a different system. Its documentation is supposed to be concise, direct, precise and searchable. GOV.UK starts from the task a citizen is trying to complete, rather than what a government department wants to explain. Microsoft emphasizes product writing that is warm but crisp. Mailchimp separates a stable voice from situational tone. Apple treats writing as part of the interface itself.
These are not clever prompts. They are editorial systems developed over years of real-world use.
That became the idea behind a project I published this week: Agent Stylebooks.
https://github.com/Neeeophytee/agent-stylebooks
The repository turns 11 established writing systems into reusable Agent Skills. Instead of telling an agent to “write professionally” or “sound more human,” you can give it a concrete editorial system designed for the kind of artifact you are producing.
Pick the writing system before the model picks one for you
LLMs already have writing defaults. Give a model some engineering notes and ask it to “turn this into documentation,” and it still has to decide how much context to add, where prerequisites belong, how warnings should be phrased, whether to address the reader directly, how much explanation is enough and how confident the language should sound.
“Professional” does not answer those questions. Neither does “human.” A stylebook does.
Imagine you have a README, some verified commands and a few notes from an engineer. You want a proper public API integration guide. The Google Developer Docs skill tells the agent to establish the reader’s goal, put prerequisites before dependent actions, use stable terminology, make commands copyable, avoid culturally specific idioms and include a way to verify success. It also tells the agent not to invent defaults, compatibility claims or product behavior that are not supported by the source material.
Now imagine an eligibility page for a government grant. The GOV.UK skill begins somewhere completely different: what decision is the person trying to make? Who qualifies? What will they need? What does it cost? How long will it take? What happens next? The purpose is not simply to make the prose shorter. It is to make a complicated process easier to act on without deleting important conditions or exceptions.
Both systems produce clear writing, but they optimize for different failures. That is exactly why one universal “good writing” prompt is not enough.
The 11 stylebooks
Google Developer Docs is for API documentation, setup guides and technical tutorials. Use it when developers need clear prerequisites, stable terminology, runnable commands and an obvious way to verify that something worked.
GOV.UK is for public-service information, eligibility pages and complicated transactional content. Use it when the most important thing is helping someone understand what applies to them and what they need to do next.
GitLab Docs is for concise product and engineering documentation. It is particularly useful when internal implementation notes need to become a maintainable reference rather than a long explanatory essay.
GitHub Docs is strong for product workflows and developer how-tos. Use it when permissions, prerequisites, actions, warnings and verification need to appear in a predictable order.
Kubernetes Docs is designed for infrastructure documentation where versions, namespaces, state changes and cleanup matter. A deployment tutorial is much more useful when the reader knows which version it applies to, what resource changes and how to verify or reverse the operation.
MDN Web Docs works well for teaching web technologies. It is useful when the reader needs both a technically accurate explanation and a small example that demonstrates the concept without unnecessary complexity.
Red Hat Docs fits enterprise procedures, runbooks and operational documentation. It helps separate concepts, procedures, references and troubleshooting instead of mixing them into one giant page.
18F Content focuses on digital public services, plain language and accessibility. It is useful for forms, applications and government workflows where confusing wording can directly prevent someone from completing a task.
Microsoft Writing Style works well for product help, UX copy and support content. A good example is an error message: rather than blaming the user or vaguely saying something failed, explain what happened and give a specific recovery action.
Mailchimp Content is useful for customer-facing education and product communication where personality is welcome but should never get in the way. A successful campaign can sound warm; a failed payment or security problem should prioritize clarity.
Apple Interface Writing is for buttons, alerts, permissions, settings and onboarding. It helps replace vague interface language like “OK” with copy that tells the user exactly what an action will do.
The topic does not determine the style
This became one of the most useful rules in the project. Suppose you are writing about Kubernetes. A deployment tutorial might use $kubernetes-docs, while a government page explaining whether companies qualify for a Kubernetes infrastructure grant might use $govuk. A button inside a Kubernetes management application might be better served by $apple-interface-writing.
Same subject, completely different writing problem.
That is why Agent Stylebooks recommends choosing the style based on the artifact and the user’s need, not the company or technology mentioned in the content.
Why package them as Agent Skills?
A prompt is usually a temporary instruction. A skill is a reusable capability that an agent can discover and load when it becomes relevant.
The Agent Skills format is deliberately simple: a skill lives in a directory centered around a SKILL.md file. That makes it possible to keep editorial guidance available without pasting thousands of words into every conversation. The agent can discover that a GOV.UK or Google Developer Docs skill exists and load the detailed instructions only when the job calls for them.
That is a much cleaner abstraction than maintaining a collection of giant prompts.
Style should never override facts
One principle runs through the entire repository: change the presentation, not the substance.
A writing skill should not make an API explanation clearer by inventing a default. It should not simplify an eligibility page by deleting an exception. It should not make an error message friendlier by promising that a user’s data is safe when nobody has established that fact.
This matters because good style can make hallucinations more convincing. A polished falsehood is still a falsehood, so the skills explicitly preserve facts, code, commands, product terminology, versions, permissions and uncertainty.
This is not really about sounding human
I increasingly think “make it sound human” is the wrong target. Humans do not have one writing style. We write API references, government forms, error messages, essays, onboarding screens and birthday cards differently because those artifacts have different jobs.
The more useful goal is intentional writing. Choose an editorial system that fits the task, then give the agent enough constraints that it does not silently fall back to its default prose.
Instead of saying, “Make this less AI-ish,” say, “This is an API setup guide for developers. Use the Google Developer Docs stylebook.” Instead of asking for a government page to sound simpler, tell the agent that the reader needs to decide whether they qualify and use GOV.UK.
That small change shifts the question from how should this prose sound? to what does this piece of writing need to accomplish?
Try Agent Stylebooks
You can browse the available skills with:
npx skills add Neeeophytee/agent-stylebooks --listInstall a specific stylebook with:
npx skills add Neeeophytee/agent-stylebooks --skill govukThen use it normally:
Use $govuk to rewrite this eligibility page around what the user needs to decide.Or:
Use $google-developer-docs to turn these implementation notes into a setup guide.The first release includes 11 stylebooks, installation instructions, examples, provenance information, compatibility notes and a style-selection matrix.
You can find the project here:
https://github.com/Neeeophytee/agent-stylebooks
AI writing probably does not need another universal “humanizer.” It needs better editorial choices, and many of the best writing systems have already been developed. They were simply written for human editors first.