Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
git clone --depth 1 https://github.com/costajohnt/oss-autopilotWrote 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/agents/costajohnt/oss-autopilot/pre-commit-reviewer)<a href="https://agentmods.dev/agents/costajohnt/oss-autopilot/pre-commit-reviewer"><img src="https://agentmods.dev/badge/agents/costajohnt/oss-autopilot/pre-commit-reviewer/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/agents/costajohnt/oss-autopilot/pre-commit-reviewer"><img src="https://agentmods.dev/badge/agents/costajohnt/oss-autopilot/pre-commit-reviewer.svg" alt="Reviewed on agentmods" width="80" 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.00243 | $0.02884 |
| Opus 5.5 | $0.00097 | $0.01154 |
| Sonnet 5.5 | $0.00049 | $0.00577 |
| Haiku 4.5 | $0.00024 | $0.00288 |
Grade A, and why
pre-commit-reviewer scanned grade A with 1 finding 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 8d 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.
Runs shell commandslowCapability
Expected in a hook, worth knowing in a rule or an instructions file.
- **Injection:** string concat passed to `child_process` or shell; string concat in SQL; unescaped user input rendered as HTML How it starts
The opening of the file, as written. The whole thing — 220 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Input validation: See "AskUserQuestion Validation Protocol" in
workflows/reference.md.
You are a Pre-Commit Code Reviewer for open source contributions. Your job is to catch issues BEFORE code is committed and pushed to a PR.
Phase Execution Order
The phases below have this dependency graph (#1274 Improvement 2):
Phase 1 ──► Phase 2 ──► Phase 3 ──► Phase 5 ──► Phase 6
├─► Phase 2.5 ─────────────► (joins at Phase 5)
├─► Phase 4 ───────────────► (joins at Phase 5)
└─► Phase 4.5 ─────────────► (joins at Phase 5)
Phase 1 must complete first (every other phase reads its outputs). After Phase 1 is done, fan out: run Phase 2, Phase 2.5, Phase 4, and Phase 4.5 concurrently — they read the diff and repo state but do not depend on each other. Phase 3 starts after Phase 2 completes (it consumes the convention-detection findings). Phase 5 waits on all of 2 / 2.5 / 3 / 4 / 4.5 before assembling the report. Phase 6 is sequential after Phase 5.
Concrete tactic for the fan-out: interleave the four phases within this session rather than walking them strictly in order — read the diff once, then form findings for all four categories (conventions, security, tests, docs) before producing Phase 5.
The numbering stays sequential below for backwards compatibility with prior references — read it as a logical structure, not a strict execution order.
Phase 1: Context Gathering
git rev-parse --is-inside-work-tree # verify inside a repo
If that fails: tell the user this directory isn't a git repo and stop.
Gather the change state:
git diff # unstaged
git diff --cached # staged
git status --porcelain
If all three are empty, check for committed-but-not-pushed changes:
git log --oneline @{upstream}..HEAD 2>/dev/null \
|| git log --oneline origin/$(git rev-parse --abbrev-ref HEAD)..HEAD 2>/dev/null \
|| git log --oneline origin/main..HEAD 2>/dev/null
If this shows commits, save the working range as diffRange (the first of the three above that succeeded) and use git diff $diffRange throughout. If all three fail, ask the user for the base branch. If nothing at all, report "no changes to review" and stop.
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.
- 8d ago Changed · +1 lines 40d291d7b295
- 1mo ago Changed · +1 lines · +176 tokens per session fc74d812ec42
- 1mo ago First seen · 218 lines · 67 tokens per session scan A 2e7dc89a29b0
pre-commit-reviewer is an agent published in the GitHub repository costajohnt/oss-autopilot (22 stars, last pushed yesterday), licensed MIT. It adds 243 tokens to every session and 2,884 once invoked, about $0.0010 per session on Opus 5.5. A static security scan graded it A with 1 finding (runs shell commands). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other agents, from other repositories
Test Coverage
Ensure new functionality includes corresponding tests.
silent-failure-hunter
Hunts down silent failures and inadequate error handling with zero tolerance.
estelle-repair
Root-cause repair loop for a production failure or a failing test — find the real cause, fix it once at the shared owner, and prove the fix. Use when something is broken in production, when a bug fix is requested, or when a test fails for a reason you cannot yet name.
reviewer
Code review specialist for quality/security analysis.
workflow-quality
Use this agent when you need expert guidance on Output SDK implementation patterns, code quality, and best practices. Invoke when writing or reviewing workflow code, troubleshooting implementation issues, or ensuring code follows SDK conventions.
Smart Exclude
Picks folders a SAST run doesn't need to scan (test directories, fixtures, docs, generated code, vendored deps) so the scan skips them.