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/code-simplifier)<a href="https://agentmods.dev/agents/mickeyyaya/evolve-loop/code-simplifier"><img src="https://agentmods.dev/badge/agents/mickeyyaya/evolve-loop/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/code-simplifier"><img src="https://agentmods.dev/badge/agents/mickeyyaya/evolve-loop/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.00049 | $0.00695 |
| Opus 5.5 | $0.00020 | $0.00278 |
| Sonnet 5.5 | $0.00010 | $0.00139 |
| Haiku 4.5 | $0.00005 | $0.00069 |
Grade A, and why
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 1mo 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.
This is a copy
97% identical to code-simplifier — 75 lines differ, which has more behind it and is treated as the original. This page carries a canonical link to it rather than competing with it.
How it starts
The opening of the file, as written. The whole thing — 54 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 should 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 is ≤ 300 lines; otherwise read the parts the dispatch prompt names. - To see around a hunk, use
Readwithoffset/limit(±40 lines). 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 prompt; you are here for shape, not correctness. After edits, compile-check ONCE withgo build ./<changed package>/(or the language's equivalent). - Budget: ≤ 12 tool calls, ≤ 30K tokens. If the diff exceeds ~400 lines, take the largest hunks first and say which you skipped.
- Never run git stash/checkout/reset/add/commit, or anything that mutates git state. Edit 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 the diff added
- duplicated logic the diff introduced (two copies of one rule → one)
- nesting the diff introduced that an early return would flatten; nested ternaries the diff added; a single-use helper the diff added that hides one line
- a name that misleads about what the changed code does; a comment that overstates or contradicts it
- a new helper re-implementing stdlib or an existing in-package helper (confirm with ONE grep)
What NOT to do
- no behavior change, ever — if a rewrite could 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.
- 1mo ago Changed · +6 lines · +17 tokens per session 28c6942331cb
- 1mo ago First seen · 48 lines · 32 tokens per session scan A 24003adf826f
code-simplifier is an agent published in the GitHub repository mickeyyaya/evolve-loop (6 stars, last pushed 2d ago), licensed Apache-2.0. It adds 49 tokens to every session and 695 once invoked, about $0.0002 per session on Opus 5.5. A static security scan graded it A with 0 findings. It is 97% identical to code-simplifier, differing in 75 lines, and is treated as a copy.
Other agents, from other repositories
quality-fixer
Specialized agent for verifying software projects and fixing quality failures within the current task scope. Use proactively after code changes or for quality, test, build, lint, format, correctness, or fix requests.
investigator
Comprehensively collects problem-related information and creates evidence matrix. Use PROACTIVELY when bug/error/issue/defect/not working/strange behavior is reported. Reports observations and evidence for downstream cause verification.
solver
Derives multiple solutions for verified causes and analyzes tradeoffs. Use when root cause verification has concluded, or when "solution/how to fix/fix method/remedy" is mentioned. Focuses on solutions from given conclusions without investigation.
verifier
Critically evaluates investigation results, checks path coverage, and validates failure points using Devil's Advocate method. Use when investigation has completed, or when "verify/validate/double-check/confirm findings" is mentioned. Focuses on verification and conclusion derivation.
architect
Maps component boundaries, data flow, interfaces, and dependency graph.
behavior-auditor
Logic correctness, error handling, async safety, and CQ3-CQ10 checks on changed production files.