"You Can Just Do Things." But Maybe, Be Safe About It?

Notes on shipping agentic code without getting yourself or your users into trouble. Hooks, slash commands, and other things I put in place so my AI doesn't ship me into production unsupervised.

Freetown. Late. Building. (Photo extended with AI, naturally.)

I started building with Claude Code in January 2026. I’d just finished the course from Anthropic Academy, I was heartbroken, and I needed something to sink myself into. So I sank myself into the terminal. My former boss had been pushing me for a while to stop being afraid of it, to lean more fully into the builder archetype since I was already a hybrid PM. I’d been dabbling in vibe-coding with v0, Bolt, Lovable, but I hadn’t lived in a terminal and a repo before. December 2025 tech Twitter was loud with people shipping things over the holidays. So I guess the timing was right and the grief gave me the focus.

I started cautious. My first project was a frontend build and redesign. I went with minimal plugins, a design and animation skill and one MCP server so the agent could see the browser. That was it. Every new project, I’d manually bring my customizations back in, adding a little more each time as I figured out what I actually used and needed. Eventually most of my setup migrated from project-level to user-level, because I was working across web and app dev and the patterns were similar enough to share.

Then the projects got serious. From pet experiments to org products in Sierra Leone that required Monime payment integrations, Supabase RLS, auth, real users with real money. Right around when that shift was happening, the Axios supply chain attack hit. Trusted package, hijacked maintainer account, malicious update shipping under the same name. That’s when I realized I needed some sort of defense to limit mistakes from my side, and if you vibe-code or use coding agents already, you’d understand what i mean.

Here was my constraint: I had no budget for security tools. Greptile, Snyk, Socket Pro... all were out. They're mostly around $20-30/month each, which sounds modest until you stack them on top of an AI bill that's already around $200/month across the tools I use. By Sierra Leonean standards, that's crazy money to spend on software, and I'm already there before adding security on top. The irony is that the tools designed to catch the kind of mistakes I was worried about, the ones you make when you're moving fast and trusting the AI, are mostly built for individuals and teams with security budgets. Solo builders and small shops are left to figure it out themselves. So whatever I built had to be defense-in-depth using free or already-paid-for tools. Reaching that conclusion, I knew the constraint would influence my design heavily.

I'd been using slash commands like /security-review and /code-review by the anthropic team for a while, and they worked. The problem was they only worked when I remembered to run them. Manual triggers depend on the human, and the human gets tired, distracted, in a hurry. So I sat down and carefully studied how I'd been working. Where I'd been sloppy, what I kept forgetting, and where the leaks would come from if they came. The pattern was clear that the tools were fine and did a decent job, the discipline was the gap. The fix wasn't a better tool, it was a layer above the tools that decides when they fire. That's when I moved to a global CLAUDE.md and built a stack of rules around it that caters to how I actually work, not how a tutorial says you should. The slash commands still do the work, but now they get triggered automatically when I do certain things, push to a sensitive surface, open a PR or install a new package. That's how I push to prod now. That's how I review code for security and logic before it goes anywhere. So far it's been working. I'm satisfied with the code I ship with AI, which is not something I would've said three months ago. But we'll get into the actual system in a bit.

A week ago, a friend in our group chat pasted a giant prompt into the chat. Two of them, actually. One for a “comprehensive security audit,” one for an “attacker’s-eye threat assessment.” Both well-written. Both designed to be copied into Claude Code or Codex or whatever agentic tool you’re running, to scan a codebase for vulnerabilities. Another friend said he also had a doc like that. I was surprised, to which, I replied, that for security and code review you don’t need a prompt, slash commands or skills exist for that. One of them fired back: “you criticize but never share” which was kind of fair.

So I’m sharing now. This is what I actually do. Not what I think people should do. Not what a tutorial would tell you to do. The system I built for myself, over a single long conversation with Claude Code, because the projects got real and the budget didn’t.

How most non-technical people are actually building, and why it scares me

Before I get into the system, I want to talk about the pattern I see, because it’s the reason this post needs to exist.

That same friend who pasted the prompts? He’d been building a project for weeks. I asked him at some point if he’d done a security review on it after he demoed it to me. He hadn’t. That was the only time he’d thought about it, and I was the one who brought it up. It was interesting, because he’s not careless. He’s smart, he ships things, he gets stuff done. He just hadn’t been thinking about it. But the muscle isn’t there. Security wasn’t part of his build loop, it was a thing he’d get to. Maybe.

And here’s the thing that concerns me about how this usually plays out. Even if he’d run the review, when you’re weeks into a project with thousands of lines of code, AI can’t really find everything. It’s not that the review is useless. It’s that the surface is too big for any one pass to cover thoroughly. The AI agent runs, generates output, you feel safer, but the actual coverage is shallow because there’s just too much to look at. The bugs you care about most (the subtle authz logic, the off-by-one in a payment flow, the env var that leaked into a client bundle three commits ago) get drowned out in a sea of style nits and generic warnings.

This is why coding principles matter more in the AI era. Fix one thing and commit. Read your diff (or not) before you commit it. Don’t accumulate a hundred changes and ask the AI to bless them. Each commit is a unit of review, and the smaller the unit, the more thoroughly any reviewer, human or AI, can actually look at it. I get into this more later in the post, but it’s worth saying upfront because it’s the precondition for everything else working. If you’re committing in big sloppy chunks, no security tool, paid or free, is going to save you. The architecture I’m about to describe assumes you’re committing small. If you’re not, start there first.

The pattern I see most often, especially with non-technical people building with AI: it works functionally, they eyeball it, it looks fine, they ship. Env variables get exposed. Routes that should be admin-only are reachable with a GET request. API keys end up in client-side bundles. Supabase tables go live with row-level security disabled. None of this is because the people building are dumb. It’s because AI made building this stuff accessible faster than the safety practices caught up. The on-ramp to shipping software got shorter; the on-ramp to shipping safe software didn’t.

Junior engineers used to learn this stuff by making mistakes in low-stakes environments. Internal tools, personal projects, code reviews from senior engineers who caught things before they shipped. The mistakes happened, but they happened slowly, and the blast radius was small. AI compresses that pipeline as everyone becomes capable to ship. A weekend project can have real users by Monday. A side experiment can be processing payments by the end of the month. The mistakes are still happening, but now they’re happening to actual people’s data and money.

I want to be clear. I’m not a security expert. I just retardmax. I’m fairly technical, into systems thinking, curious, I read a lot and I’ve been shipping for a while, but I don’t do this for a living. And that’s actually the point. You don’t need to be a security expert to avoid the worst of these mistakes. You just need to be exposed to the patterns and to take them seriously. Most of what I’m describing in this post is what someone slightly more careful than the average AI builder would do. It’s not advanced. It’s just deliberate.

If you’re building with AI and you haven’t thought about any of this, the first hour you spend on it will save you more than the next ten hours of features. That’s the case I’m making.

The automation ladder nobody draws

I had a long conversation with Claude Opus 4.7 about how people automate code review with AI. The conversation pulled from a few places: Anthropic’s own documentation on Claude Code’s extensibility primitives (slash commands, subagents, skills, hooks), the MCP server ecosystem on GitHub for tools like Semgrep and Snyk, and patterns from how people are actually using these tools in public on Twitter and in repos. None of these pieces were arranged as a ladder anywhere I could find. The primitives were mostly documented individually. The ladder is what came out of trying to map the space honestly, with Claude as a thinking partner. Most people don’t know they’re on it. From the bottom up, here are the rungs:

1. Pasting a prompt into a chat window. This is what my friend was doing. You write a long, detailed prompt that tells the AI how to look for vulnerabilities, then you copy that prompt into Claude Code or Codex or Cursor or wherever you’re working, and you run it. The AI scans your code and gives you a report. It works once. The next time you want to do a review, you have to find that prompt again, paste it again, run it again. If you change your mind about how the review should work, you edit the prompt in whatever document you keep it in, but there’s no version control. If you have ten projects, you do this ten times. I call this manual transmission. Every step requires you remembering to do it.

2. Saving it as a slash command in your repo, or installing one someone else maintains. This is rung two and where most people graduate to once they get tired of pasting. Slash commands are markdown files with a prompt inside. They live in .claude/commands/ either at the project level or globally at ~/.claude/commands/. When you type /<name> in Claude Code, the prompt fires. Tab-completion finds it. Two ways slash commands enter your setup. The first is you write them yourself, save the file in your repo, and the file gets tracked in git like any other code. You can see exactly what changed and when. Edit it once and it stays edited. The second is you install ones someone else has already authored. The /security-review and /code-review commands I use are in this second category. I didn’t write them. Anthropic’s team does, and I installed both. /security-review ships as a standalone slash command from the claude-code-security-review repo, you copy the markdown file into your ~/.claude/commands/ directory and it’s available globally. /code-review is part of an official code-review plugin (a plugin is a bundle that can include slash commands, skills, hooks, and MCP servers together) shipped through Anthropic’s official plugin directory. Recent versions of Claude Code may bundle these by default. Mine didn’t, I installed them manually. Either path gets you to the same place. Using the Anthropic-maintained versions is honestly the right move for me. Their team thinks about prompt design more than I do, and the commands get better over time without me touching anything. If you want to customize behavior, you copy the markdown into your own commands directory and edit. Either way, the move from rung 1 to rung 2 is what matters: the prompt is now a file living somewhere stable instead of a paragraph you copy and paste from a doc. No drift or reformatting. No losing the latest version. But you still have to remember to run it. Manual trigger, automated content. Big upgrade over rung 1, but the human is still the one deciding when the gate fires.

3. Wrapping it in a subagent that runs in its own context. A subagent is a focused worker that runs in its own context window with its own instructions and its own restricted set of tools. You can tell it “you are a security reviewer, you can read files but not edit them, when you’re done, return a summary.” Claude Code spins it up, it does its work in isolation, then it reports back. This matters when the review produces a lot of intermediate noise (file contents, grep results, exploratory reads) that you don’t want clogging up your main conversation. The subagent absorbs that noise and only surfaces the conclusions. You’d reach for this when you want to expand into specialized reviewers, a payment-flow auditor, an authz-logic checker, a database-RLS inspector, each of which knows your specific stack better than a general security review can.

4. Packaging it as an auto-invoked skill. A skill is a folder with a SKILL.md file inside that describes what the skill does and when to use it. The model reads the description and decides on its own whether to load and use that skill for whatever task you’ve given it. So if you have a “security-audit” skill and you ask Claude to “review the auth changes I just made,” the model recognizes the task as security-relevant and pulls in the skill automatically. No slash command, no manual trigger. The model does the matching. The catch is that “model decides” is the operative phrase. It’s conditional. The skill loads when the model thinks it should, which is great for context-dependent tasks but wrong for unconditional rules. Security policy that has to fire every time, regardless of what the model thinks the task is, doesn’t belong on this rung. You can check and find more skills here.

5. Running it as a hook on every relevant action. A hook is a script that fires automatically on a specific event, regardless of what the model wants. Claude Code has lifecycle events (PreToolUse, PostToolUse, UserPromptSubmit) and you can attach scripts to them. So a PreToolUse hook on git push fires every single time Claude tries to push, no matter what conversation it’s in or what task it’s doing. The script can run a check, ask for confirmation, refuse the action, or do anything else you want. This is the “guaranteed” layer. The model can’t forget to run a hook the same way it can forget to follow an instruction, because the hook isn’t in the model’s hands at all. It’s a separate process the runtime invokes. This is where the part of my system that genuinely cannot be bypassed lives.

6. Calling deterministic scanners (Semgrep, Snyk) over MCP. MCP, Model Context Protocol, is a standard way for tools to expose themselves to AI agents. Semgrep is a static analysis tool with thousands of rules for finding things like SQL injection, XSS, hardcoded secrets, weak crypto. Snyk does similar work for dependencies. Both ship MCP servers, which means the AI can call them like any other tool. The agent generates code, the scanner runs over it deterministically (same code, same rules, same findings every time) and the AI sees the structured output and can act on it. This rung matters because LLM review is probabilistic; deterministic scanners are not. They miss what they don’t have rules for, but they don’t miss what they do, and they don’t get tired. This is the rung I haven’t climbed yet, and Semgrep MCP is the one I’d add if I were extending the system.

7. Running everything in CI on every PR. CI is Continuous Integration. GitHub Actions, GitLab CI, that family of tools. The idea is that every time a pull request opens or updates, an automated pipeline runs against the code. Tests, linters, scanners, custom checks. No human required. For our purposes, this means the security review runs on every PR no matter who opened it or whether they remembered to ask for it. Socket.dev sits at this rung for me. It scans every PR for supply chain threats automatically, posts comments inline, and feeds those findings back to me before I merge. Anthropic’s hosted Code Review (which I talked about earlier) lives at this rung too, just at a different price point. The point of CI is that the review is no longer something you choose to run. It runs because the PR exists. The trigger is structural.

My friend is on rung 1. The prompt works. It’s just the manual transmission. Every project, every session, every audit. Paste, run, read, repeat. No version control on the prompt itself. Drift on every edit.

The interesting thing about climbing the ladder isn't getting to the top. It's that more rungs doesn't mean more safety. The right rungs for your actual threats means more safety. I sit at rungs 2, 3, 5, and 7 plus something the ladder doesn't capture: a meta-orchestration layer that sets the rules the lower layers enforce. I'll explain.

The system, layer by layer

Five layers. They don’t all do the same thing, and they don’t all work the same way.

• Global CLAUDE.md. A configuration file at ~/.claude/CLAUDE.md that loads into every Claude Code session, every project, automatically. It contains the rules: when to run security review, when to run code review, how to route pushes, how to gate dependency installs, how to handle PR merges. This is the policy file. The thing that tells Claude what the rules are.

• PreToolUse hook. A script that fires every time Claude tries to run a git push. If the push targets main, master, or production, the hook intercepts it and prompts me to confirm. Claude cannot bypass this. It’s not an instruction that can be forgotten. It’s code that runs every time, on every agent, in every session.

• Global git hook. A separate bash script wired in via core.hooksPath that runs on every push from my terminal, regardless of whether Claude is involved. Blocks pushes with critical npm vulnerabilities. Warns on changes to sensitive files. This is the layer that protects me when I push directly from my own terminal without Claude in the loop at all.

• The review commands. /security-review runs before pushes that touch sensitive surfaces: payments, auth, secrets, RLS, CORS, middleware, OAuth callbacks, third-party scripts. /code-review --comment runs on every PR before merge. These exist as Claude Code slash commands. They’re the actual review work.

• Socket.dev on GitHub. A GitHub App that scans every PR for supply chain threats. Not by checking package names against a CVE database, but by analyzing what each package actually does. Network access? Reads environment variables? Spawns shell commands? Obfuscated code? Postinstall scripts running at full permissions? These are the behavioral signals that show up when a trusted package gets compromised and a malicious update ships under the same name. The Socket layer matters because of how it connects to push routing. Because the policy forces every change through a feature branch and a PR by default, every change automatically goes through Socket. If I were pushing straight to main, Socket would never see the code until after merge. The PR-by-default rule isn’t just about review. It’s what feeds Socket its input. Each layer enables the next.

The decision that shaped everything

The first draft of this protocol had a split: production-class projects (apps with users, payments, auth) get the full protection. Personal projects (static sites, portfolios, experiments) push straight to main. Sounds like less friction, right? But, I rejected it.

I have projects in my personal folder that started as experiments and turned into real products. Side projects evolve. The moment you create a category called “personal” that gets less protection, you’ve created a shortcut. And the shortcut will eventually contain something that doesn’t deserve less protection.

The new rule was simpler, stronger and strict by default. Every project gets the same protection. Override is your explicit choice, never a project category. If I want to push to main, I say “push to main.” That’s the override. It’s conscious, it’s explicit, and it’s mine to invoke every time.

That single decision shaped the whole system. No project gets a free pass.

Instructions are best-effort. Hooks are guaranteed.

This is the insight that took me longest to arrive at, and it’s the one that matters most.

CLAUDE.md content gets auto-injected into the system prompt every session. But instruction adherence is probabilistic. The model has the rules available, decides whether to act on them, and sometimes loses. Especially in three conditions: session resume, where context compaction can lower the priority of system instructions; long sessions, where attention drifts after many tool calls; and high-momentum tasks, where the model pattern-matches on “user wants action” and skips the read-first step.

I see this regularly. Opus 4.6 has tried to bypass my own protocol on me more than once. Not maliciously, just by getting absorbed in a task and forgetting the gate exists. There’s a GitHub issue where another user hit the same thing. He had instructions in his project CLAUDE.md telling Claude to read WORKING-NOTES.md before any deployment command. Claude skipped it, ran the command, hit a 403, then read the file and realized the answer was there all along. The bot flagged it as a duplicate of three other open issues. It’s a known, recurring class of bug.

You can’t fix this with louder instructions. He wrote “FIRST” in caps with a warning emoji. It still got skipped.

The fix is structural. You move rules off the layer that depends on the model choosing to follow them. That’s why my system uses three different mechanisms: instructions for the rules that benefit from intelligence (which surfaces are sensitive, what severity matters), hooks for the rules that absolutely cannot be missed (no pushing to main without confirmation), and external scanners for the rules deterministic tools handle better than any LLM (behavioral analysis of dependencies).

Instructions are best-effort. Hooks are guaranteed. External scanners are deterministic. Each rule lives where it can actually be enforced.

This framing alone is worth more than any specific tool I’m using.

Commit cadence is a defensive strategy

I work in small phases now. Implement a piece, commit, let the protocol fire, fix what comes back, commit again. Move to the next piece. I don’t accumulate a lot of code before committing.

There’s a mechanical reason for this, and it took me a while to articulate it. LLM review quality is bounded by attention budget. A 30-line diff gets reviewed thoroughly. A 500-line diff gets reviewed unevenly: heavy on the early chunks, thin toward the end. This isn’t a Claude bug. It’s how attention works over long contexts.

When you commit in small blocks, each review pass runs at full attention. Findings are easy to attribute to a specific change. Review-until-clean converges faster because the surface is smaller. Rollback cost stays low. A bad block is a 30-line revert, not a feature unwind. Socket comments on the PR stay readable instead of becoming a wall.

Small atomic commits used to be a hygiene preference. With AI in the review loop, it’s a defensive strategy. The AI’s attention is the binding constraint, not the human reviewer’s.

What I deliberately didn’t add

People ask why I don’t have more layers. Three deliberate omissions:

• Custom subagents for security review. /security-review and /code-review already do what a security subagent would do. Wrapping them would be redundant. I do use subagents (when I summon them) for specific exploratory work. But for the unconditional review pipeline, slash commands are the right shape.

• Auto-invoked skills. Skills get loaded when the model decides they’re relevant. Security policy needs to be unconditional. Loaded every session, every project, regardless of what the model thinks the task is. CLAUDE.md is the right home. Skills would be the wrong abstraction.

• Snyk. Socket already covers the dependency surface, and Socket’s behavioral analysis is actually stronger than CVE-database approaches for compromised-package attacks. Adding Snyk would be paying for redundancy.

The one thing I’d consider adding: Semgrep MCP. It’s free, runs locally, scans every file Claude generates against thousands of rules, and catches the deterministic SAST patterns (SQL injection sinks, XSS, command injection, weak crypto) that LLM review can miss. It would close the one real gap in my stack and stay free. And that fits the thesis.

Why the constraint matters

I want to come back to the budget thing for a second, because it’s not just background. It’s the angle.

Most people writing about agentic security workflows have a budget for SAAS security tools. They reach for Snyk Pro, Veracode, SonarQube Cloud, whatever. The blog posts read like vendor demos. If I’d had that budget, I’d probably have done the same. Bought my way to safety and never thought about the architecture. The constraint is what forced me to think. Defense-in-depth using Claude Code I’m already paying for, Socket.dev’s free tier, GitHub Actions, and bash scripts I had Claude write for me. That’s the whole stack.

If you’re reading this from a country where enterprise tooling isn’t a casual line item, or you’re an indie hacker watching every dollar, the system I’m describing is built for you. Not because it’s a downgrade. Because the constraint produced a cleaner design for our situation.

The trade-offs, and what I’m still figuring out

I want to be honest about what this system costs, what it doesn’t solve, and where I’m still learning. The post would be incomplete without it.

• Review-until-clean eats tokens. The protocol says “review, fix, re-review, fix, stop only when clean.” On a noisy diff that’s three or four passes before convergence. Multiply by every PR. None of this changes my bill, I’m on the $100/month Anthropic plan and that’s flat. What changes is how fast I burn through my usage limit. Every review cycle pulls from the same pool I’d otherwise spend on building. With Opus 4.7 and the way it eats tokens, on a serious project I’m hitting the limit much sooner than I would without the protocol. So the trade isn’t dollars for confidence, it’s velocity for confidence. Some days I run out of usage before I run out of work, and I have to wait for the window to reset. So far I think that trade is worth it. But it’s real, and you’ll feel it.

• Global CLAUDE.md is a permanent context tax. The policy file gets injected into the system prompt every session, every project. Those tokens count toward my context window whether the protocol fires or not. As my CLAUDE.md grows (and it has) the cost grows with it. There’s a soft ceiling somewhere where the policy file starts crowding out the room the model needs for actual work. I haven’t hit it. But I know it’s there, and I try not to let the file bloat without reason.
  The way I work around this: I avoid longer sessions. I start fresh sessions for new work and use claude --resume less than you might expect. To carry state across sessions, I lean on two things. The project’s own CLAUDE.md, which I maintain and update as I proceed, captures architecture decisions, conventions, and anything new sessions need to know. Claude’s project memory, which the agent maintains for itself across sessions, holds the working context, what’s in progress, what was just decided, what to pick up next. Between the two, a fresh session lands on its feet without me re-explaining everything. Most of the cost of long sessions, the drift and the bloat, comes from trying to keep one conversation alive too long. If you let the conversation die and let the files carry the memory, you avoid most of the problem.

• Long conversations and claude --resume are where the model forgets. This is the hardest one, and the most consistent. In long sessions or resumed ones, the agent loses track of rules I’ve already laid out and I have to remind it. It’s not just me. Andrej Karpathy posted in March that “the agents do not listen to my instructions in the AGENTS.md files. E.g. just as one example, no matter how many times I say something like ‘Every line of code should do exactly one thing’... they will still ‘multitask’.” He noted he could fix it with hooks or slash commands but “at some point just a shrug is easier.” Anthropic’s own best practices docs confirm the underlying mechanism: “Claude’s context window fills up fast, and performance degrades as it fills. When the context window is getting full, Claude may start ‘forgetting’ earlier instructions or making more mistakes.” This was largely my experience on Opus 4.6. I’m not sure if Opus 4.7 has improved this or if I’ve just gotten better at noticing when to remind it. Probably both. The drift in long sessions is exactly why the hooks layer matters. Karpathy chose the shrug. I chose the hooks. Same problem, two responses. The hooks don’t forget.

• I’m on the free tier of Socket.dev. It covers what I need today. If my projects scale or I get into team workflows, I’d have to revisit. For solo and small-shop use, the free tier is genuinely enough.

• There’s a “I trust it because it works” risk. I configured this system using Claude Opus 4.6 as a thinking partner. The bash hooks I didn’t write line-by-line, I had Claude write them and I read them and I tested them. They’ve held up. But if something breaks at 2am I might not be able to debug it without asking Claude again. That’s a real dependency, and I name it because it’s worth knowing about yourself. The system isn’t fully understood by me end-to-end. It’s understood enough.

• I’m still learning. This is the system I have today. It’ll change. Some of the rules I haven’t fully tested under pressure. Some of the assumptions might be wrong. I write this post not as a finished framework but as a snapshot of how I’m thinking right now. If you adopt any of it, treat it the same way. Test it. Question it. Push back on the parts that don’t fit your situation. I’m asking questions every day and changing things based on what I learn. You should too.

What I’d tell someone starting

Five moves, in order:

• Start with what scares you. For me it was watching the Axios attack land. I wasn't using Axios. The fear wasn't about that specific package, it was the realization that if maintainers of something used in millions of projects can be hijacked and push malicious code, I, fairly technical, no security budget, almost certainly couldn't catch the same thing happening in something I installed. I'm not going to pretend the system I built fully solves that. I still mostly wouldn't notice. What the system does is raise the odds that something flags my attention before I install or deploy. The first gate goes where you realize you're more exposed than you thought you were. You're not aiming for safe. You're aiming for "more likely to catch it than I was yesterday.

• Build the hook before the instruction. The instruction layer is convenient and probabilistic. The hook layer is mechanical and guaranteed. If you only do one, do the hook. The instruction can come later.

• Commit small. This is the cheapest change with the biggest review-quality return. No tooling required.

• Run fresh sessions, let the files carry memory. Long sessions and resumed sessions are where the model drifts. The cheapest fix is to stop fighting it. Start a new session for new work. Maintain your project’s CLAUDE.md as you go. Let Claude’s project memory hold the working context. A fresh session that lands on a well-maintained project shouldn’t need you to re-explain anything. Most of the pain people attribute to the model is actually pain from trying to keep one conversation alive too long.

• Ask questions, change your mind. This system is what I have today. Tomorrow some of it might be wrong. The way you keep a system useful over time is to keep questioning the parts that have become habit. If a rule fires every day and never catches anything, ask if it’s the right rule. If a rule fires once a week and catches something serious, that’s the rule that earned its place. The protocol isn’t sacred. It’s a living thing.

That’s enough to be safer than 90% of people shipping AI-assisted code right now.

Closing

I’m publishing this because my friend was right. I do criticize without sharing. The reason I had something to criticize was that I’d thought about it for myself. The reason I hadn’t shared was inertia, and not secrecy.

This isn’t a finished framework. It’s where I am now. With the AI pace, in some weeks or months I’ll probably look back at this post and want to revise some things. That’s fine. The point isn’t to ship the right system, it’s to ship a system you understand and can keep improving. The bar isn’t perfection. I am just trying to be deliberate.

The protocol (the actual CLAUDE.md, the hooks, the git hook script) is in my GitHub repo you can fork, modify, and use. The post is the architecture. The repo is the implementation. Take what’s useful, leave what isn’t.

You can just do things with these tools. I think you should also be safe about it and the two aren’t in tension. They live in the same system.

Until next time, GM.

---

Written with Claude Opus 4.7 as a thinking and drafting partner.