How to build your first Claude Code mod (no coding required) Anthropic added mods to Claude Code on October 1, letting users enforce deterministic rules on the agent through JavaScript or TypeScript hook functions that run inside Claude Code and fire on events such as a command about to execute. The tutorial distinguishes mods from skills, MCP servers and settings hooks — Claude decides when to use skills and MCP servers, while mods and settings hooks always run, with mods executing inside Claude Code and able to draw on the screen. It builds three example mods: one that keeps session and weekly usage limits on screen, one that blocks a `git push` leaking a secret and hides keys from Claude, and one that logs every step Claude takes, while warning that mods run with full access to the computer and should be read before installation. Claude Code mods let you set rules your agent can’t ignore. To see why that matters, look at how LLMs differ from traditional software. With traditional software, you know exactly what the program will do with a given input; that’s what writing a program is. With LLMs, the same input can give a different output each time. The model might just ignore the flow you envisioned, and that can be frustrating. Almost every LLM user has seen this: I’ve read someone got their database deleted by their agent; imagine the anguish On October 1, Anthropic added mods to Claude Code https://claude.com/resources/articles/claude-code-mods , and they give you real control over how your agent acts. But what are mods? A mod is a plugin made of small JavaScript or TypeScript functions that run inside Claude Code. Simply put, a mod is like a bouncer at a nightclub. It decides what gets in and out, and because code enforces it, it’s as deterministic as it gets. When Claude reaches the door, an event fires: “Claude is about to run a command.” The bouncer is a small function you write for that specific door. Inside a mod, this function is called a hook. The bouncer can do one of three things: The three mods in this tutorial use all three moves. The first one watches your session and keeps your usage limits on screen, so a long task can’t quietly eat your quota. The second one stops a git push that would leak a secret, and hides your keys from Claude before it reads them. The third one keeps a record of every step Claude takes, so you can see which edit broke your code. One warning first: a bouncer is only as honest as whoever trained them. Mods run with full access to your computer, so read a mod’s code before you install it. Now that we have mods, hooks, skills, and MCP servers, things can get confusing fast. No worries, let’s go through each of them briefly. A skill is a folder of instructions https://blog.logrocket.com/top-five-claude-skills-for-react/ , such as a SKILL.md file that Claude reads when the task matches. The catch is that Claude decides when to use it, so there’s no guarantee a skill will be invoked when it should be. You can call a skill yourself, but in complex flows you rely on Claude to pick it. Skills change how Claude works, not Claude Code itself. MCP servers are separate programs that give Claude new tools or data, such as a database, GitHub, or a browser. Claude decides when to call them, and they live outside Claude Code. Settings hooks are usually shell commands that you put in settings.json https://blog.logrocket.com/maximize-claude-code/ for a fixed moment, such as before a tool runs or when a session ends. They can also call a URL or send a prompt. They always run, and Claude doesn’t decide. A shell command hook runs outside Claude Code, as a new process each time. Mods are JavaScript or TypeScript functions that run inside Claude Code, and they always run on their events. Claude does not decide when to run them. Because they run inside, they can also draw on the screen, which none of the others can do. | You want to | Use | Who decides | Where it runs | |---|---|---|---| | Teach Claude a task your way | Skill | Claude | Inside Claude’s context | | Give Claude a new tool or data | MCP server | Claude | A separate program | | Run a script at a fixed moment | Settings hook | Always runs | A new process each time | | Change Claude Code itself | Mod | Always runs | Inside Claude Code | Anthropic’s mods docs https://code.claude.com/docs/en/plugins/mods/overview compare-mods-settings-hooks-skills-and-mcp-servers have a longer version of this comparison. One habit I had while working with Claude Code is to always check my subscription usage. How much of my five-hour session limit and weekly limit did I use? I’d always go to Claude’s usage screen and look there. The moment I learned about Claude mods, I built a mod for myself that shows me my session and weekly usage directly inside my terminal. We are living in a different era now: it’s been more than a year since I touched a code editor. I don’t write code anymore; I ask Claude Code to write it for me, and I did the same for building this mod. Luckily for us, Claude Code has a built-in skill https://code.claude.com/docs/en/plugins/mods/create ask-claude-for-a-mod for this. It’s called plugin-authoring , and Claude uses it when you ask for a mod. I first asked Claude for some mod ideas. Number 3 on its list was a usage meter, so I wrote: I want you to build this, and open a public GitHub repo because I’ll share this with other people too: Usage meter. Status line, plus a toast at 80% and 90%. Claude 5h 62% resets 18:40 · week 41%. Tells you when to hand work to Sonnet. Four minutes later, the mod was working, and its tests passed. Three minutes after that, it was a public repo on GitHub. It wasn’t perfect on the first try: when I opened a new session, the meter didn’t show up. I told Claude, and it fixed how the mod loads. If you peek inside the mod Claude built for me, you’ll see it’s just a small folder with a few files: plugin.json hooks.json register.ts There’s also a helper file, a test file, and a file that lets others install it from GitHub. The mod watches two doors. The first one is “a session starts”, so the usage line shows up the moment I open Claude Code. The second one is “usage changed”, which fires every time my numbers move. At that door, the mod updates the line and, once I pass 80% and again at 90%, pops up a warning. Remember the three things a bouncer can do? This mod only watches. It never changes or stops anything. It just keeps count and shows me the result, which reads like this: Claude 5h 36% resets 10:00 · week 48% . You don’t need to write any of these by hand either. If you want to try it, clone the repo and start Claude Code with claude --plugin-dir usage-meter . Nothing gets installed, and it’s gone when you close the session. Over 200k developers use LogRocket to create better digital experiences Learn more → Many people are getting into vibe coding now, that is, building without writing a single line of code. A lot of them have no programming experience, so they might not know the pitfalls of pushing their secrets to GitHub. Even seasoned developers fall into this trap. You forget to create a .gitignore , or you forget to add your .env file to it, and bad things can happen from there, as red eyes in the dark forest are always watching for your keys. Our bouncer says no: that push never happens, and your key never goes public. I built this mod for myself too, because I’m only human and I make mistakes. I can just forget and push my keys to GitHub, and I for sure don’t want to wake up to thousands of dollars of API usage. I named this mod secret-guard . Before a git push runs, it checks if the repo is public, then looks through the new lines for keys, tokens, and home paths. If it finds one, the push never runs. What did the secret-guard mod catch? In its first 17 days, secret-guard stopped 30 pushes. Not one of them was an API key. Every finding was a home path, a line like /home/