anti-ai-slop-writing: a writing skill that constrains an AI by rule

A rules file rather than a model

The project describes itself as a Claude Code skill and a universal SKILL.md that forces any AI to produce human-sounding text by eliminating statistically detectable AI writing patterns.

The mechanism matters more than the marketing in that sentence. There is no model here, no fine-tuning, no classifier. The deliverable is a file of instructions that the assistant reads and then obeys, which is why the installation section lists copying a file to a skills directory as the whole setup for a dozen different tools.

The scope is wide. Every piece of text the AI produces, tweets, emails, articles, bios, reports, copy and message, passes through the same constraints on vocabulary, structure, punctuation and formatting. The stated goal is to remove the patterns that readers and detection tools flag as AI-generated, which is the same target from two directions: a reader who notices the tell and a tool that scores the text.

The claims are tied to sources. The project says it is based on research from Carnegie Mellon in 2025, on Wikipedia's Signs of AI Writing page, on Buffer's analysis of 52 million posts, and on community detection patterns documented across X and Reddit. That is a mixed evidentiary base, from academic work to a platform's own corpus to community observation, and the skill treats all of it as equally usable.

The project is MIT licensed and the author is Jalaaldeen, who is described as the builder of Wardex, ZakatChain and open-source AI tooling for founders. The last push was on 2026-04-18, there are no GitHub releases, and the topic tags are ai-writing, anti-slop, claude-code, prompt-engineering, skill and skillmd.

What the rules actually catch

The What It Catches list is the substance of the project, and it is organised by the kind of tell rather than by the specific instance.

Vocabulary comes first: 50 or more banned words flagged across multiple AI detection studies. The examples named are the sort of word that appears constantly in generated prose and rarely in edited prose, and the count of fifty suggests the list is long rather than selective.

Phrases are the next category, with 35 or more banned phrases. The examples are the shape of a generated opening, such as "In today's competitive...", "It's worth noting..." and the "Not just X, but Y" construction.

Then 16 banned sentence openers, with examples such as "Certainly,", "Moreover," and "Additionally,". That is a narrow and mechanical rule, and it is the kind of rule that works, because those openers are strong markers that appear in the first few words of a paragraph where a reader's attention is highest.

Structure is the fourth group and the most interesting one: 10 structural patterns, including the rule of three, uniform sentence length, a hedging seesaw, corporate pep talk and passive voice. These are not word bans. They are observations about how generated prose is shaped, such as three-item lists appearing where two would do, or sentence lengths clustering around a single value, or a paragraph that hedges in one direction and then reverses.

Then the punctuation tells, which are em dash overuse, exclamation spam and ellipsis abuse, and the formatting leaks, which are markdown appearing in plain text, emoji used as bullet points and stacked hashtags.

The last category is different in kind from the rest. Accuracy failures are listed as invented statistics, fabricated quotes and fake anecdotes. That is not a style rule, it is an accuracy rule, and including it inside a style skill is a reasonable choice since a fabricated number is the failure readers care about most once the prose no longer sounds like a machine.

The count of categories is what makes the project more than a word list. Banned words alone are trivially worked around by an assistant that has been told to avoid them. Banned words plus banned phrases plus banned openers plus structural patterns plus punctuation plus formatting is an attempt at a full specification of the output style.

Installing it in whichever agent you use

The installation options are the practical face of the project, and there are four of them.

For Claude Code through the plugin marketplace, the command is:

/plugin marketplace add jalaalrd/founder-toolkit

For Claude Code manually, you copy the folder into your skills directory:

cp -r skills/anti-ai-slop-writing ~/.claude/skills/

For other tools, Cursor, Codex, Gemini CLI and similar, you copy the SKILL.md file to that tool's skills directory, and the project states that the SKILL.md format is cross-compatible with 11 or more coding agents.

For any AI chat, whether ChatGPT, Claude.ai or Gemini, you copy the contents of SKILL.md and paste it at the start of any conversation, and it works as a system-level writing constraint.

That last route is the one that says the most about what the project is. A file of instructions pasted into a chat window is a system prompt in everything but name, and the fact that it works there means the value does not depend on any agent's skill mechanism. It is portable text.

The naming in the marketplace command is worth noticing too, since it is not the repository name. The command adds jalaalrd/founder-toolkit, which suggests the skill ships inside a larger bundle of founder tooling rather than as a standalone plugin, so installing it from the marketplace brings more than this one file.

The usage section says the skill activates automatically when you ask the AI to write anything, that you can also invoke it directly, and that you can simply ask for it in the request:

/anti-ai-slop-writing

The last option, asking for a tweet, an email or an article and for it to sound human, is the shape most people will use. The automatic activation is the part you cannot control, and in a tool with many skills that means the rules apply to more than the writing you deliberately invoked them for.

Two files, and why the vocabulary list is loaded on demand

The file structure is the smallest possible thing that could work:

anti-ai-slop-writing/
├── SKILL.md                          # Core rules (under 500 lines)
└── references/
    └── banned-words.md               # Full banned vocabulary list (loaded on demand)

The split is the interesting part. The core rules are held in a file of under 500 lines, and the full banned vocabulary list sits in a references directory and is loaded on demand.

That is the standard pattern for a skill file, and it solves a real problem. A large list of banned words pasted into every conversation is expensive in two ways: it consumes context that could hold the actual task, and it competes for the model's attention with the instructions that matter. Keeping the core rules short and the vocabulary in a separate file means the expensive part is only pulled in when it is actually consulted.

The consequence is that the vocabulary list is a reference, not a rule set, which changes how strictly it binds. The core file can state the categories and the mechanism, and the model treats the fifty-plus banned words as a lookup table it should consult rather than as fifty instructions it can hold in mind. A banned word that is not in the loaded context is a banned word the model may use.

The 500-line cap on the core file is itself a constraint worth reading as a design decision. It is a statement that the rules have to be short enough to be read and followed rather than long enough to be skimmed. A rule file of several thousand lines would produce worse output than a rule file of four hundred, because the model treats the whole thing as one undifferentiated blob of instructions.

The top level of the repository reflects the same minimalism. There is a `.gitignore`, a `README.md` and a `skills/` directory, and that is the entire tree. The project is a skill, not an application, and it has no build step, no package manifest, no tests and no runtime.

Where the approach limits itself

The design has a clear philosophy and it is worth stating what that philosophy gives up.

The rules are categorical. A word is banned or it is not, and the ban applies whether the usage is lazy or whether it is the precise word for the thing being described. That is a real cost in technical writing, in marketing, and in any field where the vocabulary of the subject overlaps with the vocabulary of generated prose. If a banned word is genuinely the best word available, the skill has no way to express that, and the user has no way to grant an exception.

The structural rules have a similar character. A rule against uniform sentence length pushes toward varied length, which is usually better and occasionally worse. A rule against the rule of three pushes away from three-item lists, which are often the clearest way to present three things. The rules are heuristics about a corpus, and applying them to a particular piece of writing involves a judgement the rule itself does not make.

The other limit is that a rule set addresses symptoms. The patterns the skill bans are evidence of how the underlying model generates text. Suppressing the evidence while the underlying sameness remains can make prose sound different without making it better, and readers who are good at this will notice. The skill is most useful as a second pass over text that was already thought about, rather than as a substitute for having an opinion.

The evasion side is worth naming too. A rule set that is published can be learned by the models it targets, and a model trained to satisfy the rules can produce text that satisfies the rules and trips nothing, which is not the same as human writing. Nothing in the project claims otherwise, and the framing of statistically detectable patterns is careful enough to acknowledge that detection and quality are different questions.

What the project does offer is a concrete, portable and enforceable version of a piece of advice that is usually given as encouragement. Most writing guidance says to avoid certain tics. This one is a file with a list, a size budget and a set of installation paths, and that makes it usable in a pipeline, which is where the difference between advice and a rule file shows up.

Editorial conclusion

Adopt anti-ai-slop-writing if you draft with an assistant and publish the result, since the skill is a single portable file that works in Claude Code, in Cursor, in Codex and in a plain chat window. Do not adopt it as a substitute for editing, since the rules remove symptoms rather than fix the underlying sameness of a generated draft, and check first that none of the banned vocabulary is a term your field genuinely needs, since the list is applied without regard to context.

Frequently asked questions

Official sources

1. Issues
2. jalaalrd/anti-ai-slop-writing on GitHub
3. README