claude code · governance layer

Claude Code cannot
self-approve.

baseline is an open-source governance layer for Claude Code. It covers your codebase from intake to commit, and enforces every rule at the tool boundary, where Claude cannot reach.

read the docs →
~/your-project · claude
Cannot self-approve.
3 user-typed gates
Cannot bypass a guard.
27 hooks, outside the tool boundary
Cannot silently skip a phase.
11 phases, exceptions on the record

Every rule traces to a named authority.

Memory, prompts, and skills shape what Claude does. The hooks are what enforce it. Four strata, one overlay, and a precedence order that decides which one wins.

four strata
IGenesisseed.md
IIConstitutionCLAUDE.md
IIIImplementationhooks · skills
IVTool boundaryguards
01 · constitution

Twelve articles bind the session

Authority, architecture, workflow ordering, engineering rules, git rules, and memory are each fixed by an Article. Where two strata disagree, the higher one wins, so a lower stratum can never quietly widen its own permissions.

02 · enforcement

27 hooks at every boundary

Pre- and post-tool-use guards block destructive commands, gate consent markers, and enforce phase ordering as the tool call is made.

03 · workflow tracks

9 canonical tracks, declared as data

intake-full spec-entry tdd-quickfix chore freeform epic epic-child org power

A blocked tool call never runs.

Enforcement here is a process that runs before the call, on the other side of a boundary the model has no path to. These guardrails are not instructions Claude can choose to follow. When a guard denies a call, Claude receives the refusal in place of a result and must work from that.

The Claude Code tool lifecycle and the hook boundary beneath it A user prompt passes to Claude, which reads, plans and picks a tool. The tool call — Write, Edit or Bash — returns a diff, output or an error, and the result passes back. Below that lane, outside Claude's reach, sit three hook events: UserPromptSubmit, where consent_gate_grant writes the consent marker; PreToolUse, where the guards block, ask or allow; and PostToolUse, where lint_runner and test_runner run. user claude tool result prompt read plan pick Write Edit Bash diff output error UserPromptSubmit PreToolUse PostToolUse consent_gate_grant writes the marker the guards block · ask · allow lint_runner test_runner outside Claude's reach The Claude Code tool lifecycle and the hook boundary beneath it A user prompt passes to Claude, which reads, plans and picks a tool. The tool call — Write, Edit or Bash — returns a diff, output or an error, and the result passes back. Below that lane, outside Claude's reach, sit three hook events: UserPromptSubmit, where consent_gate_grant writes the consent marker; PreToolUse, where the guards block, ask or allow; and PostToolUse, where lint_runner and test_runner run. user claude tool result prompt read · plan · pick Write · Edit · Bash diff · output · error UserPromptSubmit PreToolUse PostToolUse consent_gate_grant writes the marker the guards block · ask · allow lint_runner test_runner outside Claude's reach

The tool boundary. consent_gate_grant writes the marker on UserPromptSubmit, before Claude is invoked on the turn. The paired PreToolUse guard validates that marker before an approval-token write is allowed. Claude cannot reach the first hook, so it cannot manufacture the input the second one checks. That pairing is what makes consent unforgeable.

11 phases, and none can be skipped.

A track is a DAG of skill nodes. Here is intake-full, request to commit, with the gates you type marked in orange. If a phase has to be skipped it takes a recorded exception, which the audit can see afterwards.

The intake-full workflow track, request to commit Phase 1 intake, then 2 scout, then 3 research. The user-typed gate slash approve-direction follows. Then phase 4 spec, the plan anchor. Then phase 5 review, a machine gate: shippability and a checker fan-out, which blocks entry to phase 6 when it fails. Then phase 6 tdd, running scenario, implement and verify, as a swarm by default and solo when the project is not a git repository. Then 7 simplify, 8 security, 9 integrate and 10 document. Then 10.5 archive, 10.6 roadmap-sync and 10.7 memory-sync. Then the user-typed, branch-aware gate slash grant-commit. Then phase 11, commit. 01 intake 02 scout 03 research 04 spec 05 review 06 tdd 07 simplify 08 security 09 integrate 10 document 10.5 archive 10.6 roadmap-sync 10.7 memory-sync 11 commit /approve-direction /grant-commit user-typed plan anchor machine gate · blocks entry to 6 scenario ▸ implement ▸ verify swarm default · solo without git branch-aware ship The intake-full workflow track, request to commit Phase 1 intake, then 2 scout, then 3 research. The user-typed gate slash approve-direction follows. Then phase 4 spec, the plan anchor. Then phase 5 review, a machine gate: shippability and a checker fan-out, which blocks entry to phase 6 when it fails. Then phase 6 tdd, running scenario, implement and verify, as a swarm by default and solo when the project is not a git repository. Then 7 simplify, 8 security, 9 integrate and 10 document. Then 10.5 archive, 10.6 roadmap-sync and 10.7 memory-sync. Then the user-typed, branch-aware gate slash grant-commit. Then phase 11, commit. 01 intake 02 scout 03 research 04 spec 05 review 06 tdd 07 simplify 08 security 09 integrate 10 document 10.5 archive 10.6 roadmap-sync 10.7 memory-sync 11 commit /approve-direction /grant-commit user-typed plan anchor machine gate scenario ▸ implement ▸ verify branch-aware ship
the 3 gates
■ /approve-direction ■ /approve-swarm · in phase 6 ■ /grant-commit

All 3 are commands you type. Because Claude cannot reach the code path that writes the markers, and a guard blocks it from writing them directly, there is no route by which it can approve its own work.

/grant-push is a fourth command you type, but it is not one of these gates. It clears a single push at the moment the push runs, rather than opening a phase.

Under github-flow, an autonomous feature on a non-protected branch omits /grant-commit and opens a pull request instead.

install and see all 9 tracks →

One subagent, and it decides nothing.

Decisions live in main context, where the whole conversation is visible. Subagents only execute recipes that were already decided.

main context

Where decisions live

Architecture, scenario selection, recipe design and security calls: anything that depends on seeing the whole conversation.

scout · research · spec scenario decide implement decide merge audit
isolated worktree

Where execution runs

Each swarm-worker executes a fully-specified recipe inside its own git worktree, and may not make design choices, widen scope, or edit a test. When it finishes, a merge audit checks what it wrote against the write set it was given.

Skill(scenario) Skill(implement) tests pass · fail JSON status returns

Adoption is one command.

One npx command lays down the full overlay (hooks, skills, subagent, MCP servers, and the constitutional documents), and sets up a CI posture by default.

01

Run the overlay command in a clean working tree.

02

Open the repo in Claude Code, or the JetBrains / VS Code extension.

03

Run /init-project to tailor the config to your stack.

04

Drive work through /triage or /harness.

~/your-repo · zsh
# inside a clean git working tree
$ npx @friedbotstudio/create-baseline@latest .

# open in Claude Code, then:
> /init-project
> /triage "add user-facing onboarding flow"

Every answer names its mechanism.

What evaluators ask before installing. If an answer here cannot be traced to a file in the repository, it does not belong on this page.

No. If there is no fresh consent token on disk, git_commit_guard blocks the Bash call outright, and that token only appears when you type /grant-commit within the preceding fifteen minutes. The marker itself is written outside Claude's tool boundary.

To do something the baseline forbids, add a named exception through /triage. It is recorded in the workflow state, scoped to that one run, and visible to the audit afterwards, so the deviation stays on the record.

Yes, and it takes an explicit amendment to seed.md §4.1 plus the matching settings edit. The disable is constitutional, not silent.

When you have customized a file, the upgrade prompts you before anything moves. Every other path reconciles against the shipped manifest on its own: untouched files refresh, tier-2 files merge mechanically, and tier-3 files are staged for review.

No. The overlay is a ruleset and the machinery that enforces it: hooks, skills, and the workflow tracks. You bring your own Claude Code.

You keep them out of the overlay entirely. env_guard blocks every write that targets a .env file, and .env.example is generally the only exception it will allow.

also ships · off by default

A feature can span more than one session.

A flat pod of peer sessions can take one feature between them, governed by Article X. A second command reads your release state, backlog and open questions, then says what to pick up next.

Install it in a clean tree.

Apache 2.0 · open source · public alpha, under active development.