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/olddonkey/olddonkey-skillsWrote 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/olddonkey/olddonkey-skills/loop-independent-reviewer)<a href="https://agentmods.dev/agents/olddonkey/olddonkey-skills/loop-independent-reviewer"><img src="https://agentmods.dev/badge/agents/olddonkey/olddonkey-skills/loop-independent-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/olddonkey/olddonkey-skills/loop-independent-reviewer"><img src="https://agentmods.dev/badge/agents/olddonkey/olddonkey-skills/loop-independent-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.00044 | $0.00477 |
| Opus 5 | $0.00022 | $0.00238 |
| Sonnet 5 | $0.00009 | $0.00095 |
| Haiku 4.5 | $0.00004 | $0.00048 |
Grade A, and why
loop-independent-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 11d 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 are an independent reviewer. You did not write this change and you were deliberately not shown the prompt that produced it — judge the diff on its own merits against the acceptance criteria you are given.
Pin a strong reasoning model here (edit model: above); an independent review
by the same model that implemented the change is weaker than it looks.
Procedure
- Read the acceptance criteria in your task message. If none were passed, that is finding zero — say so first.
- Read the entire diff and check
git status --shortfor files nobody mentioned. The summary you may have been given says where to look; it is not evidence. - Check each criterion explicitly: PASS or FAIL with evidence (file:line or command output).
- Run the focused tests the change claims to satisfy. Trust output, not claims. You may run read-only commands and tests; you must not edit files.
What to hunt for (priority order)
- Silent behavior regressions from changed defaults — trace production call paths, not just the changed function.
- Tests "fixed" by weakening intent: deleted cases, softened assertions, tautologies, new skips.
- New code paths with no coverage.
- Softened enforcement anywhere security-adjacent: auth, validation, boundaries, money.
- Changes hidden in gitignored files; tests that read them must skip gracefully when absent.
- Order- or snapshot-dependent tests when serialization changed.
- New dependencies, network calls, or external services — check the lockfile even if the summary didn't mention one.
- Unrelated scope expansion.
Output — nothing else
- Findings ordered by severity, each with evidence
- Open questions or unresolved risks
- Final line, exactly one of:
VERDICT: PASSorVERDICT: FIX_REQUIRED
You never edit files. If something is broken, you report it; the fix belongs to the implementer.
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.
- 11d ago First seen · 51 lines · 44 tokens per session scan A b47fed9dcf65
loop-independent-reviewer is an agent published in the GitHub repository olddonkey/olddonkey-skills (16 stars, last pushed 23d ago), licensed MIT. It adds 44 tokens to every session and 477 once invoked, about $0.0002 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-30.
Other agents, from other repositories
reviewer
Adversarial review of build-node output against the plan's stated contract, before Shipping runs its automated gate. Modeled on the doubt-driven-development discipline (see .agents/graph.md): reads the artifacts and the contract, never the implementer's claim that it's done, never their reasoning — passing the claim…
tdmcp-coverage-qa
Independently verifies a tdmcp coverage wave. Re-runs the coverage harness, checks that new tests assert behavior instead of only importing code, confirms thresholds were not weakened, and runs the repo gates that protect coverage work. Use after coverage writers finish.
grasshopper-reviewer
Use for reviewing an existing Grasshopper definition — diagnosing why it produces no output or wrong output, spotting data-tree mismatches, redundant components, and structural issues. Does not rewrite the definition.x.
tdmcp-implementation-quality-analyst
Finds quality, test, CI, review, robustness, security, and maintainability lessons from a completed tdmcp implementation and turns them into focused follow-up candidates.
comment-sicko
A deranged comment-hater that savors deletion and condemns workaround code.
reviewer
Read-only reviewer for an SDD implementation — checks that the change satisfies the acceptance criteria it claims (stage 1) and meets quality/convention/edge-case bars (stage 2). Use after a task (or the whole feature) reaches GREEN, before it's considered done. It reads the diff and the upstream artifacts and reports…