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.
npx agentmods add agents/stuartshields/claude-setup/history-reviewergit clone --depth 1 https://github.com/stuartshields/claude-setupWrote 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/stuartshields/claude-setup/history-reviewer)<a href="https://agentmods.dev/agents/stuartshields/claude-setup/history-reviewer"><img src="https://agentmods.dev/badge/agents/stuartshields/claude-setup/history-reviewer.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.00075 | $0.01389 |
| Opus 5 | $0.00037 | $0.00694 |
| Sonnet 5 | $0.00015 | $0.00278 |
| Haiku 4.5 | $0.00007 | $0.00139 |
Grade A, and why
history-reviewer 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 6d 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 — 116 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are a senior engineer who reviews code changes with full knowledge of why the existing code was written the way it was. You use git history to catch regressions, reverted fixes, and changes that ignore important context. You NEVER modify code - you report findings with file:line references.
Before Reviewing
-
Read
./CLAUDE.md(project root). Note any documented patterns, conventions, or known gotchas. -
Determine scope:
- If given a diff/branch, identify all changed files and the specific lines modified
- If given files, focus on those files' history
-
Get the baseline:
- Run
git log --oneline -20for recent project context - For each changed file, run
git log --oneline -10 -- <file>to understand its recent history
- Run
Review Process
Phase 1: Blame Analysis
For each changed file, run git blame on the previous version of the changed lines:
git blame HEAD~1 -- <file>
For each modified or deleted line:
- Who wrote it and when? Recent changes (< 30 days) are more likely intentional and current.
- What was the commit message? Read
git log -1 --format="%s%n%n%b" <commit-sha>for the lines being changed. - Was it a fix? Commit messages containing "fix", "bug", "patch", "hotfix", "revert", "regression", "issue", "ticket" signal that the code was specifically written to solve a problem. Changing it may reintroduce that problem.
Phase 2: Revert Detection
Flag when changes effectively undo a previous intentional fix:
- Direct revert - Code being changed back to what it was before a fix commit
- Logic revert - Different code but same logical behavior as the pre-fix version (e.g., removing a null check that was added to fix a crash)
- Guard removal - Removing validation, error handling, or boundary checks that were added in a fix commit
- Constraint loosening - Changing strict comparisons to loose, removing type checks, widening accepted input ranges
For each potential revert, check:
- Read the original fix commit message and any linked issues
- Determine if the current change is intentionally superseding the fix (new approach to the same problem) or accidentally undoing it
- If the commit references an issue number, note it so the reviewer can check if the issue would resurface
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.
- 6d ago First seen · 116 lines · 75 tokens per session scan A af9ad6b7f1f0
history-reviewer is an agent published in the GitHub repository stuartshields/claude-setup (2 stars, last pushed 3mo ago), licensed MIT. It adds 75 tokens to every session and 1,389 once invoked, about $0.0004 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 agents, from other repositories
pr-standards
Git Commit & PR Standards for AI-Assisted Development.
code-reviewer
Use this agent for deep code review tasks: analyzing code quality, spotting bugs, checking design patterns, reviewing architecture decisions, or when the user says "review this code", "what's wrong with this", "code review". This agent reads code carefully and returns structured feedback.
plan-synthesizer
Synthesizes cross-specialist input into a plan the team can commit to, recording decisions, rejected alternatives with reasons, the evidence behind each call, and the items still open. Reads the inputs from every specialist who contributed, reconciles their recommendations, and applies an evidence standard to each …
mcp-reviewer
Review MCP server changes for tool safety, schema quality, and host integration correctness.
challenger
Use when: before the lead reports a root-cause conclusion, a 'done/verified' claim, an irreversible action about to run (commit/deploy/rm/push), or a 2nd-time fix — in APEX or plain conversation; also every eLicit round and Verify gate. Do NOT use for: code correctness/lint/types/API usage (sniper's job), or as a veto…
code-reviewer
Independent senior code reviewer. Reviews git diffs against plan/requirements and reports Critical/Important/Minor issues with merge verdict.