DEV Community

Cover image for Why I put the Guardsman SKILL on duty in front of every repo I touch
Antoinette C. Lennox
Antoinette C. Lennox

Posted on

Why I put the Guardsman SKILL on duty in front of every repo I touch

I almost skipped this one. Another "AI coding skill," another README promising your agent will finally behave. I've installed six of those this year and uninstalled six of those this year.

Then I actually read what Guardsman does, and I stopped scrolling.

The problem it names correctly

Most of these tools optimize for one thing: stop the agent from over-building. Fair enough — we've all watched an agent turn a two-line ask into a new dependency, a config layer, and an unprompted essay on edge cases nobody has.

But Guardsman names a second failure mode I hadn't seen anyone else call out directly: the confidently small diff. Five clean lines. No test. Written after skimming half the flow. Landing straight on a path that touches money, auth, or user data. It compiles. It demos. It's the one that actually gets you, three weeks later, because nothing about it looked dangerous.

That's the sentence that sold me: code size is not risk, blast radius is risk. I'd been unconsciously grading diffs by how they looked, not by what they touched. Once you say it out loud like that, you can't unsee it.

What made me actually install it

It's not a vibe check, it's a mechanism. Every change gets a risk tier — trivial, standard, sensitive, critical — decided by blast radius before a line is written. Money, auth, or user data in scope pushes the tier up automatically. The agent can be told to downgrade a tier explicitly. It is never allowed to infer a downgrade just because the code looks simple. That one rule is the whole point: "looks simple" is exactly the disguise the dangerous diff wears, so the tool refuses to take the bait on your behalf.

Underneath the tiers is a build ladder I actually agree with in order: does this need to exist at all → is it already in the codebase → does the stdlib do it → does the platform already do it → does something already installed solve it → can it be one line → only then, the minimum code the tier calls for. It's the YAGNI checklist I keep meaning to run in my head and don't, made mandatory instead of aspirational.

And the part I didn't expect to care about: TODO comments get replaced with structured, severity-tagged logbook entries instead — a scanner can actually harvest them and flag what's overdue. I have TODOs in production from two years ago that nobody, including me, remembers the context for. That's not a hypothetical problem for me.

The detail that made me trust the rest of it

Buried near the bottom of the README is a line most tool authors would never write:

A tool that invents numbers about your codebase has no business guarding it.

No "saved you 12,000 lines," no unverifiable percentage. The author states plainly that there's no baseline version of your repo to diff against, so no honest tool can produce that number — and the real benchmark protocol is public, not yet finished, and will ship with its method and limits when it lands. A tool that's this disciplined about not overclaiming its own value is the same kind of tool that'll actually enforce discipline on your diffs. That consistency is what moved this from "interesting README" to "installed in my project."

Getting it running

/plugin marketplace add hedimanai-pro/guardsman
/plugin install guardsman@guardsman
Enter fullscreen mode Exit fullscreen mode

Five modes if you don't want it running persistently: build (default, on every turn), review (diff-only, changes nothing), audit (whole-repo pass), logbook (surfaces open shortcuts by severity), post-report (only what's directly countable, right now, no invented figures). Not on Claude Code? The condensed ruleset in adapters/AGENTS.md ports the tiers to any agent that reads custom instructions.

I'm running it in build mode on my current work. I'll follow up with what I actually observe once I've got real mileage on it — not before.

💂

Top comments (0)