A reminder can be forgotten by an agent; a supported hook can run a deterministic check. Neither replaces CI, and a hook configuration is only tested when the real client dispatches it.
- 1Tool event
- 2Hook handler
- 3Exit status
- 4Continue or stop
Work through the example
Use a synthetic protected file to test both denial and allowance. Then deliberately fail verification and inspect whether the client stops.
Start with a disposable branch and synthetic data. Write the expected outcome before changing the implementation, then keep the first failing result. This prevents a later repair from quietly redefining the task. The procedure below is grounded in the repository reference; its examples must still be checked against your project and installed toolchain.
Implementation reference
The following focused section is adapted from the maintained project guide. It preserves the source’s examples and limitations.
1. Hook vs. CI vs. reviewer
Three enforcement layers. Use the cheapest one that can decide the question.
| Layer | Decides | Cost | Feedback speed |
|---|---|---|---|
| Hook | Rules a script can evaluate | ~free | Immediate — model self-corrects mid-turn |
| CI | Same, plus full build/test | minutes | After push |
| Reviewer subagent | Judgment: is this correct, does it match intent | tokens | End of task |
The ordering matters. Spending a reviewer subagent on "did you use
DispatchQueue.main.async" is waste — a grep answers that for free, instantly,
and cannot be argued with. Reserve model judgment for what rules cannot express.
Rule of thumb: if you can write the check as a grep or an exit code, it is a hook. If it needs to understand intent, it is a reviewer.
Acceptance and failure review
| Checkpoint | What to inspect | If it does not match |
|---|---|---|
| Tool event | Confirm the input and environment | Preserve the failure and return to this step |
| Hook handler | Inspect the intermediate artifact | Preserve the failure and return to this step |
| Exit status | Run the focused check | Preserve the failure and return to this step |
| Continue or stop | Record the observed result | Preserve the failure and return to this step |
Ask the agent to explain the smallest change that resolves the observed mismatch. Keep unrelated refactors out of the repair. A change that makes a warning disappear is not enough if the behavior or ownership contract has changed. Re-run the same acceptance check so the before and after results are comparable.
Evidence and limits
Claude script-level checks and Muse Stop discovery have different scopes. Full cross-client enforcement remains unverified.
This is an educational guide. Its presence in the series does not certify a completed client-specific lab. The series evidence record separates executed checks from exercises and blocked environments.
Inspect the source used in this lesson.
Related reading
- How can Claude Code hooks protect generated files and verify a project before stopping?
A tested generated-file guard and Stop check, with configuration, reproducible exit codes, and enforcement limits.
What to do next
Next: Making the agent prove it: screenshots as evidence, not "done"