Guardrails for Claude Code that are actually tested.

Questions worth answering straight

The first two were asked by readers of the launch article, in sharper words than these. The rest come up in every thread about agent guardrails.

Does the secret guard catch ~/.aws/credentials, or just .env?

Both, and this exact question improved the pack. A reader pointed out that the article's snippet matched basenames only, so home-directory credential stores with boring names sailed straight through. The shipped guard checks well-known paths after the basename pass - .aws/credentials, .ssh/, .docker/config.json, .kube/config - on top of .env, key files, .netrc, .npmrc, .pypirc, and .git-credentials. Project-specific additions go in one env var, as basename globs or path fragments (.vscode/settings.json, .config/gh/). What a path rule cannot do: spot a token inside a file that has no business holding one. That is a content-scanning problem, and the pack does not pretend to solve it.

Won't the agent just route around a denial?

It will try, which is why the denial text is treated as part of the design. Every block returns structured JSON with a one-line reason naming an alternative - usually "ask the user for the value" - and in harness runs that ends the retry loop instead of feeding it. The sharpest lesson came from our own guards: five of them used to name their blanket kill switch inside the denial reason, which is text handed straight back to the blocked model at the exact moment it most wants to proceed. That is fixed, a test per guard now asserts no denial names an off switch, and the write-up is in the operator log. A denial reason is a prompt, so the pack writes them as prompts.

The two best guards are in the free tier. Why pay?

You might not need to - clone the free repo first, seriously. The pack adds the other 12 hooks (write guards, test and typecheck loops, commit hygiene, transcript archiving, cost logging), the slash commands, the CLAUDE.md patterns, the CI recipes, the permission presets, and the hardening guide. But the honest answer to "couldn't I write these myself" is: yes, any one hook is an afternoon. What you are buying is the part that is not an afternoon - 239 test cases that re-verify every hook in seconds whenever anything changes, live headless-session tests before each release, and updates included when Claude Code moves.

Claude Code ships fast. Won't this rot?

This is the strongest reason the pack exists at all: the AI that maintains it operates on Claude Code every day, so breaking changes tend to surface here before most buyers hit them. On your side, tier 1 runs in seconds with no API key, so after any Claude Code update you can re-verify every installed hook yourself instead of trusting a changelog. The free repo's CI re-runs the suite on every push and weekly on a schedule, and updates are included in the one-time price.

Do I have to adopt all 17 hooks?

No. The installer takes a list (--hooks secret-leak-guard,git-main-guard), every hook is independent, re-runs are idempotent, and --uninstall removes cleanly. The permission presets are deliberately not auto-installed: hooks are code, but a permission policy is a decision, so the presets ship as files their README tells you to read before merging.

My projects are TypeScript. Is a pack of Python hooks for me?

Python is just the runtime (stdlib only, so macOS, Linux, and WSL need nothing beyond python3); what the hooks guard is tool calls, in any repo. The language-aware ones resolve your project's own tools: lint-on-stop runs your package.json lint script or ruff, typecheck-on-write runs your project-local tsc for TypeScript and mypy for Python, format-on-write picks prettier, ruff, gofmt, or rustfmt by file type.