When I first looked at agent-style, what caught my attention wasn’t just that it has 21 rules. Anyone can write rules; the hard part is how to really integrate those rules into the AI’s workflow.
agent-style does exactly that: it embeds writing rules into different AI Agents and then gives you a style-review Skill for a second round of editing.
We should clarify its context first.
The README states its applicable scenarios mainly involve English technical writing: API docs, design docs, papers, grant proposals, READMEs, runbooks, commit messages, postmortems.
Novels, poetry, marketing copy, or emotionally charged long-form writing are not its focus.
So this article doesn’t recommend it as a tool for Chinese public accounts.
What I want to analyze is its productized approach: the rule set is in RULES.md, a compressed version in docs/rule-pack-compact.md, the review entry point in skills/style-review/SKILL.md, and the command line uses agent-style review --audit-only FILE for mechanical checks.
Together, these parts form the core of what I want to unpack here.
1. Clarify the source first
The agent-style repository is here:
https://github.com/yzhao062/agent-style
It’s also published as Python and npm packages.
If you just want AI to help you install it, you can give the repo URL to the AI:
https://github.com/yzhao062/agent-style
Then say:
Help me install agent-style and enable the writing rules suitable for this AI tool in the current project.
This article mainly looks at these files:
README.md
RULES.md
docs/rule-pack-compact.md
skills/style-review/SKILL.md
First the rules, then how they are embedded into the tool.
2. The 21 rules are divided into two categories
agent-style splits the rules into two groups.
The first group has 12 classic writing rules.
Sources include Strunk & White, Orwell, Pinker, Gopen & Swan.
For example:
- Don’t assume the reader knows your implicit knowledge.
- Avoid passive voice when the actor is important.
- Use concrete words instead of abstract ones.
- Remove unnecessary words.
- Avoid clichés.
- Don’t overstate when evidence is weak.
- Break up long sentences and vary sentence length.
The second group has 9 rules derived from observing AI outputs.
This group is closer to the typical “AI flavor” we often see:
- Don’t force non-list content into bullet points.
- Don’t treat em dashes as default punctuation.
- Don’t start consecutive sentences the same way.
- Don’t overuse Additionally, Furthermore, Moreover.
- Don’t end every paragraph with a summary sentence.
- Factual judgments need evidence or citations.
Putting these two groups together reveals its judgment: technical writing problems don’t just come from AI but also from old habits.
Readers’ backgrounds aren’t explained, actions hidden in passive voice, insufficient evidence yet overstated claims—these problems existed before. LLMs just amplify them and add new issues like excessive bullets, stacked transition words, and em dash overuse.
So it doesn’t just create an “anti-AI word list.” It first fills in the rules technical writing should already follow, then tackles common bad habits in model outputs.
3. It’s not just about post-writing polishing
agent-style offers two usage paths: one before writing, one after.
Before writing, it embeds the rules into the current AI tool’s context. This path is called soft enforcement in the README. Simply put, it lets the AI see the rules when drafting the first version to reduce detours.
After writing, it provides style-review.
This is an opt-in second-round review Skill. After the document is written, you have it review for issues like long sentences, vague words, excessive bullets, and insufficient evidence.
This design is more reliable than just saying “please follow these 21 rules.” Rules before generation only reduce error chances but can’t guarantee the model always follows them; the review step offers a second interception opportunity.
4. How style-review works
The process is described in skills/style-review/SKILL.md.
When reviewing a single file, it roughly goes through two layers.
The first layer is deterministic auditing. It calls:
agent-style review --audit-only FILE
This part checks mechanical rules like em dashes, transition words, long sentences, title capitalization, and common fluff.
The second layer is semantic auditing.
Some rules can’t be judged by regex alone.
For example:
Will the reader not understand this term?
Is there evidence for this factual claim?
Is this sentence overstating the evidence?
These require the model to combine rules and examples to judge.
After merging results from both layers, it outputs a scorecard. If the user agrees, it writes a FILE.reviewed.md.
This file naming detail is worth copying: it doesn’t directly modify the original file. Reviews should be reversible, and the original should be kept, especially for team docs and long public articles.
5. Why it suits technical writing
Technical writing often has two common problems.
One is that readers simply don’t understand. Authors assume too much background knowledge, immediately piling on abbreviations, method names, and internal jargon.
The other is writing that flows well but lacks factual support.
For example, phrases like “significant improvement,” “industry-leading,” or “proves something” look like conclusions but lack evidence on closer inspection.
agent-style is sensitive to both.
It places RULE-01 very early: don’t assume readers share your implicit knowledge.
It also marks RULE-H as a key rule: factual judgments must have citations or concrete evidence.
This is also how it differs from ordinary “remove AI flavor” tools: it first asks if the reader can understand and if the facts hold up, then it deals with sentence aesthetics.
6. What can be learned for public account writing
Although agent-style mainly targets English technical writing, some rules can be directly applied to public account writing.
For public account writing, I’d first use it to check three things.
First, is the reader’s state clearly explained? When deeply analyzing a Skill, readers may not understand source code or may only know some command line basics. The article can’t assume they all know what CDP, adapter, frontmatter, or CLI mean.
Second, is factual judgment supported? When explaining a Skill’s implementation, you need to read source code, check scripts, confirm repo structure. If you haven’t seen something, say so; don’t invent an unverified mechanism just to make the article smoother.
Third, is the structure overly listified? Public account articles can use lists, but if the whole article feels like a README.md feature list, readers will quickly get tired. Some paragraphs should just move on without adding an empty summary sentence.
7. Insights for writing Skills
What’s most worth learning from agent-style is how it turns rules into something actionable.
It doesn’t just say “please follow these 21 rules.” It anticipates questions like:
How to integrate with different AI tools?
Which rules can be mechanically checked?
Which rules require model judgment?
How to save reviewed files?
How to avoid overwriting originals?
How to benchmark effectiveness?
If it’s just for personal use, one SKILL.md might be enough.
If you want others to use it, you have to think further:
- Where to put it after installation?
- How to confirm it’s active?
- Will it mistakenly modify originals?
- How can users see before/after differences?
- Which rules can be auto-checked?
- Which rules need manual judgment?
A good Skill ultimately comes down to these small details, not just a few catchy slogans.
8. My judgment
agent-style isn’t suitable for directly porting to Chinese public accounts. Its context is English technical documents, and many rules clearly favor English.
But it’s very useful for learning how to engineer writing rules.
It breaks style rules into a set of things that can be referenced, installed, checked, and reviewed again. For me, its insight is pushing “avoid AI flavor” one step further.
Don’t rush to judge if something sounds AI-like. First see if the reader can understand, if the facts hold up, and if the sentence clearly conveys specifics.
If these are done well, the article usually won’t feel so vague.
