How to Edit AI Drafts Without Losing Facts or Your Voice

An AI editor can remove every tired phrase from a draft and leave its weakest claim untouched. “Our product saves you time” still needs evidence, however naturally you write it.

An anti-slop skill gives your AI editor reusable writing rules. That can help you stop fixing the same prose problems by hand. But if you’ve shipped a product and need buyers to find it, cleaner sentences are only part of the job.

Use the skill to edit your wording. Give it evidence before you ask it to make the wording better.

What is an anti ai slop skill?

An anti AI slop skill is a reusable set of instructions that tells an AI agent how to avoid or remove generic writing patterns. You give the editor rules rather than explaining your preferences again for each draft.

jalaalrd’s anti-ai-slop-writing describes itself as a writing skill that eliminates detectable AI patterns. It advertises support for Claude Code, Codex, Cursor, Gemini CLI, and other agents. That describes its intended job and where you can use it. It doesn’t establish how well it performs.

For your own writing, useful editing rules might cover:

• Replacing stock phrases with direct statements.
• Cutting introductions that delay the answer.
• Using concrete subjects and active verbs.
• Preserving the words you’d actually use with a customer.

Those are examples of rules you could supply, not a verified inventory of the repository’s instructions. The supplied source material doesn’t include enough of the skill to audit its full behavior.

The distinction matters. A reusable instruction can tell an editor to remove puffery. It cannot establish whether your product really delivers the result described underneath that puffery.

Imagine a draft saying your app “dramatically simplifies reporting.” An editor might change that to “finish your reports faster.” The second sentence is easier to read. It still makes a claim you need to support.

Treat an anti-slop skill as part of your editing setup. Let it handle repeated wording rules while you decide what the page can honestly say. Don’t treat a more natural voice as evidence that the facts have been checked.

Which anti-slop tools are worth testing?

jalaalrd’s anti-ai-slop-writing and SalZaki’s antislop both target AI writing patterns, but describe different ways to use their tools.

The first advertises support across several agents, including Claude Code, Codex, Cursor, and Gemini CLI. The second describes a Claude Code plugin with skills for removing AI-generated tells while keeping your voice.

Choose your first test based on the editor you already use. If you draft across different agents, the broader advertised support is relevant. If you work in Claude Code, the plugin is a direct candidate. Neither description gives you a reason to rebuild your workflow before trying a draft.

Keep the advertised promises separate from what you’ve verified:

• Support for your agent doesn’t prove the edits will suit your writing.
• Removing AI tells doesn’t prove a claim is accurate.
• A promise to preserve your voice doesn’t show that it will preserve your caveats.

The supplied repository excerpts don’t include a comparative test, measured editing results, or evidence that either tool improves sales. There’s no basis here for declaring a winner.

I’d start with a draft you understand well. Use a page about a feature you built, rather than a topic where you’d struggle to catch a mistake. Save the original, run the edit, and inspect what changed.

Read the current repository instructions before installing either tool. The excerpts supplied here don’t establish the installation commands or the full set of available options. Guessing those steps would defeat the point of a source-backed workflow.

Your first decision is small: which tool is easiest to test in your existing editor? Whether it deserves a permanent place comes after you’ve read its edits.

Add product evidence before editing the prose

An AI editor needs your product facts before it can preserve them. A screenshot, a failed approach, or an actual customer question gives the draft something specific to explain.

SalZaki’s antislop promises to remove AI-generated tells without losing your voice. That’s a writing promise. It doesn’t supply the product knowledge needed to explain why a buyer should trust your recommendation.

Before you run an editing skill, add one piece of evidence that belongs in the answer. Choose something you can inspect and explain:

• A screenshot showing the feature you’re describing.
• A customer question, shared with permission or stripped of identifying details.
• A failed approach and the reason you changed it.
• A measured result with the test conditions attached.

You don’t need all four. Pick the evidence that supports the page’s main claim.

For a hypothetical article about an export feature, a screenshot could show which fields the export contains. That supports a narrow claim about what the feature does. It doesn’t support a broader claim that the feature saves every customer hours.

If you want to claim time savings, measure the task and record how you measured it. Without that result, describe the steps your product removes. A narrower sentence can still help a buyer decide.

Write down what the evidence cannot prove, too. A test with one file doesn’t establish how every file behaves. A customer’s question reveals a concern, not how common that concern is.

Add those limits beside the evidence before editing starts. Then the editor has something concrete to protect. Asking for punchier prose before supplying facts gives it a wording problem to solve while leaving your real gap untouched.

How should you instruct an AI editor?

Give your AI editor separate rules for style and factual accuracy. “Make this sound human” leaves too much room for changes you didn’t ask for.

jalaalrd’s anti-ai-slop-writing advertises the removal of detectable AI patterns. You can test that aim while also giving the agent firm boundaries around claims, quotes, and product details. Don’t assume a writing skill includes every safeguard your draft needs.

A useful editing request starts with the reader’s question. For example: “Help a buyer understand whether our export includes the fields they need.” That gives the editor a purpose beyond making sentences sound nicer.

Then give it rules like these:

Edit for clear, direct language. Answer the buyer’s question early. Remove stock phrases and repeated points. Keep product names, source links, quotes, and test conditions intact. Don’t strengthen claims or invent examples. Flag unsupported claims instead of repairing them with confident wording. Return the edited draft and a short list of changes that could affect meaning.

That’s a suggested brief, not a quoted instruction from either repository.

Keep your supporting material next to the draft. Label which details came from your product, which came from an outside source, and which are only suggestions. Otherwise, an illustrative example can end up reading like a customer result.

You can also give the editor a short sample of your own writing. Choose something you’d happily say aloud. Ask it to preserve that level of formality rather than adding jokes or rough edges to imitate a person.

Instructions don’t remove the need to review the result. They make the review clearer. You can check whether the editor followed a concrete request instead of arguing with a vague feeling that the draft sounds wrong.

Punchier prose must keep caveats and citations

An edit changes meaning when it removes the conditions attached to a claim. “Worked in our test” and “works” make different promises.

SalZaki’s antislop describes preserving your voice as part of its purpose. Your own acceptance test should also check whether it preserves the limits of what you know. That isn’t a reported flaw in the plugin. It’s a risk worth checking in any rewrite.

Consider this hypothetical sentence:

In our test, the export handled the sample file without manual cleanup.

Now compare it with:

Export your data without manual cleanup.

The second version is shorter. It also drops the test conditions and turns a reported result into a general promise. An editor hasn’t improved that sentence if your evidence only supports the first version.

Review changes to small words especially carefully:

• “Can” becoming “will.”
• “In our test” disappearing.
• “The author claims” becoming a statement of fact.
• A source link moving away from the sentence it supports.

These changes don’t look dramatic in a polished paragraph. Each can alter what a buyer thinks you’re promising.

Citations need the same care. Keep the link beside the claim it supports. If a source describes a tool’s intended behavior, retain that distinction. “The repository advertises support” is more precise than “the tool works” when you haven’t tested it.

An edit fails if it makes a sentence easier to read by making it less true.

Keep useful caveats short and local. You don’t need to bury the reader in warnings. You do need to say which file you tested, what the screenshot shows, or whose claim you’re reporting. Those details help the buyer judge whether the answer applies to them.

How do you test an anti-slop skill on your own drafts?

Compare the edited draft against a saved original and check every changed claim. A smoother read is only one part of a useful test.

Neither jalaalrd’s anti-ai-slop-writing nor SalZaki’s antislop has demonstrated results in the supplied excerpts. Their descriptions give you reasons to investigate, not proof that either will work for your content.

Use a draft with enough substance to expose mistakes. Include a product detail, a linked claim, and a sentence with a necessary limitation. A generic introduction won’t tell you whether the editor can handle the parts you care about.

Run a simple review:

1. Save the untouched draft and its supporting material.
2. Run one editing tool with a clear brief.
3. Compare both versions, checking meaning before style.
4. Record what you accepted, rejected, or had to restore.

If you test both tools, give each the same original draft and brief. Running the second tool on the first tool’s output makes the comparison harder to interpret.

Check whether the answer arrives sooner. Check whether the product detail remains correct. Open the citations and confirm they still support the nearby claims. Read the revised prose aloud to catch wording you wouldn’t use.

You can record how much review the draft needed. Just don’t turn one editing session into a broad claim about time saved. Your result describes that draft, with that brief, in that editor.

Keep the tool if its edits are worth the checking they require. Reject changes freely. A skill doesn’t need to win every sentence to be useful, but you need to know which kinds of edits you can trust it to attempt.

When is an AI-assisted post ready to publish?

Publish when the post answers a buyer’s question with details you can support. Passing a style check alone doesn’t meet that standard.

jalaalrd’s anti-ai-slop-writing targets detectable AI patterns. SalZaki’s antislop targets AI tells while promising to preserve your voice. Those aims can fit inside your publishing process without becoming the final test for whether a page deserves to go live.

Name the buyer’s question in one sentence before your final review. “Does this export include the fields I need?” gives you something you can actually check. “Thought leadership about better workflows” doesn’t tell you what the reader should learn.

Use a short release check:

• Does the page answer the named question directly?
• Does its main claim have evidence beside it?
• Can the reader see relevant limits or missing information?
• Does the next step follow from the answer?

The next step might be checking a sample export, reading a setup guide, or trying a feature. It should help the reader resolve the question, rather than interrupting the answer with a sales pitch.

If the post still consists of claims any competitor could make, return to your product. Add the detail that lets a reader judge your advice. Don’t ask the editor to disguise the absence of evidence with a more distinctive voice.

For your next draft, choose one buyer question and attach one relevant piece of proof. Run the anti-slop skill after that. Compare the result against the original, restore any lost limits, and check the links.

Then publish the answer you can defend. You can automate repeated editing rules without handing over the judgment that makes the page worth reading.