agentsclimarketplace

Hook safety review

Skill yeaight7/agent-powerups/plugins/security-guardrails/skills/hook-safety-review

Curated power-ups for coding agents: skills, slash commands, MCP configs, hooks, AGENTS.md templates, and workflows for serious software engineering. Claude Code, Codex, Antigravity CLI, Cursor and more

Install
npx -y skills add yeaight7/agent-powerups --skill hook-safety-review

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 6 stars6 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

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.

SKILL.md

3.6 KB, as published. Nobody here has run it

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

  1. 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.

  2. 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>
    
  3. 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.

  4. 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.

  5. 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.

  6. 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.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.