Permissions, hooks, slash commands

Status: drafted · Time: 20 min · Audience: daily-builder Outcome: Use permissions, hooks, and slash commands as daily safety rails instead of speed hacks.

White Belt taught you not to click yes blindly. Yellow Belt adds the daily harness: permissions, hooks, and slash commands. These are not decorations. They are how repeated AI work stays safe when you are moving faster.

If you’re short on time

Permissions decide what the assistant can do right now.
Hooks run repeatable checks at known moments.
Slash commands package approved workflows so you do not rebuild them from memory.

The mental model

Permission = should this action happen?
Hook       = what check should run at this moment?
Slash      = what approved workflow should I invoke?

You can ship without fancy automation. But once you work daily, repeated manual checks become easy to skip. Harness turns those checks into a path.

Permissions: the live gate

Approve when:

the action matches your prompt;
the file or command is expected;
the result is reviewable;
the scope is small.

Deny when:

the command is broad;
the action touches unrelated files;
the assistant asks for elevated authority;
the task has drifted;
you cannot explain why the action is needed.

Prompt:

Before asking for permission, explain why this action is needed and what output you expect.

Hooks: the repeated checks

Hooks are useful when a check should run predictably:

before a PR is opened;
after a file edit;
before running a risky command;
after tests fail;
when a branch has unexpected files changed.

Yellow Belt readers are not expected to author complex hooks. You should know what a hook is doing when one fires.

Good hook behaviour:

Changed files include generated output. Confirm before proceeding.

Bad hook behaviour:

Silently rewrites half the repo.

If a hook surprises you, stop and inspect.

Slash commands: packaged workflows

Slash commands are shortcuts for known workflows. Examples:

orient in repo;
run a pre-PR sanity pass;
summarize branch state;
prepare a PR description;
run a design compliance check.

Use them when the workflow is established. Do not use them to avoid understanding. A slash command should make the right path faster, not make the wrong path invisible.

Worked example: verify a pre-PR workflow

Before opening a PR, discover the workflows this session actually has:

/help

Look for an installed workflow whose description says it reviews a branch or diff before PR. The exact name depends on the plugin and repository you loaded. An old command in notes is not proof that your current session supports it.

If /help does not list a suitable workflow, do not guess a command name. Follow the manual PR flow in Y.13 instead.

Before acting on any workflow result, use this review point:

PRE-PR WORKFLOW REVIEW
[ ] The command appeared in /help before I ran it.
[ ] Changed files match the change I intended.
[ ] Checks name what actually ran and what did not run.
[ ] Risk notes match the diff, not a generic template.
[ ] I inspected git status and git diff myself.

If any box is unclear or the workflow reports unrelated files, stop and inspect before pushing.

Common failure modes

“I used a slash command without reading the output.” The command is not magic. The output is the review point.

“A hook failed and I bypassed it.” First understand the failure. Hooks exist because someone saw the mistake repeat.

“Permission prompts became background noise.” Slow down. That is the moment to reset.

“Automation edited something surprising.” Use git status and git diff immediately.

GREEN / YELLOW / RED self-check

You are GREEN if:

you can explain permission, hook, and slash command in one sentence each;
you read workflow output before continuing;
you inspect diffs after automated actions;
you deny surprising actions.

You are YELLOW if:

hooks fire but you do not know why;
slash commands feel useful but opaque;
you approve commands from habit.

You are RED if:

automation changed files you cannot explain;
you bypass failed checks;
you use always-approve while unfamiliar with the workflow.

What you can say after this module

“I can use the daily safety harness without surrendering judgement to it.”

Previous: Y.6 Reading unfamiliar code - Next: Y.8 LiteLLM and Claude workspace access