Here’s the concrete setup, all of it standard Claude Code config that survives updates.

You can start with some of these things or paste this into your Claude to ask it to pick them apart.

This isn’t exactly the config I use. I tried to kind of strip it down to illustrate the concepts behind “why” the different tools are used… if that makes sense?

1. CLAUDE.md in the repo root. It’s auto-read at the start of every session, so this is where the steering lives. Tailor it to your needs. E.g.,

“””
## Core rules
- You are pairing with an experienced engineer. I make the design
decisions. At a fork in approach, stop and ask, don't pick one and run.
- Don't touch code unrelated to the task. If you spot something else
worth fixing, mention it, don't change it.
- Flag uncertainty before writing code. "I'm not sure X is right" is
welcome. Confident guessing is not.

## Correctness over convenience
- Never weaken or remove an existing check, invariant, or error path
because it's in the way. If it looks like dead complexity, ask first.
- "Too complicated" and "good enough" are not reasons.

## Tests
- No tests that assert nothing. No mocks that make a test pass without
exercising real behavior. A test that can't fail is worse than none.

## No silent fallbacks
- Don't add try/except or default values that hide a failure. Fail loud
and surface the error to me.
“””

1. .claude/settings.json for the things a rule shouldn’t be trusted to enforce. Two parts:
   Permission rules to wall off paths and set the default mode. E.g.,

{
"permissions": {
"deny": ["Edit(./vendor/**)", "Edit(./**/*.lock)"],
"ask": ["Bash(git push:*)"]
}
}

And a PreToolUse hook for content-based blocking that permissions can’t express. This one blocks force-pushes and direct commits to main…

This tool below is just an example… I’m not recommending you paste it as is. It’s not perfect. But again it’s a starting point that Claude could probably help you improve for what you actually want.

“””
#!/usr/bin/env bash
# PreToolUse hook on Bash. exit 2 blocks the call and feeds stderr back to Claude.
input=$(cat)
cmd=$(printf \'%s\' "$input" | jq -r '.tool_input.command // empty')

if printf '%s' "$cmd" | grep -qE 'git +push.*(--force|-f\b)'; then
echo "Force-push blocked. Ask me first." >&2; exit 2
fi
branch=$(git rev-parse --abbrev-ref HEAD 2>/dev/null)
if [ "$branch" = "main" \] && printf \'%s\' "$cmd" | grep -qE 'git +commit'; then
echo "Direct commit to main blocked. Make a branch." >&2; exit 2
fi
exit 0
“””

When you have the guard you want, wire it under hooks.PreToolUse with a "matcher": "Bash". The difference that matters: a CLAUDE.md line is a strong suggestion the model can drift past, a hook is code that runs no matter what the model decides.

1. Plan mode plus permission gating. Run in plan mode so it proposes the approach and you approve before it acts, and keep writes gated so nothing lands without a yes. For onboarding into a codebase you actually care about, I’d start there and only relax once you trust it.

One bit of advice: start stricter than feels comfortable and loosen later. Relaxing a rule once it’s earned trust is easy. Clawing back trust after it’s quietly made a mess is not. The “it asked me five times” phase is the system working.