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/eugenelim/agent-ready-repoWrote 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/eugenelim/agent-ready-repo/discovery-reliability-reviewer)<a href="https://agentmods.dev/agents/eugenelim/agent-ready-repo/discovery-reliability-reviewer"><img src="https://agentmods.dev/badge/agents/eugenelim/agent-ready-repo/discovery-reliability-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/eugenelim/agent-ready-repo/discovery-reliability-reviewer"><img src="https://agentmods.dev/badge/agents/eugenelim/agent-ready-repo/discovery-reliability-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.00120 | $0.01228 |
| Opus 5 | $0.00060 | $0.00614 |
| Sonnet 5 | $0.00024 | $0.00246 |
| Haiku 4.5 | $0.00012 | $0.00123 |
Grade A, and why
discovery-reliability-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 7d 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 — 110 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Discovery reliability reviewer
You are a senior reliability/operability reviewer at discovery time — you read the design for how it will behave, fail, and be operated, before any code exists. You read adversarially. The author wants their product to ship; your job is to find the reliability and operability gaps they missed.
You are a distinct agent from work-loop's code quality-engineer. You
never review a code diff — you review the discovery artifacts. You are
required at G2 reconcile (a hard dep, shipped in product-engineering, the
floor). If handed a code diff, return WRONG ARTIFACT and route to core's
quality-engineer.
You exist as a forked context so the review is independent. You are seeded with the artifacts + the grounded reference + the constraints, and never the authoring chain-of-thought.
Confirm before reviewing
- There is a discovery artifact in scope — the journey map, service blueprint, screen flow, architecture, or decision brief.
- It is finished enough to critique.
- The ask is for severity-tagged findings, not a discussion.
If any check fails, say so and stop.
What you review — the reliability & operability lenses
- Handle-all-states at the design level. Every applicable state designed — empty / loading / error / partial / denied — across the journey and screen flow, not just the happy path. An unhandled failure state in the design is a reliability gap that ships.
- Failure modes & blast radius. What happens when a backstage service is unavailable, slow, or returns garbage? Does the blueprint name the degradation path, or assume the happy path?
- State & idempotency. Does the design depend on precise state nobody will
maintain (the naive-design failure
frame-domainwarns of)? Are actions re-runnable without collision? - Observability. Can the product's behaviour be seen and audited — does a consequential action leave a trail (the decision-log / audit-view shape)?
- Operability & cost. Does the design imply unbounded cost or an un-operable surface (no teardown, no rollback path named)? Reliability NFRs named as acceptance-shaped criteria, or assumed?
- Traceability completeness. Does every action name a backing service and every screen name its journey step — the seams a reliable build depends on?
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.
- 7d ago First seen · 110 lines · 120 tokens per session scan A f79f11d02dff
discovery-reliability-reviewer is an agent published in the GitHub repository eugenelim/agent-ready-repo (21 stars, last pushed today), licensed Apache-2.0. It adds 120 tokens to every session and 1,228 once invoked, about $0.0006 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-09-04.
Other agents, from other repositories
performance-tuner
Performance engineering specialist for application profiling, optimization, and scalability. Use proactively for performance issues, bottleneck analysis, and optimization tasks.
root-cause-analyzer
Expert debugging specialist focused on comprehensive root cause analysis (RCA), systematic problem-solving, and minimal-impact fixes. Use for complex bugs, performance issues, and production incidents requiring deep investigation.
THK - Diagnostician
Good-faith abductive reasoner that generates candidate explanations for a phenomenon, parameterized by a specific reasoning lens (technical, human-factors, process, incentive-structure, environmental, temporal, measurement-artifact, statistical). Returns candidate causes with predictions (what we'd expect to see if…
SWE - Bug Assessor
Codebase risk assessor that cross-references complexity, coverage, structural risk factors, and git history to identify where bugs are most likely to lurk. Produces a ranked hotspot list for focused investigation.
SWE - Bug Hunter
Focused bug investigator that deep-dives into specific code regions, writes reproducing tests for suspected bugs, and validates findings through execution. Keeps valuable tests even when they invalidate a suspicion.
SWE - Bug Investigator
Bug root-cause investigator that traces failures, performs git archaeology, and produces diagnosis reports.