name: hook-safety-review
description: Use when a hook is about to be enabled or modified -- a hook recipe proposed for activation, a pre/post-tool or lifecycle hook added to agent settings, a git pre-commit hook added to a repo, or a third-party hook snippet pasted in from outside.
Purpose
Review a hook definition before it is enabled so command injection, data exfiltration, and silent failure cannot ride in on automation. Hooks run automatically with the agent's privileges; a malicious or sloppy hook executes without any further review once it is on.
When to Use
- A hook recipe (safety, quality, productivity) is a candidate for activation
- An agent settings file gains or changes a lifecycle hook entry
- A git pre-commit or pre-push hook is added or edited
- A hook snippet arrives from outside the repo
Do not use for broad agent-config audits — that is the agent-config-security-audit skill. This skill is the enablement gate for one hook at a time.
- The hook definition: command body, trigger event, matcher pattern
- The settings or recipe file that declares it
- What the hook can reach: environment variables, file paths, network
Workflow
- Inventory the trigger surface. Identify the event (pre-tool, post-tool, session start, commit), the matcher pattern, and how often it fires. A catch-all matcher on a high-frequency event deserves the strictest review.
- Scan for command injection. Any user- or model-controlled value interpolated into a shell string is a P0 until proven bounded:
rg -n '\$\{?[A-Za-z_]+\}?|\$\(|`' <hook-file> # interpolation and substitution
rg -n 'eval|sh -c|bash -c|Invoke-Expression' <hook-file>
- Scan for outbound network. Hooks should not phone home:
rg -n 'curl|wget|nc |Invoke-WebRequest|Invoke-RestMethod' <hook-file>
Any hit needs a documented justification and explicit user approval.
- Scan for silent failure. Error suppression hides both bugs and attacks:
rg -n '\|\| true|2>/dev/null|2>\$null|exit 0' <hook-file>
A hook that swallows its own failures cannot be trusted to gate anything.
- Check scope and privilege. Does the body read or write outside the repo? Does it touch credentials, dotfiles, or agent config? Flag absolute paths and home-directory access.
- Classify and report. Use the same levels as the security-audit command: P0 direct risk (injection, exfiltration, secret access) — do not enable; P1 weakened controls (suppression, over-broad matcher) — fix before enabling; Note — best-practice gap, log it.
Output
- A per-hook verdict: enable, fix-then-enable, or reject
- Findings listed with level, line reference, and a concrete fix each
- An explicit "no findings" statement when the hook is clean
Verification
- [ ] Trigger event and matcher breadth were identified before reading the body
- [ ] Injection, network, and suppression scans were actually run, not eyeballed
- [ ] Every P0/P1 finding carries a line reference and a concrete fix
- [ ] No hook was enabled during the review — the verdict and the enablement are separate, user-approved steps
Failure Modes
- Eyeball-only review — skimming the body instead of running the scans lets obfuscated interpolation through.
- Reviewing one file, enabling another — the content reviewed must be exactly what gets enabled, byte for byte.
- Matcher blindness — a benign-looking body behind a catch-all matcher still runs everywhere; breadth is part of the risk.
- Review-as-enablement — this skill ends with a verdict; turning the hook on is a separate, explicit user decision.