Raising Claude Code - Part 6: Operations

Across the previous five posts I covered the mechanisms for raising Claude Code:

• Part 1: Concepts (persuasion vs. enforcement)
• Part 2: Enforcement (permissions.deny for prohibition + Hooks for automation)
• Part 3: Persuasion (writing CLAUDE.md)
• Part 4: Extension (when to use Skills vs. Subagents)
• Part 5: Subagent implementation (concrete authoring, role design, multi-agent coordination)

This is the final post — Operations: the improvement loop and the anti-patterns that keep these mechanisms healthy over time.

Incident-driven beats everything

Try to design the perfect setup up front and you will almost certainly fail.

Why:

• Rules written from imagination drift from reality
• Unused rules accumulate
• Contradictory rules creep in

Instead:

👉 Add a rule the moment an incident calls for one.

This is the iron rule of Claude Code operations.

The improvement loop, applied at incident time

When something goes wrong, do this on the spot:

1. Ask Claude where it belongs. — e.g. “To prevent this mistake from happening again, should the rule live in CLAUDE.md / Skills / Hooks / Subagents / settings.json?”
2. Pick “persuasion or enforcement” using the criteria below.
3. Have Claude draft the rule; you review and adopt (the adoption decision stays with you — same principle as Subagent output).
4. Run the replay test — this is the step that gets skipped most often.

Criteria:

• One-strike fatal → physical block via settings.json deny
• Bad if broken, but no big incident → CLAUDE.md
• Mechanical check that should run every time → Hooks
• Reusable procedure → Skills
• Different role / separate context needed (the main role can’t carry it) → Subagent

Always run the replay test

Don’t stop at “I wrote it down.”

When you add a new rule:

• Same session — reproduce the same operation, confirm the rule actually fires
• Fresh session (after /clear) — reproduce again, confirm it survives a session boundary

CLAUDE.md in particular has a habit of being injected but ignored. If you don’t check the moment you write it, your operations rot under the assumption that “this is working.”

Aside: where auto memory fits

Claude Code has an auto-memory feature: it quietly accumulates things it has learned from conversations into files. User preferences, past corrections, project-specific facts — all auto-captured.

memory / Skills / Hooks / CLAUDE.md / settings.json differ in trigger, enforcement, and cost. The same information behaves differently depending on where you put it. auto memory is best for:

• Flowing information — pending tasks, in-progress project state
• Conventions where forgetting isn’t fatal — naming, formatting
• Personal-local context — your preferences, past exchanges

It’s a poor fit when:

• You can’t see what got recorded → for accident prevention, use Hooks
• It can’t be shared with the team (local-personal) → shared rules belong in CLAUDE.md / settings.json
• It doesn’t show up in Git → version-controlled conventions belong in CLAUDE.md

👉 “memory works” and “memory is optimal” are different. Heavy-incident cost → Hooks. Reusable procedures → Skills. Invariant baseline → CLAUDE.md. memory fills the gap underneath: flowing information where forgetting is acceptable.

Anti-patterns to avoid

The ones that bite hardest in practice:

• ❌ Over-conformance rules — e.g., “every function must have a docstring” → a one-line fix turns into a documentation diff and pollutes git
• ❌ Heavy work in Hooks — full test suite, full build → minutes of waiting per edit, dev experience collapses
• ❌ permissions.allow: Bash(*) — grants everything and silences confirmations. Narrow the scope
• ❌ Writing only the prohibition, no alternative — Claude stalls with no path forward
• ❌ Piling prohibitions into CLAUDE.md — things that should be enforced via settings.json get left to persuasion and slip through
• ❌ Adding rules pre-emptively, before any incident — accumulates rules nobody uses

Application priority (recap)

If you’re starting fresh, in this order:

1. Write permissions.deny in .claude/settings.json (accident prevention is highest priority)
2. Start CLAUDE.md under 50 lines — role and decision axes only
3. Hooks: lint and format only. Don’t put the full test suite in
4. When you’ve written the same long prompt 3 times → extract to a Skill
5. When CLAUDE.md alone starts breaking the role → split into a Subagent

Try to set everything up at once and you’ll be left with a config you can’t maintain.

Periodic cleanup

About once every three months, do this pass:

• Delete unused rules / Skills
• Resolve contradictions
• Check CLAUDE.md line count (split if it’s over 200)
• Walk through the incident log and check for gaps in rule coverage

Rules-only-grow-never-shrink rots over time. Build pruning into the loop, not just adding.

Series wrap-up

Six posts in, here’s the framework and operations for raising Claude Code.

Three core ideas:

1. Don’t confuse persuasion and enforcement. Accident prevention belongs in permissions.deny (prohibition); after-edit checks belong in Hooks (automation). Both live in settings.json.
2. Grow incident-driven. Don’t write from imagination.
3. Verify with replay tests. Don’t stop at “I wrote it down.”

Claude Code is not magic, and not a junior engineer. It’s a different MIT student intern arriving every morning, with no memory of yesterday.

So you write things outside, block what’s dangerous, and automate what repeats. That’s what “raising it” actually means.

A lot has been written, but humans forget and Claude forgets too. If you’re stuck, hand this series to Claude Code and ask — it should give you the right answer.