9-Arm Skills: AI Agents Need Brakes, Not More Gas

There's a small GitHub repo making quiet rounds in AI developer circles called 9-arm-skills, built by a developer named Thananon (the video source credits this name; no GitHub handle or full name was provided, so take the attribution as is). It's not a framework. It's not a platform. It's four behavioral templates — rules, essentially — for how an AI coding agent should debug, review, document, and communicate. That's it.

AICodeKing, the YouTube channel covering it, frames this as a workflow blueprint rather than a literal tool install. And the framing is worth understanding even if you've never typed a line of code in your life — because the problem these templates are trying to solve isn't really a coding problem. It's an accountability problem.

What the repo actually does

Think of 9-arm-skills as a set of policies for an AI employee you've just hired. Left to its own devices, this employee is fast, confident, and frequently wrong in ways that look exactly like being right.

The four "skills" address four distinct failure modes:

Debug Mantra stops the agent from proposing fixes before it understands the problem. The rule is explicit: reproduce the issue first, trace the failing path, challenge the hypothesis, treat every test run as evidence. As AICodeKing puts it: "The problem with many coding agents is not that they cannot write code. The problem is that they are too eager to write code before they understand the failure."

Postmortem governs the engineering record written after a bug is fixed. Crucially, it refuses to produce that document until the facts exist — no confirmed reproduction, no root cause, no validated fix means no writeup. Full stop.

Scrutinize is a review skill that doesn't just check whether the code looks tidy. It asks whether the change should exist at all — whether there's a simpler approach, whether the tests are actually testing the right thing, whether the behavior matches what the pull request claims.

Management Talk translates technical incident details into the kind of update a product manager or team lead can actually act on — keeping ticket numbers and impact summaries, stripping the stack traces that mean nothing outside an IDE.

Together they form a loop: debug properly, review properly, document properly, communicate properly. The multi-agent structure to pull this off isn't complicated in concept — it's just rarely enforced in practice.

The postmortem problem is the one that should make you uncomfortable

Of the four skills, the postmortem constraint is the one I'd push teams hardest on — and not just for the engineering reasons AICodeKing describes.

Here's the specific failure mode: AI tools are exceptionally good at writing text that sounds authoritative. They can take a debugging session that ended with "we think it was probably the cache invalidation logic" and produce a root cause analysis that reads like forensic certainty. The language is confident. The structure is professional. The underlying conclusion is a guess wearing a suit.

In a security context, I see this failure pattern constantly — incident reports that launder speculation into findings, that replace "we don't know" with "the evidence suggests." People get fired based on those reports. Vendors get cleared. Patches get skipped because the documented root cause pointed somewhere else.

The 9-arm-skills postmortem template is trying to enforce a basic epistemological standard: you cannot document what you don't know. But here's what the template can't fix on its own — someone still has to sign off on that document. If a team deploys an AI agent to write their post-incident analysis, who owns the output? Who's accountable when the ghost root cause turns out to be wrong six months later and the same bug class resurfaces? The template adds friction in the right place, but friction only works if there's a human checkpoint at the end who actually reads the thing, not just approves it.

The engineering discipline argument has been building for a while — the idea that AI tools amplify whatever practices already exist in a team. If your team already has sloppy incident documentation, an AI postmortem agent will produce sloppy incident documentation faster and with better grammar. 9-arm-skills is useful precisely because it codifies the standard before the agent runs, not after.

How to tell if a constraint like this is actually holding

If you're a developer, or a manager whose team is using AI coding tools, here's the practical stress-test I'd apply to any behavioral constraint before trusting it in production:

Can you observe the constraint being violated? Debug Mantra is only useful if there's a way to see whether the agent actually reproduced the issue before patching. If the agent's output skips straight from "error received" to "files modified," the constraint isn't holding — it's just decorative. Build in a logging step, a structured output requirement, something that makes the skipped step visible.

Does the postmortem document include falsifiable claims? A real root cause names a specific component, a specific condition, a specific test that confirms the fix. "The system experienced increased load" is not a root cause. "The rate limiter on the auth service was misconfigured to trigger at 100 req/s rather than 1000 req/s, confirmed by reproducing with a load test targeting that threshold" is a root cause. If your AI-generated postmortem reads like the first example, the template isn't doing its job.

Is the review agent actually separate from the implementation agent? Scrutinize's entire value proposition is that the reviewer didn't write the code. If you're using a single AI session to write and then review its own work, you've re-created the exact bias problem the skill is designed to break. The discipline-over-features pattern keeps surfacing in different repos for a reason — separation of concerns in AI workflows isn't optional, it's structural.

Ask for the evidence, not just the conclusion. Whether you're a developer looking at agent output or a team lead reviewing an AI-assisted incident report, get in the habit of asking: "Show me the reproduction steps. Show me the test that passed. Show me what you ruled out." An AI agent running under proper constraints should be able to answer those questions with specifics. One running without them will give you confident-sounding generalities.

The disclosure footnote worth noting

The video describing 9-arm-skills includes a referral link to Verdent, an AI coding platform, in the description. AICodeKing spends a significant portion of the video explaining how 9-arm-skills could be implemented as a workflow blueprint within Verdent specifically. I can't independently verify Verdent's full feature set or confirm the nature of that referral relationship from the video alone — readers should weigh that context when evaluating the platform-specific recommendations. The behavioral templates in 9-arm-skills are described as built for Claude Code and are independent of any particular platform.

What happens if teams keep skipping this

The AI coding tools conversation has been dominated for two years by a single question: how much can these things do? Bigger context windows, faster inference, more capable models, more integrations. The capability ceiling keeps rising.

9-arm-skills is asking a different question: how much should these things do before a human checks the work? And that's a threat model, not just a workflow preference. Teams that keep reaching for more capability without building in constraint checkpoints are accumulating a specific kind of technical debt — not in the codebase, but in their documentation, their incident records, their trust assumptions. When something goes wrong at scale, and the postmortem was written by an agent that never had a reliable reproduction, the blast radius isn't just a bug. It's a gap in the organizational record that nobody can reconstruct.

A small repo with four markdown files can't solve that systemically. But it names the failure modes clearly enough that you can go looking for them in your own stack — which, for a free GitHub repo, is a pretty good return.

---

Rachel "Rach" Kovacs is Buzzrag's cybersecurity and privacy correspondent.