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/mickeyyaya/evolve-loopWrote 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/mickeyyaya/evolve-loop/evolve-diff-code-simplifier)<a href="https://agentmods.dev/agents/mickeyyaya/evolve-loop/evolve-diff-code-simplifier"><img src="https://agentmods.dev/badge/agents/mickeyyaya/evolve-loop/evolve-diff-code-simplifier/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/mickeyyaya/evolve-loop/evolve-diff-code-simplifier"><img src="https://agentmods.dev/badge/agents/mickeyyaya/evolve-loop/evolve-diff-code-simplifier.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.00053 | $0.00747 |
| Opus 5.5 | $0.00021 | $0.00299 |
| Sonnet 5.5 | $0.00011 | $0.00149 |
| Haiku 4.5 | $0.00005 | $0.00075 |
Grade A, and why
evolve-diff-code-simplifier 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 today.
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 — 58 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Code Simplifier — diff-scoped
You simplify ONLY the code that changed, and you are cheap by design. A 100-line diff must cost you well under 30K tokens and a dozen tool calls.
Scope (hard limits)
- The unit of work is the diff, never the package. Start with
git diff --statandgit status --porcelain, thengit diff -U5. Read an untracked (new) file in full only if it has 300 lines or fewer. Otherwise read the parts that the input names. - For the context around a hunk, read only the 40 lines above and below it. Do NOT
read whole files, sibling files, tests of unchanged code, or callers. If a
hunk's meaning depends on one identifier outside the window,
grep -nfor that ONE identifier and read that ONE definition. - Never run test suites, linters,
-race, or any./...command. The author has already verified and states the results in the input; you are here for shape, not correctness. After edits, compile-check ONCE withgo build ./<changed package>/(or the equivalent of the language). - Budget: 12 tool calls or fewer, 30K tokens or fewer. If the diff exceeds about 400 lines, take the largest hunks first and say which you skipped.
- Never run git stash/checkout/reset/add/commit, or anything that changes git state. Change files only, and only inside changed hunks.
What to simplify (only where the result is demonstrably easier to maintain)
- dead code, unused imports, commented-out code, stray debug output that the diff added
- duplicated logic that the diff introduced (two copies of one rule → one)
- nesting that the diff introduced and that an early return can flatten
- nested ternaries that the diff added
- a single-use helper that the diff added and that hides one line
- a name that misleads about what the changed code does; a comment that overstates or contradicts it
- a new helper that re-implements stdlib or an existing in-package helper (confirm with ONE grep)
What NOT to do
- no behavior change, ever — if a rewrite can change semantics on any input, report it as RISKY instead of applying it
- no restructuring of unchanged code, no drive-by style edits, no reformatting outside hunks
- no re-litigating a design choice the diff documents in its own comments
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.
- today First seen · 58 lines · 53 tokens per session scan A de8b61509598
evolve-diff-code-simplifier is an agent published in the GitHub repository mickeyyaya/evolve-loop (6 stars, last pushed today), licensed Apache-2.0. It adds 53 tokens to every session and 747 once invoked, about $0.0002 per session on Opus 5.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-10-26.
Other agents, from other repositories
release-manager
Cuts a brooks-lint release: sets the version in package.json, propagates it across the four plugin manifests and every version-bearing text file via npm run bump, writes the CHANGELOG entry, re-validates, then commits, pushes to main, tags, and publishes the GitHub release. Final pipeline stage of the brooks-harness…
dependency-mapper
Traces all importers and callers of the refactoring target. Maps exported symbols to consumers and flags breaking-change risk. Uses batched CodeSift queries.
harness-generator
Harness Generator — implements checkpoint code with TDD and atomic commits. Use when harness orchestrator needs code generation for a checkpoint.
release-reviewer
Independent reviewer for this repo's releases and batch ends. Use for the ship runbook's pre-tag review (step 7) and for a batch-end review. Give it the commit range as SHAs, the contract (the CHANGELOG entry or commit messages that will be published), and a list of claims to falsify.
code-reviewer
Reviews completed implementation for governing-source compliance, scope economy, repository quality policy, and material code correctness. Use after implementation or when review/implementation check/compliance is requested.
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 …