Sentinel

Each prompt identifies which agent it is running under and adapts to it. That includes the name of the persistent context file, the permission mechanism, and any automatic commit attribution the tool adds. The context file is AGENTS.md for most tools and CLAUDE.md for Claude Code.

You can also run a single prompt. Paste its contents into a session, or ask the agent to read and run the file. When you want to review between stages, need only one or two prompts, or are re-running part of the suite after an update, run the prompts individually.

The best order is 0, 1, 2, 3, since each stage reads what the previous one produced. Prompts 1 and 2 can run without 0, though you’ll fill in the project details yourself. Prompt 3 requires INTEGRATION_CHECKLIST.md. If it’s missing, prompt 3 tells you to run 2 first.

Prompts 0 through 2 pause to ask questions, and your answers become permanent parts of the hook that prompt 3 builds. Where a question has fixed answers, the agent will show clickable options if your tool supports them.

Without version control, prompt 3 builds a manual command instead of a hook. That command checks for a .git directory each time it runs and offers once to switch to a real hook if one appears. A version control system with its own trigger mechanism, such as Perforce, is treated the same as git.

The manual command is also used for any Sentinel output you choose to keep out of version control, since a hook can’t see ignored files. When git is in use but you choose the manual command, commit-message rules are still checked against your most recent commit after the fact.

Prompt 2 reads any existing system for known weaknesses, such as checking the working tree instead of staged files, or failing silently. It then asks whether new checks should follow that system’s style or Sentinel’s.

If one exists, the audits check the code against it. If not, you’re asked before one is created. A generated design document reads as ordinary documentation, but it won’t state a rationale as fact without evidence.

Once a design document exists, it gets two checks. One is a per-commit gate for architecturally significant changes. The other is an occasional review, tied to releases, that confirms its content is still true.

A full graphical interface (web, mobile, desktop, or game) gets the complete design audit. A presentational surface without a GUI, such as a CLI’s color scheme, gets the parts that apply. A backend service or library gets only the code-quality section.

If you add something with no precedent in the project, name it and ask what covers it. The agent will point you to the right prompt and section.

Prompt 3 asks once whether the agent should confirm every commit (the default), commit freely but confirm before pushing, or run fully automatically. Your answer is recorded in AGENTS.md.

Whatever style you pick, commit messages are written in your voice and describe the change. No “at the user’s direction,” no mentions of the agent or the session, and no trailers the agent makes up. A trailer is a line at the end of a commit message in the form Name: value, such as Co-authored-by:.

The hook rejects trailer-shaped lines that aren’t on your allowed list, and a short list of agent-voice phrases. The phrase list is weaker than the trailer check and will miss wordings it doesn’t contain, so the rule also lives in AGENTS.md.

The hook enforces this as a hard block. If a change is too broad for one honest subject line, split it into several commits.

The subject line alone is the norm. A short bullet body is allowed only when a change has three or more separate parts, or a behavior change a later reader needs to know about.

The hook accepts no body or a valid bullet body and blocks prose. It can’t judge whether a body was needed, so the trigger is also recorded in AGENTS.md.

If you pick the terse comment style, comments are limited to one or two sentences. Longer explanations go in AGENTS.md, not in the code.

If the agent finishes an unrelated task while TODO.md items remain open, it mentions them briefly before ending its response.

The agent keeps Sentinel-Notes/HANDOFF.md current while it works: what’s in progress, what failed, and the next steps in order. It rewrites the file as each step finishes, so closing the window or a crash loses at most the last step. Telling the agent you’re done before you close still gives the most complete handoff.

The next session reads it before anything else, then the open TODO.md items. If the handoff doesn’t account for uncommitted changes, that session says it may be out of date.

If your setup already uses a handoff file, the agent uses that one instead. It still writes the rules for that file into AGENTS.md, because your personal configuration and the agent’s own memory don’t reach a cloud or remote session.

The agent also records a short close-out that covers the handoff, any log you keep, and any step that needs your approval. It ends the close-out with one line saying what was done and what was skipped. If you sometimes work in remote sessions, it asks once, because those sessions see only what is committed to the repository.

Where your tool can run a command at session start, prompt 3 offers a hook. The hook puts the handoff in front of the agent automatically, so reading it doesn’t depend on the agent remembering to.

Versions are written major.minor.patch, and a recorded two-part version such as 1.1 means 1.1.0. Prompt 0 carries a version history listing what each release changed, where, and how to tell whether a project already has it. The agent applies changes that only add standing notes to AGENTS.md directly, without re-running a full audit.

If you run the prompts individually, decide what the update actually changed. If it only affects gate-check implementation, run 0 and then 3. If it adds a new design check, re-run 1. If it adds a new integration gate category, re-run 2 before 3, since 3 can only build what 2 has proposed.

Exceptions

A sentinel-exceptions file for documented, owned, expiring exceptions. If you choose it during setup, you also get a Sentinel-Override: <reason> commit trailer for one-off cases. Only you write it, never the agent. Both are deliberate acknowledgments.

A TODO.md sync check

A hard gate for items linked to a design brief, and a non-blocking reminder for everything else.

The pre-commit hook itself

Stored in a tracked location so it survives a fresh clone, plus a full-repo scan run on a schedule or on push.

A session-start hook (optional)

Where your tool supports one, it shows the agent any open handoff at the start of every session.

A new-file-category check

Flags the first file of a type the project hasn’t used before, such as the first image or the first 3D model. It asks a few questions to route the file to the right audit.