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.
Inputs
- 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
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.
1---2name: hook-safety-review3description: 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.4---56## Purpose78Review 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.910## When to Use1112- A hook recipe (safety, quality, productivity) is a candidate for activation13- An agent settings file gains or changes a lifecycle hook entry14- A git pre-commit or pre-push hook is added or edited15- A hook snippet arrives from outside the repo1617Do 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.1819## Inputs2021- The hook definition: command body, trigger event, matcher pattern22- The settings or recipe file that declares it23- What the hook can reach: environment variables, file paths, network2425## Workflow26271. **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.28292. **Scan for command injection.** Any user- or model-controlled value interpolated into a shell string is a P0 until proven bounded:3031 ```sh32 rg -n '\$\{?[A-Za-z_]+\}?|\$\(|`' <hook-file> # interpolation and substitution33 rg -n 'eval|sh -c|bash -c|Invoke-Expression' <hook-file>34 ```35363. **Scan for outbound network.** Hooks should not phone home:3738 ```sh39 rg -n 'curl|wget|nc |Invoke-WebRequest|Invoke-RestMethod' <hook-file>40 ```4142 Any hit needs a documented justification and explicit user approval.43444. **Scan for silent failure.** Error suppression hides both bugs and attacks:4546 ```sh47 rg -n '\|\| true|2>/dev/null|2>\$null|exit 0' <hook-file>48 ```4950 A hook that swallows its own failures cannot be trusted to gate anything.51525. **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.53546. **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.5556## Output5758- A per-hook verdict: enable, fix-then-enable, or reject59- Findings listed with level, line reference, and a concrete fix each60- An explicit "no findings" statement when the hook is clean6162## Verification6364- [ ] Trigger event and matcher breadth were identified before reading the body65- [ ] Injection, network, and suppression scans were actually run, not eyeballed66- [ ] Every P0/P1 finding carries a line reference and a concrete fix67- [ ] No hook was enabled during the review — the verdict and the enablement are separate, user-approved steps6869## Failure Modes7071- **Eyeball-only review** — skimming the body instead of running the scans lets obfuscated interpolation through.72- **Reviewing one file, enabling another** — the content reviewed must be exactly what gets enabled, byte for byte.73- **Matcher blindness** — a benign-looking body behind a catch-all matcher still runs everywhere; breadth is part of the risk.74- **Review-as-enablement** — this skill ends with a verdict; turning the hook on is a separate, explicit user decision.
yeaight7