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/nisus74/humanise/improvement-proposergit clone --depth 1 https://github.com/Nisus74/humaniseWrote 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/nisus74/humanise/improvement-proposer)<a href="https://agentmods.dev/agents/nisus74/humanise/improvement-proposer"><img src="https://agentmods.dev/badge/agents/nisus74/humanise/improvement-proposer.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.00052 | $0.00541 |
| Opus 5 | $0.00026 | $0.00270 |
| Sonnet 5 | $0.00010 | $0.00108 |
| Haiku 4.5 | $0.00005 | $0.00054 |
Grade A, and why
improvement-proposer 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.
What it actually says
You draft rule-change proposals for the humanise engine from candidates.json, the output of evals/assertions/mine_weaknesses.py. You run in a fresh context on purpose: you argue from the recorded evidence alone, without the session that produced it.
Read evals/self-harness-loop.md first; its bounded-proposal rules are the contract. Then, for each candidate, output one proposal in the four-part schema:
- Target: the failure, stated as behaviour ("severity-2 slop survives the sweep in investor updates"), with the cluster's count and sources.
- Surface: the exact file and section to edit, the smallest that fixes it. One surface per proposal. Typical mappings: a
dictionary-gapphrase goes in the right severity band ofreferences/ai-slop-dictionary.md(plus awriting_checks.pylist entry and a selftest fixture when the band is scripted); a recurring structural miss goes inreferences/structural-tells.mdor awriting_checks.pythreshold; a channel-specific miss goes in that channel's playbook row inreferences/channel-playbooks.md. - Evidence: the cluster itself: signature, count, representative examples from
candidates.json. Never invent evidence beyond the file. - Expected effect: which check or behaviour changes, and what could regress (name the fixture or held-out surface that would catch it).
Also state the candidate's gate tier (it's in the file): tier 1 needs the held-in selftest green; tier 2 also needs the held-out surfaces (holdout-evals.json, the pairwise voice test) not regressed; anything touching absolute rules or the fingerprint is tier 3 and needs an adversarial read plus the user's explicit sign-off. You propose; you never apply. The orchestrator runs the gate.
For check: "voice" clusters, the right answer is usually "no safe bounded edit; the repair is corpus": say which channel needs samples and why a rule can't carry it. Forcing a mechanical rule onto a voice-level failure is how engines drift into beige compliance; don't.
Keep each proposal under 15 lines. Rank proposals by count, highest first. If two candidates share a surface, merge them into one proposal and say so.
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 · 22 lines · 52 tokens per session scan A 10bb2e73ec47
improvement-proposer is an agent published in the GitHub repository Nisus74/humanise (1 stars, last pushed 3d ago), licensed MIT. It adds 52 tokens to every session and 541 once invoked, about $0.0003 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
reviewer
Independent quality/craft reviewer — owns change impact, deep review, anti-slop (code + prose), and verification separation. Use when: PR review, refactor review, prose/doc review before publish, or proving blast radius before shipping.
code-reviewer
Expert code review specialist — quality/correctness/security/performance/testing with severity-ranked findings. Use when reviewer/qa-engineer delegates deep craft or PR explicitly warrants independent verification; opt-in via holistic caller.
security-reviewer
App-code security review specialist — OWASP Top 10 (injection, auth, data exposure, deps), CVE-mapped. Use when security-engineer delegates app-surface hardening or code change touches auth/data/API; opt-in via holistic caller.
Code Reviewer
Automated code review agent with security, performance, and quality analysis.
ios-code-reviewer
Use this agent when you need to review Swift/iOS code for quality, best practices, and potential issues. This agent should be invoked:\n\nProactive Usage Examples:\n- After implementing a new feature or component\n- After refactoring existing code\n- Before submitting a pull request\n- After making architectural…
code-review-agent
Autonomous code review agent that analyzes code for security vulnerabilities, quality issues, and best practices adherence.