Recently, while revising articles for my public account, I had a clear realization: removing the AI feel can’t be done by just deleting words.
Deleting a few conjunctions, using fewer dashes, varying sentence length, and adding some colloquial phrases sometimes help.
But overdoing it turns the article into something else: deliberately loose grammar, fragmented sentences, and ideas that seem hastily thought up.
It doesn’t look so much like AI-generated text, but it also doesn’t look like a good article.
This is exactly where WRITING.md shines.
It doesn’t aim to “fool detectors.”
Its goal is simpler: make the writing fit the specific context, with less default model tone and more verifiable content.
1. Clarify the Source First
The WRITING.md repository is here:
https://github.com/Anbeeld/WRITING.md
There are several versions in the repo:
WRITING.md
WRITING-compact.md
WRITING-mini.md
skills/writing/SKILL.md
The full rules are in WRITING.md.
The compact versions can be included in AGENTS.md or CLAUDE.md.
skills/writing/SKILL.md is a packaged Skill version, suitable for tools like Claude Code, Codex, Cursor, and OpenCode that support Skills.
If you want to install it, just give the AI the repo address:
https://github.com/Anbeeld/WRITING.md
Then say:
Help me install the writing Skill from this repository.
2. It Sets the Direction Right from the Start
In the Purpose section of WRITING.md, there’s a sentence that basically defines the whole set of rules:
Writing should fit the medium, task, and reader.
In other words, first consider:
Where is this being published?
Who is the reader?
What is this text supposed to accomplish?
This is more reliable than just “write more like a human.”
An email to a colleague, a public account article, a product copy, or a technical document shouldn’t all use the same tone.
Some situations require clear structure.
Some require fewer lists.
Some need neutrality.
Some need the author to stand out.
WRITING.md doesn’t use a one-size-fits-all approach. It lets the AI judge the context first.
This explains why dissecting public account Skills is tricky.
It’s not an official document or casual social media rambling. It should feel like experience sharing, but the source code and implementation can’t be wrong; it should be understandable to beginners but not distort technical details.
Get the context right first, and the rules won’t get messed up later.
3. It Doesn’t Encourage Pretending to Be Human
My favorite part is the Safety rails.
It clearly says:
- Don’t make up typos.
- Don’t deliberately break grammar.
- Don’t force in slang, profanity, or fake uncertainty.
- Don’t create messiness just to “sound human.”
- Don’t fake naturalness by programmatically varying sentence length.
Many current methods to remove AI feel actually add noise to the article.
Making sentences messier doesn’t equal more authentic.
Breaking down structure doesn’t make it more human-like.
WRITING.md is clearer: the AI feel often comes from overly strong patterns, context mismatch, and vague content—not from the text being too clean.
So it opposes “fake human-ness.” Good writing doesn’t need deliberate roughness.
4. It Requires Each Paragraph to Have Concrete Anchors
There’s a rule called concrete specificity in WRITING.md.
It means important paragraphs should have concrete anchors.
What counts as anchors?
For example:
- Specific names
- Specific numbers
- Direct quotes
- A verifiable detail
- A real decision or scenario
- A change the reader can observe
What doesn’t count?
For example:
many
various
meaningful changes
broad impact
essentially
ultimately
usual patterns
This rule is especially useful for checking AI articles.
AI is good at writing “correct but ungraspable” sentences.
For example:
This Skill can significantly improve writing efficiency.
Sounds fine, but the reader doesn’t know what it actually does.
Change it to something like:
It first lets the AI judge where the article will be published and who will read it, then decides whether to use lists, paragraphs, or a chat-like style.
Public account articles need these anchors. Without actions, files, scenarios, or changes, sentences tend to float.
5. It Reminds You: Specificity Needs Evidence
Many know “empty talk is bad,” so they overcompensate by adding numbers, dates, names, or seemingly specific details.
If these have no source, they become “fake specifics.”
WRITING.md specifically warns about this.
It says numbers, dates, quotes, causal judgments, and internal mechanisms must be handled carefully.
Don’t invent a seemingly credible detail just to avoid vagueness.
This rule fits well with our Skill dissections.
For example, when explaining a Skill’s implementation, don’t invent “it uses such-and-such algorithm internally” just to make the article lively.
If you’ve seen the code, say so; if not, say you haven’t; if it’s speculation, clearly say it’s speculation.
Better to say less than to say false things. This is especially important for Skill dissections.
6. It Focuses on Regularity
WRITING.md doesn’t judge AI feel by any single word.
It focuses more on repetitive patterns.
For example:
- Every paragraph starts with a conclusion sentence.
- Every paragraph unfolds with the same rhythm.
- Every section uses the same transition.
- Three consecutive paragraphs in parallel structure.
- Splitting adjacent ideas into one line each to fake sharpness.
- Every paragraph ends with a summary sentence.
I’ve fallen into these traps myself. Sometimes single sentences are fine, but the whole article feels too neat.
Readers feel the author isn’t present, only a model pushing forward a template.
This is what we said earlier: short sentences aren’t forbidden, but stacking short sentences continuously creates another kind of AI feel. It looks like attitude but is just putting every judgment on its own line.
7. It Also Controls Long-Form Structure
Many writing rules only focus on sentences, but WRITING.md also manages long-form structure.
It warns against turning articles into catalog prose or system-tour prose.
Simply put, don’t make every paragraph sound like introducing a module.
For example:
Background
Mechanism
Impact
Summary
Or:
Feature A
Feature B
Feature C
My judgment
This structure can be clear but also easily feels like a manual.
When dissecting Skills, we also tend to write like this: first the source, then files, then rules, then usage, and finally a summary.
If every article is like this, readers get tired quickly.
So find a main thread.
For example, the main thread of this article is:
Don’t ruin your article just to remove the AI feel.
The following rules revolve around this sentence.
8. What This Means for Writing Your Own Public Account Skill
If I were to apply the WRITING.md approach to a public account style Skill, I’d have it make four judgments first.
First, judge the article scenario: is it a Skill dissection, experience review, tutorial, tool recommendation, or series summary? Different articles shouldn’t use the same structure.
Second, protect facts: repository addresses, file names, script behaviors, API results, release status—none should be casually changed for flow.
Third, check anchors: paragraphs without examples, actions, files, dialogues, diffs, or screenshot locations should be supplemented or deleted.
Fourth, check regularity: don’t write every section as “problem-explanation-value-summary,” and don’t compress every paragraph into short sentences to force judgments.
Only then handle the ending. Finish and wrap up; readers need next steps, not a grand finale.
9. My Take
WRITING.md isn’t a detector, nor does it promise to fool any tool.
It’s more like a writing guardrail: first check context, then protect facts, add concrete anchors, check regularity, and finally remove fake actions added just to “sound human.”
This approach fits well with continuing our Skill series. Public account articles should aim for something concrete: a target, facts, presence, and personal judgment. The surface-level goal of “not sounding like AI” is just a byproduct, not the goal.
