anti-slop-text

Anti-Slop Text

The rule

Every sentence gives the reader a fact they need, in the plainest words that carry it, and every fact comes from the material you were given or something you checked.

Slop is text shaped like writing with nothing specific in it: significance claimed instead of shown, reasons made up to sound concrete, rhythm doing the work that content should. A reader who spots the patterns tends to distrust the rest of the text, including the parts that were true.

Read the companion files first

This skill ships two companion files beside it. On first use in a session, before any other step:

1. Read tells-catalog.md in full. It holds the full list behind the review table below: every pattern, the words and shapes to search for, and what to write instead. The table here is a reminder of text you have already read, never a substitute. Re-read it before any review pass over text longer than a few paragraphs.
2. Load the communication rules, one of two ways:
   • The effective-communicator skill is installed (it appears in your list of available skills, on its own or under a plugin prefix): invoke it and follow it. Do not read communication.md; the installed skill is the fuller version of the same rules.
   • It is not installed: read communication.md in full. It is the distilled version of that skill.

Writing from memory of what "plain" or "clear" means, without one of those loaded, is a red flag below. Never tell the reader to install the other skill; use it when it is there and the file when it is not.

Write it in this order

1. List the facts first. Before writing, list what you know from the brief, the code, the diff, the data, or a source you opened. The text says those things and nothing else. When a fact is missing (why a decision was made, what a number was, what happened next), ask for it or leave it out. Never supply a plausible reason, anecdote, number, quote, or outcome to make the text feel complete; a made-up detail is worse than a missing one because the reader cannot tell which details are real. If the requested length needs more facts than you have, write the shorter text, say how long it came out and why, and ask for the material that would fill it.
2. Say it plainly. Subject, plain verb, fact. Use is, has, uses, wrote, tried, moved over serves as, boasts, utilizes, authored, attempted, relocated. A number beats an adjective: "builds in 9 minutes" over "blazing fast".
3. Let facts carry their own weight. Do not tell the reader something is significant, pivotal, a testament, a turning point, or part of a broader trend. If it matters, the fact shows why; if the reason is not obvious, state the reason as another fact.
4. Name who said it. A claim about what people think names its source, or is stated as your own claim, or is cut. No experts argue, many believe, studies show without the study.
5. Say Y. When a sentence, or a pair of sentences, brings up X only to set it aside and then says Y, write Y. The structure is the tell, whatever the words: "it's not X, it's Y", "it could be X, but it's Y", "X isn't the problem, Y is", "sure, X, but Y", "less X, more Y", "the real X is Y", "Y rather than X", "no X, no Y, just Z", and every other variant in tells-catalog.md. Ask whether the reader would have believed X if you had not raised it; if not, X is a foil, so delete it. Keep X only when the reader actually holds it or it was an option someone weighed, and then state it as a fact ("we first suspected the cache; the logs showed …"), not as a reveal. When editing, rebuild the sentence: Y in its own sentence; X only if it is a fact the reader needs on its own (a measurement, a named option), in its own sentence, never as the setup for Y. An evaluative X such as easy or obvious is framing, not a fact, so "keep every fact" does not protect it.
6. Let the content set the count and the rhythm. List the real items, whether that is one or five. No drumroll openers (here's the thing, turns out, the punchline), no stacked rhetorical questions, no three sentences in a row starting the same way, no fragment pairs built for punch ("It broke. We fixed it.").
7. Fit the structure to the content. Headings in sentence case unless the house style says otherwise, used only when the text is long enough to need them, in order, each with text before any subheading. Bold at most the one thing a skimmer must not miss. Bullets for list-shaped content; paragraphs for reasoning. A table for three or more rows compared across two or more columns. No emoji as bullets or heading markers, no rule between every section, no closing "Conclusion", "Summary", or "Key takeaways" that restates the text. End on the last new fact.
8. Use the destination's format. Markdown where it renders, plain text in a commit body, email, or form field, the house markup in a wiki. Follow the house style for dashes, quotes, and heading case; with none, prefer commas, colons, and parentheses to repeated em dashes.
9. Leave the conversation out of the artifact. A document, commit message, or PR description has no Certainly!, Here is …, I hope this helps, Let me know if …, or model disclaimers. It starts with its first real sentence. Fill every placeholder with a real value or ask for it.
10. In reports, commits, and PRs, say what changed. What changed, why, and how it was checked. Mention an untouched part only when the reader would otherwise assume it changed. No assurances (following best practices, ensuring consistency, preserved existing behavior) without the evidence that makes them true, and no narration of your process.