Preventing Direct Commits to Main with Claude Hooks

Is this is the future: baby-proofing environments so we can hand development to agents we just can’t trust to behave? You don’t have to let Claude even have unfettered git or terminal access, but if you must, these are good tips. Local git hooks are one way to stop coding assistants commit to branches they shouldn’t. Protected branches at the remote are necessary, too. Maybe trade a little speed for peace of mind. It’s pretty dang fast that they are writing the code to begin with; it won’t kill you to read the terminal commmands they want to run. In fact, it might save you quite a bit of trouble. #claude #ai #security #git

Loved this example. As we experiment with AI in development workflows, it’s becoming clear that guardrails in the system matter more than instructions in the prompt.

It’s funny how people ask AI why it did something they didn’t ask for or why it broke some established rules.

Just wanted to reshare a great post from my colleague Taylor Keazirian. Her willingness to share her AI experiences in the open, including the missteps and adjustments, is exactly where real learning happens. Really appreciate the transparency!

I was exploring Claude hooks and found out it has so many good use cases. Like preventing Claude from touching your .env files There are two types of hooks: - PreToolUse — runs before Claude executes anything, you can block it - PostToolUse — runs after Claude executes, you can give feedback but can't block For blocking .env I used PreToolUse. Here is how I set it up: - Created a small script that checks which file Claude is trying to open - If it's the .env file, it blocks it and notifies Claude - Added that script to .claude/settings.local.json - Restarted Claude. And this is just one tiny use case. You can run your type checker after every code change, catch errors instantly, and Claude fixes them itself. Also run code formatter after file edits, auto run tests after changes, block deprecated functions, check for TODO comments, block variables that don't follow naming conventions and a lot more. Hooks basically let you decide how Claude behaves in your project.

I'm actually salivating right now... Here's the phase table as it stands in the queue, Kojie! ✨ Phase 2 established that every turn is system-classified before model invocation. Phase 3 makes the system honest and capable inside that boundary. Phase 3 established turn governance. Item Status 3a: Host adapter identity enforcement at ingress ✅ done 3b: Minimal decision policy in conversation mediation ✅ done 3c: Minimal intent signal in mediation output (conditional) ✅ done Phase 4 — Behavior design inside the boundary. Phase 4 defines what each turn class actually does. Item Status 4a: Introduce ingress surface field in runtime context ✅ done 4b: system_query response policy ✅ done 4c: command_followup context preservation ✅ done Phase 5 — Provider architecture Item Status 5a: Provider registry as single source of truth ✅ done 5b: Provider selection policy ✅ done 5c: model_host becomes derived ✅ done 5d: classification precedence fix (system_query > command_followup) ✅ done All phases fully closed. 💖 No active phase in progress right now — the queue is clean and ready for Phase 6 whenever you define it.

𝗧𝗵𝗲 𝗜𝗺𝗽𝗼𝗿𝘁𝗮𝗻𝗰𝗲 𝗢𝗳 𝗘𝘅𝗰𝗲𝗽𝘁𝗶𝗼𝗻 𝗛𝗮𝗻𝗱𝗹𝗶𝗻𝗴 𝗜𝗻 𝗝𝗮𝗵𝗮 You need to handle runtime errors in your program. This is where exception handling comes in. It prevents your program from crashing when an error occurs. Here are some key benefits: - Prevents program crash: without exception handling, your program stops when an error occurs - Maintains normal program flow: even if an error happens, the rest of the code still runs - Separates error-handling code from regular code: makes your code cleaner and easier to read - Helps in debugging: you can print error details to understand the problem - Allows custom error messages: you can give meaningful feedback instead of cryptic errors For example, without exception handling, this code will crash: int a = 10; int b = 0; System.out.println(a / b); But with exception handling, you can handle the error and continue running your program: try { int a = 10; int b = 0; System.out.println(a / b); } catch (ArithmeticException e) { System.out.println("Cannot divide by zero"); } Source: https://lnkd.in/gKS5va7H

Claude Code's context window isn't 200k tokens — it's closer to 160k once system prompts and tools load in. And performance degrades way before it hits 100%. Three things worth knowing: → Run /context to see exactly what's eating your tokens → /compact mid-task = bad. /compact after a task = good → CLAUDE.md is the only thing that survives a compaction Work smarter inside the window, not against it.

Just gave this instruction to Claude Code, and I think it’s a pretty good norm: “Please create new universal intructions to allow no black boxes, but for everything I build, to create clear, plain-language documentation explaining where all the data comes from, what assumptions are embedded, what calcuations were performed, etc.”

Advanced Kody tip: don’t apply the same review logic to every PR. A small fix, a large refactor, and a breaking change need different checks. With PR variables, you can make Kody Rules adapt to the PR context, like size, labels, description, and number of files changed. Create a Pull Request rule, click Variables, and use them directly in the instructions.