slopaganda countermeasures: part 2

June 27, 2026

Hi, I know it's been a while since my last post. Things have been nuts in my personal life and I've also been hella busy at work onboarding someone new. I've just generally had a lot on my plate. Good news, though, I've been building a lot of stuff and maybe, JUST MAYBE, some of this might benefit you! Here are a few more things I'm doing to combat slop and bad outputs, generally.

skills writing lab

As someone who has paid the bills by writing instructions for a long time, I'm particularly OK at writing agent skills. I'm also willing to test things and iterate, so the skills and agent instruction files I produce typically work like I want them to.

Folks who are newer to AI and perhaps don't spend as much time writing as I do can sometimes struggle with their skills and other instructions producing wholly out of pocket results (like entirely hallucinated product features, for example). I've made myself available to help people troubleshoot their skills and instructions, and it's been a really rewarding experience. I'm throwing this out there as a way to keep yourself relevant as a writer in the AI age, and also as a way to build relationships with other teams.

dAIagrams

First off, I know this doesn't really count as anti-slopaganda, but I'm including it because adding the thinky-through parts to the process has, in fact, improved the quality of AI-coauthored diagrams for my docs and has made them a viable addition to my work.

I read Abby Covert's STUCK? Diagrams Help. I am not a visual person in the slightest and I have been known to say I hate diagrams and diagramming. I don't have the module in my brain that makes diagrams anything other than infuriatingly opaque, and sometimes my documentation suffers from no-diagrams-itis. Because I'm a professional, I decided to get better at diagrams this year.

Turns out I still suck at diagrams, and no matter how good the book was (it was very good), it cannot make me better at diagrams. So, I used my notes from the book to create an agent skill that walks through the steps that STUCK? lays out. Turns out agents can do a decent job of writing D2 diagrams if you give them clear instructions. I can't go into too many details because I don't want to give away STUCK? -- if you struggle with diagrams go ahead and read it. But, the gist here is that I now have a skill that makes the agent ask me questions about who the diagram is for, what my goal is, and a few other (proprietary) things, and then drafts a diagram and uses our homegrown D2 automations to generate the SVG, write ai-friendly "alt text" for the .md version of the page, and then spin up a preview for me to pick apart.

On the whole, it does a much more thoughtful job of diagramming than my no-picture-having-ass-brain could dream of. Thanks Abby Covert and thanks Claude Code.

intern work

I am a player-coach, meaning I am both a people manager, department head, and an IC. As most writing teams are probably aware, headcount is hard to come by, and we are generally expected to do a lot with a little. So, in that spirit, I built a human-gated workflow between Linear and Claude Code that allows Claude Code to create and (once approved) execute on doc plans for simple, tightly-scoped doc tickets. It works like this:

1. I sit down every morning and triage incoming doc work. If I think a ticket is something that an agent can execute on independently, I clean up the ticket description to make it bad interpretation-proof, add a label to mark it, and then add a comment for Claude with any further instructions (like branching from a feature branch or sequencing instructions).
2. When I'm done triaging, I run a local script that's aliased to a single command that loads a Claude Code session with a permissions file and kicks off a Claude command (again, I'm skimming over some details cause I can't give away all my work secrets).
3. Claude fetches the Linear issues with the label that mark it for the run, and reads the ticket, reads our docs repo context. Meanwhile, I'm already working on other stuff for the day while Claude handles this. Claude writes documentation plans for each ticket, and will post any blocking questions to the ticket.
4. At my own leisure, I review the doc plans on each Linear ticket, and either approve, or comment back with changes. When I'm done, I run a second Claude Code command, which performs the work. I wander off to do other work with my human brain at this point.
5. I eventually start getting notifications that PRs are ready for me to review. I review them, make any adjustments that I need to make, then eventually send them to the SME or stakeholder for final approval if necessary.

So now, I'm not having to use my mid-career brain for small things like adding new fields or net-new sections that don't need intricate explanations. Hate it if you want, but I have a lot on my plate and I'm trying to protect my team and myself from having to do work that doesn't challenge us and doesn't necessarily need our actual expertise for. We have so many agent instructions and quality check tooling built around our docs -- AI is perfectly capable of producing content that follows our style guides and it can run our preflight checks from the CLI.

I like the workflow because I gate it at both ends to make sure I'm not delegating anything delicate to AI and I'm also not letting AI slop into my docs. I treat it like any other PR review I'd do for my team.

skills

I built something totally wild for our customers (integration agent skills), but I'm still waiting on the official blog post and announcement so you'll just have to wait on the guts for that for now. I am planning another docs goblin post about my design and build process, so stay tuned.

That's all I've got for now, I was thinking things would slow down for me for the summer, but it turns out that was wishful thinking. I'm also in the thick of writing a book, which is way less fun than I initially anticipated, so most of my energy is headed in that direction.