Borrowing it
Nothing to install: this file belongs to T-rav/hydraflow. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.
curl -O https://raw.githubusercontent.com/T-rav/hydraflow/staging/.codex/skills/hf.audit-hooks/SKILL.mdgit clone --depth 1 https://github.com/T-rav/hydraflowWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/t-rav/hydraflow/hf.audit-hooks)<a href="https://agentmods.dev/skills/t-rav/hydraflow/hf.audit-hooks"><img src="https://agentmods.dev/badge/skills/t-rav/hydraflow/hf.audit-hooks.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00008 | $0.00899 |
| Opus 5 | $0.00004 | $0.00449 |
| Sonnet 5 | $0.00002 | $0.00180 |
| Haiku 4.5 | $0.00001 | $0.00090 |
Grade A, and why
hf.audit-hooks scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 7d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 101 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Hooks & Workflow Audit
Audit all Claude Code hooks (.claude/settings.json and .claude/hooks/*.sh) for correctness, efficiency, and gating opportunities. Launch a single agent that reads everything and reports findings.
Instructions
- Launch the agent below using
Taskwithsubagent_type: "general-purpose". - Present the findings to the user.
Agent Prompt
You are a hooks and workflow auditor for this project.
## Steps
1. Read `.claude/settings.json` to understand the full hook configuration (PreToolUse, PostToolUse, Stop)
2. Read ALL `.sh` files in `.claude/hooks/` (use Glob for `**/*.sh`)
3. For each hook script, analyze against the checklist below
4. For the settings.json hook wiring, analyze against the wiring checklist below
5. Return a structured report of findings
## Hook Script Checklist
For each .sh file:
**Fast-exit gating:**
- Does it exit early when the tool input is irrelevant? (e.g., non-Python file for a Python-only check)
- Does it avoid expensive operations (git, grep, make) before confirming relevance?
- Are marker/warned checks done BEFORE filesystem scans or subprocess calls?
- Does it use session markers with TTL to avoid repeating warnings?
**Correctness:**
- Does `set -euo pipefail` behave correctly? (unmatched grep with pipefail can cause unexpected exits — should use `|| true`)
- Does it read tool_input correctly via jq? (Edit uses `file_path` + `old_string` + `new_string`; Write uses `file_path` + `content`)
- Are exit codes correct? (0 = allow, 2 = block for PreToolUse; 0 = ok for PostToolUse)
- Does it handle missing/empty jq fields gracefully?
**Efficiency:**
- Are there redundant subprocess calls? (multiple git invocations that could be combined)
- Are there filesystem operations that run unconditionally but could be gated?
- Could marker files be checked before mkdir -p?
- Are there grep/find calls that scan large directory trees unnecessarily?
**Robustness:**
- Does it work when CLAUDE_PROJECT_DIR is unset? (fallback to pwd)
- Does it handle filenames with spaces?
- Does it work on both macOS and Linux? (md5 vs md5sum, find syntax)
- Are /tmp marker directories cleaned up or TTL-gated?
## Settings.json Wiring Checklist
**Matcher coverage:**
- Are all relevant tools covered? (e.g., if a check applies to both Edit and Write, is it on both matchers?)
- Are there matchers that should exist but don't?
- Are there hooks on matchers where they'll never trigger? (wasted registration)
**Hook ordering:**
- Are fast/cheap hooks listed before slow/expensive ones in each matcher's array?
- For Stop hooks: are agent hooks gated by a marker or fast check before doing LLM work?
- Is the cleanup command hook last in the Stop array?
**Consistency:**
- Do all PreToolUse blocking hooks use exit 2?
- Do all PostToolUse tracking hooks use exit 0?
- Are timeout values reasonable? (tracking: 5s, checks: 10-15s, tests: 120s)
- Do all hooks that should have statusMessage have one?
**Gaps:**
- Are there tools or workflows not covered by any hook?
- Are there hooks that overlap or duplicate each other's checks?
- Could any PreToolUse hooks be replaced by cheaper PostToolUse tracking + Stop review?
## Report Format
Group findings by severity:
### Critical (broken or blocking incorrectly)
- [hook:line] description
### High (wasted execution or missing gate)
- [hook:line] description and recommended fix
### Medium (improvement opportunity)
- [hook:line] description
### Low (style/micro-optimization)
- [hook:line] description
### Summary
- Total hooks: X scripts, Y settings entries
- Gating score: X/Y hooks have proper fast-exit paths
- Portability: any macOS-only concerns
- Recommended next actions (top 3)
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 7d ago First seen · 101 lines · 8 tokens per session scan A fdf420e9df31
hf.audit-hooks is a skill published in the GitHub repository T-rav/hydraflow (5 stars, last pushed 2d ago), licensed Apache-2.0. It adds 8 tokens to every session and 899 once invoked, about $0.0000 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
check
Confirm a change before merge. /check verify drives the real app to prove behavior against the spec (every acceptance criterion met, every surface built). /check review runs a senior code review on a fresh model, one that did not write the code. Verify after /develop, review before a PR. Writes to docs/reviews/, never…
holdout-validation
Cross-reference agent self-review claims against actual file state using hidden holdout scenarios, producing mapped P1/P2/P3 findings that reference visible acceptance criteria only. Use when verifying implementation completeness after self-review in start (Phase 4 VERIFY), address (convergence check), or review…
team-coordination
Coordinate agent teams for adversarial review (paired skeptic/verifier per facet, challenge round with disposition vocabulary, consolidated findings with confidence) or parallel implementation (task sizing 5-6 per teammate, non-overlapping files). Enforces independent analysis before shared conclusions. Reference only…
code-review-methodology
Conduct two-stage code review: Stage 1 verifies spec compliance (criterion-to-code mapping), Stage 2 evaluates security, correctness, performance, and maintainability across 6 parallel facets with P1/P2/P3 synthesis and deduplication by file:line. Use when reviewing code changes or pull requests. This skill MUST be…
feedback-resolution
Address PR review feedback through surgical fixes traceable to specific comments, apply the Boy Scout Rule only to already-modified files (separate improve: commits), recover context by code snippet rather than line number, and enforce pushback only when factually incorrect, test-breaking, or CLAUDE.md-violating. Use…
code-quality-principles
Enforce code quality through the Boy Scout Rule (leave code better than found), secret-free commits, production-ready code (no TODOs, console.log, mocks, or commented code), and self-review against an atomic-commits checklist. Use when writing, modifying, or reviewing code. This skill MUST be consulted because…