/fair-share: AI work that respects the reader.

A newsletter I read used a term I'd started seeing everywhere: the slop grenade. The phrase comes from Shopify, where Harry Brundage coined it and the CEO, Tobi Lütke, made it public on a podcast. Someone asks AI for a lot, gets a lot, and passes it along unread. The person who receives it then absorbs the cost of figuring out what it says.

Researchers at Stanford and BetterUp have a broader name for it, workslop: AI output that looks finished but doesn't move a task forward. In their survey, roughly four in ten U.S. desk workers had received some in the past month, and each one took close to two hours to deal with. But what really stuck out to me was that 42 percent said they trusted the coworker who sent it less.

I think most people who send it are overworked, and a tool that writes 15 pages in a minute feels like relief. I do want people to have that relief, but I also want us to be able to trust the work we hand each other.

The newsletter's author offered a rule I liked: never send AI work that takes the reader longer to understand than it took you to make. I wanted a tool that applied it.

My first two names, Slop Mop and Slop Guard, were both taken, four times between them. Every one of those tools works on style (does this sound like AI?) or on feeds. None of them looked at the handoff between two colleagues, which is the relationship, where the focus should really be.

I also set aside a rewriting editor for the sending side. A rewrite that happens without the writer seeing it doesn't teach them anything, and a red-pen skill can already handle line edits, so /fair-share diagnoses and hands revisions there.

Claude's first sketch split the idea into two tools, one for each side. I wanted one skill that starts with a single intake question: did you receive this, or are you about to send it? Inbound and outbound run on the same diagnosis, with different outputs.

Slop grenades usually come from an incomplete prompt that asks for a lot, so the sending side should coach rather than just edit. Outbound mode traces weak output back to likely gaps in the prompt that made it: no audience named, no length, no source material, nothing marked as most important. It returns a better prompt along with the diagnosis. It presents those causes as likely, never as verdicts, because inferring a prompt from its output is the least reliable thing the skill does.

So inbound protects the person receiving, and outbound helps the person sending get better.

Claude offered a list of skill names, and I chose /fair-share because working with AI is still working with colleagues. A recent paper on etiquette for AI-supported work describes what recipients expect from coworkers: a review pass before sharing, and a declaration of how much the tool did and how finished the work is. That's close to the sending side of this skill, written as research.

A tight newsletter. I ran inbound mode on the newsletter that started this. It passed. That exposed the first gap: the output template assumed something was wrong. The /fair-share skill now has three verdicts (Passes, Mixed, Slop), and "this is fine" counts as a useful result. Public content also gets "what to verify before you repeat it" instead of questions to send back to a colleague.

A padded news post. I asked Claude to find a real example online instead of writing a fake one. It found an agency's news post about slop grenades, where the real reporting sat under a ten-question FAQ that restated the body almost line for line. That became the Mixed verdict and a repetition check. The post also confirmed a figure the first test had marked unverified, so the skill now says plainly that unverified doesn't mean false.

My own first draft. For outbound mode I didn't want to stage a fake mistake. I needed this case study anyway, so I gave a separate Claude chat a one-line prompt for it and pasted back the result untouched. /fair-share labeled it Draft. The structure and voice were good, but five claims about the skill were wrong. It said the skill "never grades," about a skill that issues verdicts. It said the skill doesn't guess at authorship, two paragraphs after saying it flags writing that "looks like it was generated." The prompt trace found the cause: the skill file was never in front of the chat that wrote about it. That test added a contradiction check.

That draft also included the line "some of my own drafts went out sounding like I hadn't read them." /fair-share flagged it as a claim only I could confirm.

Honestly, it isn't quite true. I prepare carefully before any task, with voice skills, context files, and examples. But in shared drafts that everyone knows are unfinished, I rely too much on the grace of my peers to catch what I didn't check.

That work is neither inbound nor outbound, so I named it crossbound. /fair-share now gives a crossbound draft a short handoff note: how rough it is, what I need from the reader, and what I didn't check. My collaborators were already giving me that grace, and the note just says it out loud so we've both agreed to it.

Claude's own read-time estimates were loose. It called the newsletter about 330 words and my draft about 450. Counted, they were about 305 and 362. Those are small misses, but this is a tool that measures other people's padding, so word counts should be computed.

It has been tested on three samples (actually four, if you include this case study!): one newsletter, one news post, and one of my own drafts. None was a long internal document from a coworker, which is the case it was designed for.

I haven't measured how often the prompt trace guesses right.

Nobody but me has used it yet, and the threshold that keeps it quiet on short items (about 250 words) is a starting guess.