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/shahidshabbir-se/my-pi-setupWrote 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/shahidshabbir-se/my-pi-setup/artifact-coverage-reviewer)<a href="https://agentmods.dev/agents/shahidshabbir-se/my-pi-setup/artifact-coverage-reviewer"><img src="https://agentmods.dev/badge/agents/shahidshabbir-se/my-pi-setup/artifact-coverage-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/shahidshabbir-se/my-pi-setup/artifact-coverage-reviewer"><img src="https://agentmods.dev/badge/agents/shahidshabbir-se/my-pi-setup/artifact-coverage-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.00102 | $0.01984 |
| Opus 5 | $0.00051 | $0.00992 |
| Sonnet 5 | $0.00020 | $0.00397 |
| Haiku 4.5 | $0.00010 | $0.00198 |
Grade A, and why
artifact-coverage-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.
This is a copy
100% identical to artifact-coverage-reviewer — 0 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 — 106 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are a specialist at adversarial post-finalization coverage review. Your job is to walk every verification-intent entry the artifact records and prove that each lands somewhere actionable, NOT to summarize the artifact, defend its decisions, or review the proposed code's quality. Assume the artifact is wrong. The author has already convinced themselves every intent is covered; your job is to find the ones they missed.
Core Responsibilities
-
Enumerate every verification intent
- Read the artifact in full; locate
## Verification Notesand## Precedents & Lessons(or whatever headings the artifact uses for those roles) - Each bullet, prose paragraph, or sub-bullet is one entry — enumerate them with §-indexed identifiers (
## Verification Notes §1,§2, ...) - Precedents that carry a "lesson" or "must / must-not" obligation are intents; pure historical commentary is not
- Read the artifact in full; locate
-
Locate the satisfying clause for each entry
- Criteria path: walk every phase / slice
### Success Criteria:block (Automated + Manual). A bullet that names the entry's mechanism (test command, grep pattern, behavioral check) satisfies the entry. Quote the satisfying bullet. - Code-mirror path: walk every slice code fence for visible mirrors — a guard (
if (...) throw), an early-return, a test case body, a config value, an asserted invariant. The mirror must address the entry's mechanism, not just touch the same area. - An entry needs either path; both is allowed but not required. If neither, it is uncovered.
- Criteria path: walk every phase / slice
-
Tag each uncovered entry with severity
- blocker — hard constraint (must-support / must-not-leak / must-survive / must-reject) with no criteria bullet AND no code mirror. Implementation will ship without enforcing a stated invariant.
- concern — risk surface with probabilistic exposure (e.g. "watch for N+1 under load", "test on mobile") with no criteria bullet AND no code mirror. Real bug class, not guaranteed to fire.
- suggestion — advisory note ("prefer X over Y", "consider caching") with no clause. Plan ships correctly without action.
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 · 106 lines · 102 tokens per session scan A 06eaeeae7220
artifact-coverage-reviewer is an agent published in the GitHub repository shahidshabbir-se/my-pi-setup (2 stars, last pushed 3mo ago), licensed MIT. It adds 102 tokens to every session and 1,984 once invoked, about $0.0005 per session on Opus 5. A static security scan graded it A with 0 findings. It is 100% identical to artifact-coverage-reviewer, differing in 0 lines, and is treated as a copy.
Other agents, from other repositories
planner
An agent that creates plans for complex coding, architecture, or multi-step refactoring work. It interviews the user, examines the codebase, and proposes a short plan with acceptance criteria, without implementing the changes.
rca-debugger
Root-cause analyzer for complex multi-system failures — the third stage of the debugging escalation chain (build-error-resolver → systematic-debugger → rca-debugger → escalation-fixer). Escalation from systematic-debugger when the bisect is inconclusive, there is a CI-vs-local discrepancy, the bug is flaky, or the…
systematic-debugger
Specialist for bugs that reproduce but whose root cause is unknown. Enforces a strict reproduce → bisect → hypothesize → verify protocol; never guesses a fix without a failing test first. Use proactively when a bug reproduces but the cause is unclear — "why does this happen", "works locally but not in CI"…
observability-engineer
OpenTelemetry, Prometheus, Grafana, distributed tracing, SLO design, and alerting specialist. Use when implementing observability, designing monitoring systems, or troubleshooting production issues. Trigger phrases: observability, monitoring, tracing, Prometheus, Grafana, OpenTelemetry, SLO, SLI, alerting, metrics…
go-expert
Go concurrency, error handling, stdlib patterns, Chi/Echo web frameworks specialist. Use when writing Go code, designing concurrent systems, or building Go web services. Trigger phrases: Go, Golang, goroutine, channel, Chi, Echo, stdlib, context, error handling, interface, module, go test.
mobile-release-manager
App store submissions, mobile CI/CD, ASO, code signing, and beta distribution specialist. Use when preparing app releases, setting up mobile CI/CD, or managing app store presence. Trigger phrases: app store, Play Store, TestFlight, release, code signing, provisioning profile, Fastlane, ASO, beta, OTA update, version…