Claude Code mods vs skills: a skill is a suggestion, a mod is a guarantee — and what I would hard-block first

I've written a lot of skills. A skill is a markdown file telling Claude how I want something done — the house voice for a blog post, the filing rules for my knowledge base, the order of operations for a client report. They work well, and they have one structural property I've been quietly working around for a year: a skill is advice. The model reads it and almost always follows it. Almost.

Mods, which landed at the start of this month, are the other thing. A mod is a plugin made of JavaScript or TypeScript functions that Claude Code calls when something happens — a tool call, a submitted prompt, a part of the interface being drawn — and the function can watch the event, rewrite it, or answer it itself so the normal behaviour never runs. It isn't in the context window. It's in the harness.

That distinction is the whole reason I care, and it took me a week to say it cleanly.

A skill is a suggestion, a mod is a guarantee

Anthropic's own comparison table puts it in plain terms: a skill is "a SKILL.md file of instructions Claude reads" and changes "what Claude knows and does." A mod is "functions in a plugin that Claude Code calls in its own process" and changes "tool calls, prompts, commands, turns, and what the interface draws."

Read those two rows next to each other and the design decision falls out. Anything where a 99% compliance rate is fine is a skill. Anything where the 1% is the whole point is a mod.

My knowledge base has two folders I never want read: a private journal and a credentials folder. Today that rule is prose, repeated in three instruction files, and it has held. It has held because the model is good, not because the system prevents it. A mod handling tool.check can simply refuse a read under those paths — no deliberation, no judgement call, no dependence on how much context is left at turn forty.

If the only thing standing between a tool call and a credentials folder is a sentence in a markdown file, you don't have a guardrail. You have a preference.

This is not a criticism of skills. It's a scoping correction I should have made earlier. I'd been treating instruction files as policy, and they're documentation that happens to be obeyed.

The four I'd actually build

Having gone through my own setup, the shortlist came out shorter than I expected, which is usually a good sign.

A hard guardrail is first and it isn't close. Block the two off-limits folders outright, lock the paths that scheduled routines depend on, require a prompt before any delete, and redact anything that looks like a token on its way into the transcript. All of that is currently trust.

Second, a context loader. Every session in my workspace opens with the same ritual: read the root instructions, read the system file, read the relevant project summary. It's in the instructions, I ask for it in scheduled prompts, and it still gets done at slightly different depths depending on the run. A hook on session start injects it, identically, every time. The ritual becomes infrastructure.

Third, a spend-and-publish gate. I have tools that post to a live blog, change ad budgets and push to git. Those should be held behind an approved plan rather than available from the first turn. Holding a tool call while you ask the user something is one of the documented things a mod can do, and it's precisely the shape of that problem.

Fourth, a context meter in the interface. I already run a checkpoint routine for long sessions, and the trigger for it is my own guesswork about how full the window is. A pane reading actual session usage replaces a guess with a number — and the sample mods Anthropic ships include exactly this, a forecast of your context window drawn above the prompt.

The two I wrote down and then cut: a one-click "log learnings to the inbox" at session end, which my scheduled routines already cover, and an automation health pane, which is honestly a daily job and not an editor feature. Knowing which of your ideas is the wrong shape for the tool is most of the value of reading the docs before building.

The part that should slow you down

Mods are not sandboxed. The documentation is blunt about it: a mod runs with your permissions, can read and write files anywhere your account can, start processes, make network requests, read your environment variables and settings — including an API key kept in either — see every prompt and every tool call, and approve a tool call before you're asked. If you turn on sandboxing, it isolates the Bash commands Claude runs; a process a mod starts runs outside it.

So the honest security posture is: install your own, or ones you've read. claude plugin validate on a directory will list which events a mod handles and what it asks the harness to do before you ever load it, which is a genuinely good primitive — the capability surface is inspectable because a hook has no way to touch the outside world except through the documented API.

One detail I found reassuring, and it's the kind of thing that tells you a team thought about the threat model: a mod can restyle almost the entire interface, but not the permission prompt. It can't change what that dialog shows you. The one surface whose integrity matters most is the one they took off the table.

Where this leaves the stack

I now think of my setup in three layers rather than one. Skills say what good work looks like. Settings hooks run scripts I already had on lifecycle events. Mods enforce what must never vary, and draw the things I want to see while working. MCP servers remain what they always were: how Claude reaches systems outside the machine.

Worth noting where this does and doesn't run. Mods are a Claude Code feature — the CLI and the Code tab of the desktop app, from v2.1.287 and v2.1.286 respectively. The hooks also fire in headless and SDK sessions; the drawing only shows up in the terminal and the desktop app. They are not a Cowork or chat feature, which matters if, like me, you run scheduled work in Cowork and interactive work in Code. The guardrail I most want is for the surface that has shell access, so that lines up.

Twenty years of operating has taught me one reliable thing about tooling: the useful question is never what a tool can do. It's which of your current rules are only working because everyone is being careful.

Sources & further reading

External
Mods overview — Claude Code documentation
Mods reference — Claude Code documentation
Skills — Claude Code documentation
Hooks reference — Claude Code documentation

Related posts
Claude merged chat and Cowork
My scheduled Claude Code routine failed three weeks running
I tested a Claude skill against a baseline control group
Off had to mean off