Humanizer or Unslop? It depends who's talking

When I ask an agent to make some writing sound more human, I'm usually asking for one of two things. Either its reply to me has buried the useful part under too much explanation, or I've given it a rough thought and want something I can send to another person.

I asked an agent in Conductor to find the writing skills I had installed, compare them and check what people were saying about them on GitHub. Two were dedicated editors: Humanizer and Unslop. Most of the others ran Unslop as one step in a bigger workflow.

I now choose between them by asking who's talking. If someone will read the text as something I wrote, it goes through Humanizer, along with examples of how I actually write. Everything else goes through Unslop: agents reporting back to me, technical rewrites, reference documentation and instructions written for other agents.

The same conclusion, written twice#

The same session produced an example of each. The agent was writing for me, and it used Unslop for the write-up. Its report opened like this:

Humanizer and Unslop are your two dedicated AI-text editors. I found six other closely related skills, plus four workflows that apply Unslop to their output.

My recommendation: Humanizer for text that should sound like you, Unslop for clearer everyday agent replies, and technical-writing for documentation.

Below that came a table of eight skills with links to their sources and GitHub issues. It had also noticed that my copy of Humanizer was a major version behind. That's what I want from an agent reporting back: I can check its sources and decide what to do next.

Once it had set up my agents, I asked for a short Slack message about where I'd landed. This time it used Humanizer:

Been playing around with a couple of writing skills and landed on this setup:

• Unslop for my agent summarising things for me. Keeps explanations clear and cuts the jargon.
• Humanizer for turning my thoughts into messages to other people. Helps keep them sounding like me.

I've set up Codex and Claude to pick between them automatically depending on what I'm writing.

It reaches the same conclusion without any of the evidence, because the people reading it don't need a table to understand what I did. A lot of the wording is mine. I'd asked for a message saying I'd been "playing around" with the skills and "landed on unslop for my agent summarising things for me", and Humanizer kept that phrasing.

Swap the two and neither works. My colleagues would get a research report for a short update, and I'd get a message with nothing in it to check.

What each skill is built for#

A skill is a Markdown file of instructions that an agent reads before it starts a task. These two ask for different things from an editor.

Unslop comes from Cursor's pstack collection. It's a checklist of just under 1,000 words, grouped by kind of problem: filler, jargon, stock AI vocabulary, vague attributions and sentences that are hard to parse. Some of the rules are strict. Em dashes are banned outright, with no parentheses as a substitute, and a phrase about how something feels should become the mechanism or the number. The last rule warns against going too far the other way, into dropped articles and arrows that leave the reader decoding shorthand. That suits an agent reporting on its own work.

Humanizer is almost five times as long. Version 3.0.0 rebuilt it around 25 patterns from Wikipedia's list of signs of AI writing, ordered from the strongest signal to the weakest. What makes it suit my own writing is the guidance around the patterns. A writing sample overrides its rules, including the one about dashes. It checks the rewrite for facts it has added or lost. A section on when not to act tells it to keep unusual details, mixed feelings, dated references and genuine asides.

Cursor's copy of Unslop describes itself as "Cut AI tells from any writing. Must always apply." It also sets disable-model-invocation: true, which stops agents from reaching for it on their own. I rewrote the description in my copy so my agents pick it for routine replies, with a pointer to Humanizer for anything authored. Agents choose skills by reading their descriptions, so that's the simplest place to put the routing.

The comparison turned up other pstack skills built around Unslop. technical-writing gives docs, READMEs and commit messages a structure and applies Unslop to the result. bro restates the last answer in plainer language. Both are useful for those jobs, but neither is a general editor to choose between.

What other people ran into#

The GitHub issues gave me things to check for. Two proposals on Humanizer's repository, #93 and #172, came from people who had run it on their own writing and found it over-edited, smoothing away their voice. Both asked for a lighter mode. The maintainer declined, replying that the existing voice and restraint guidance already covered it.

A more recent report, #269, is closer to the cases I care about. Its author ran Humanizer on a reply to a pull request review. The tells were gone, but the reply still restated the diagnosis, proved it and explained a data backfill before it reached the decision. What they sent in the end was much shorter, because the reviewer already knew about the bug. That's a technical subject in a person's voice, which my rule sends to Humanizer. My rule has a line for this problem too: in an ongoing conversation, leave out what the reader already knows.

The strongest evidence for Humanizer is a same-model replay by the author of a competing tool. Across 18 drafts, it reported much better scores than the originals, with the important details kept in 17. The author described it as a small study they ran themselves, reviewed by a model, and the maintainer replied that the numbers matched what they'd seen.

Unslop has less public feedback. The clearest mention I found was on the Apache Cassandra developer list, in a thread about model-written comments and documentation named after the kind of phrase it objected to, "the load-bearing seam". The proposal was to keep the project's flat, neutral style, and one contributor suggested steering agents with skills like Unslop instead of rejecting their comments.

Show it how you write#

Without examples, "make it sound like me" gets you a generic friendly voice. Describing yourself doesn't get you much further. An earlier voice profile of mine came from a questionnaire of 71 questions, from a one-to-five formality rating to which platforms I post on, with the writing samples near the end. When I rebuilt the process in August, the samples became the main evidence and the core questions dropped to twelve. A pasted Slack message shows how long my sentences are and how I open a message. A formality rating can only describe them.

For anything longer than a quick message, this is what I'd give an agent now:

• Three to five pieces of genuine writing that match the job, such as Slack messages for a Slack reply or longer posts for a post. Anthropic's guidance on examples suggests that number, with examples close to the real task and varied enough that the model doesn't copy an accidental pattern.
• One or two examples that sound wrong, with a note on why. "Never opens with 'Excited to share'" tells an agent more than "not too formal".
• The reader, what they already know and what I want them to do.
• The facts for this message, kept apart from the samples so the agent borrows the style and leaves the content.

Old AI drafts don't count as samples, even with my name on them. They'd teach the agent to imitate itself.

Before it writes anything, I'd ask the agent to list the habits it noticed, each with a quote from the samples. That turns a vague impression into a list I can correct.

There's a limit to how far this goes. An EMNLP 2025 study of writing from more than 400 authors found that the models it tested could approximate a person's style in news and email from a few samples, and struggled with informal writing in blogs and forums. It didn't test these skills or the models I use now, but it's a good reason to read the draft before sending it.

Here's the prompt I'd start from. The tags follow Anthropic's advice to keep examples separate from instructions.

Help me write a message in my voice.
 
<reader>
Who it's for, where it'll appear and what they already know.
</reader>
 
<goal>
What I want them to understand or do.
</goal>
 
<samples>
Three to five genuine pieces of my writing, similar to this message.
</samples>
 
<not_me>
One or two examples that sound wrong, with a note on why.
</not_me>
 
<facts>
The details, links and anything I'm unsure about.
</facts>
 
First, list the habits you see in my samples, quoting each one.
Then write the message. Match the samples' word choice, rhythm,
punctuation and formality, and take facts only from <facts>.
Leave out context the reader already has. If I've supplied a draft,
edit it lightly. Don't invent experiences, opinions or details.
Run Humanizer as the final pass.

The rule I gave my agents#

I use Codex and Claude Code. Both load Humanizer from one shared installation, so an update reaches both, and they have the same rule in their global instructions. Here it is, rewritten to stand on its own so you can adapt it:

Choose a writing skill by who the text speaks for.
 
Use Humanizer for anything written as me: emails, Slack messages,
posts, articles and replies in a conversation, including technical
subjects when I'm explaining something to another person.
 
Use Unslop for your own replies to me, progress updates, debugging
explanations, PR descriptions, commit messages, reference docs and
instructions for other agents. Keep any documentation workflow's
structure and accuracy checks.
 
Use one editor per passage unless I ask for both. My samples and
requested tone override generic style rules. Preserve facts,
uncertainty, quotes, code and links. Edit my own writing lightly.
In an ongoing conversation, leave out what the reader already knows.

PR descriptions and commit messages sit on the Unslop side. They go out under my name, but they're a record of a change for whoever reads the history later.

The judgement call is a technical message to another person. If I ask an agent what a bug fix does, I want the Unslop explanation. If I then ask it to tell a colleague about the fix, the facts are the same but I'm the one talking. That's Humanizer, with a note on what the colleague already knows.

I don't run both editors over the same passage. Their punctuation rules disagree, and a strict cleanup pass can strip out a habit the voice pass was told to keep. One turn can still use both: Unslop for the agent's update to me, and Humanizer for the message it has drafted for me to send.