Rules the agent
cannot decline.
The baseline is an opinion your team already holds, written down and then enforced below the layer Claude can reach. This page explains what it is, and why enforcement has to live where it does rather than in a prompt.
The problem with prompt-level rules
Leave Claude Code alone on a real codebase for long enough and it will push to main without review, amend a published commit, mock the database in a test, or sign off on its own spec. Each time, Claude Code is working exactly as designed. What is missing is a rule your team already agrees on, written down somewhere the agent has no choice but to obey it.
The baseline is that rule set, written down and enforced below the layer Claude can reach. It installs into your repo: 27 hooks, 59 skills, one subagent, an eleven-phase workflow, 3 consent gates, and 9 workflow tracks you can pick from. You bring your own Claude Code.
The tool boundary
What matters is where the rule lives. If you put it in a prompt, a memory entry or a CLAUDE.md paragraph, you are asking the model to follow it, and a model may comply unevenly. Put the same rule in a hook and it becomes a program which runs before the tool call and decides whether that call happens at all.
The hooks run on seven events. Twenty of them sit on PreToolUse, where they see a Write, Edit or Bash call before it runs and may answer block, ask or allow; three run on PostToolUse and can only report on what the call produced. The rest cover the session itself: one on UserPromptSubmit, one at SessionStart, three on Stop, one on Notification, and one before context is compacted.
Add those up and you get 30, which is more than the 27 scripts under .claude/hooks/. One script, notify, is wired on three events and counts once in each, and it also lives outside that directory. Every other hook runs on exactly one event.
Because a guard runs before the model is consulted, a blocked call ends at the guard: Claude receives the refusal in place of a result and has to work from that.
The consent handshake
Consent is the sharpest case, because it is the one an agent has the most reason to work around.
When you type /grant-commit, consent_gate_grant runs on UserPromptSubmit, an event which fires before Claude is invoked on that turn, and it writes a short-lived single-use marker to disk. Later, when Claude tries to write an approval token, a second guard on PreToolUse will allow the write only while that marker is still fresh. The same guard blocks Claude from writing the marker itself.
Claude cannot reach the UserPromptSubmit code path, so the input the second hook checks can only come from a human typing the command.
Authority and precedence
docs/init/seed.md. The specification the whole overlay is rebuilt from.
CLAUDE.md. Binds Claude's behaviour inside a session.
The hooks and skills that actuate the two above.
The guards themselves, running outside the model's reach.
Each layer binds the ones below it. If the constitution and the code disagree, the constitution wins and the code is what gets fixed; should seed.md and the constitution disagree, work stops until a human has been told about the drift.
audit-baseline checks all of this on every CI run, comparing a shipped list of per-file sha256 hashes against what is actually on disk and failing when the two differ. Every number on this page derives from that same source, so if a hook is added without the docs being updated the build breaks (rather than a sentence here quietly going stale).
Named exceptions
You can skip a workflow phase, but it takes a named exception which /triage records in the workflow state where the audit can find it. Turning a hook off is possible too, and that one takes an amendment to seed.md plus a matching settings edit.
Both routes leave a record behind, and both of them require a human.
Where to go next
To set this up in a repository, start with the install page. The reference pages hold what you will look up afterwards: the CLI commands and exit codes, the workflow tracks, the hooks, the skills, and the MCP servers.