Roles, Models and Safety Rails
Hooks and Guardrails: Rails That Run Without You
Safety You Do Not Have to Remember
Hooks are scripts the runtime fires on events. The important ones for day-to-day safety:
| Hook | When | Effect |
|---|---|---|
secret-scanner |
Before Write/Edit | Blocks writing a secret |
guardrail |
Before shell commands | Blocks, nudges or asks confirmation on destructive commands via guardrail-rules.yaml |
commit-guard |
Before shell commands | Blocks inline git commit -m |
post-read-scrubber |
After Read/Bash | Scans output for secrets and redacts shell output |
path-guardrail |
Before Write/Edit | Enforces the output path schema |
Commits Go Through commit.js
Write the message to docs/.output/.state/.commit-msg, stage specific files, then run node .claude/core/commit.js. It normalizes the message and scans the staged set for secrets before committing.
git add path/to/file-a path/to/file-b # never git add . in a shared tree
node .claude/core/commit.js # commits only what is staged
--all sweeps everything and is unsafe when another process shares the working tree. The toolkit commits locally only; push, publish, deploy and PR need your explicit go-ahead.
One gap remains by design: a raw git commit typed in a plain terminal bypasses the staged-content scan. Use commit.js. Newly installed or changed native hooks may also need review or trust in your runtime before they run.
Why is `git add .` followed by a commit discouraged in this workflow?