claude-code - 💡(How to fix) Fix Users need reliable instruction enforcement without building a hook for every failure mode [2 comments, 2 participants]

I've been using Claude Code daily for months, across personal and work projects. The recurring failure is this: I write clear instructions in CLAUDE.md, memory files, and skill files. Claude reads them. Claude then does something else anyway.

This isn't about ambiguity. The instructions are specific. "Use the Edit tool, not sed." "Round times to the nearest 15 minutes." "Show your work before running a command." Claude acknowledges these rules, and then violates them — sometimes in the same session they were written.

The only thing that has actually worked is hooks. A PreToolUse hook blocking sed doesn't rely on Claude's attention. It fires every time, without fail.

But I shouldn't have to build a hook for every failure mode. That's not a configuration problem — that's a reliability problem. I currently have hooks blocking: sed, direct file writes via Bash, dangerous git commands, and direct edits to a specific file. Each of those hooks exists because Claude did the thing it wasn't supposed to do, sometimes destroying real work in the process.

What would actually fix this

1. A native pre-execution confirmation mode for irreversible actions. Before any Bash command, Write, or Edit that can't be easily undone, Claude states what it's about to do and why. One sentence. Not a prompt to the user — a visible commitment that can be caught before it lands. Today this requires a hook. It should be a first-class setting.

2. Skill file constraints enforced by the runtime, not by Claude. If a skill has disable-model-invocation: true, the runtime should prevent Claude from invoking it via the Skill tool — not rely on Claude remembering not to. The flag exists; it should have teeth.

3. A way to weight CLAUDE.md rules by severity. Right now all instructions are equal. A rule that says "don't use trailing summaries" and a rule that says "never use sed, it destroyed days of work" are treated identically. There's no way to mark something as inviolable at the instruction level — only at the hook level.

4. Visible instruction compliance. When Claude is about to violate a rule in CLAUDE.md, it should know it. A pre-execution check against stated rules — even a simple one — would catch the class of errors where Claude has the right instruction and ignores it anyway.

The core ask

The gap between "Claude knows the rule" and "Claude follows the rule" is too wide and too inconsistent. Hooks close that gap mechanically. The ask is to make that reliability available without requiring users to enumerate every possible way Claude might ignore what it was told.