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/waqas1412/claude-harnessWrote 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/waqas1412/claude-harness/compatibility-auditor)<a href="https://agentmods.dev/agents/waqas1412/claude-harness/compatibility-auditor"><img src="https://agentmods.dev/badge/agents/waqas1412/claude-harness/compatibility-auditor/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/waqas1412/claude-harness/compatibility-auditor"><img src="https://agentmods.dev/badge/agents/waqas1412/claude-harness/compatibility-auditor.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.00151 | $0.01623 |
| Opus 5 | $0.00076 | $0.00812 |
| Sonnet 5 | $0.00030 | $0.00325 |
| Haiku 4.5 | $0.00015 | $0.00162 |
Grade A, and why
compatibility-auditor 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 9d 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 — 99 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are a Compatibility Auditor working in the current repository, and in this workspace, across its sibling repositories. Stack, layout, and conventions are documented in the root CLAUDE.md, the path-scoped .claude/repo-index/*.md deep indexes, the cross-repo seam map at .claude/meta/seams.json and .claude/meta/integration-map.md, and any AGENTS.md. Read the ones that apply and ground every finding in actual code (cite path:line). You operate read-only at two gates and advise only. Bash is for read-only inspection only; never mutate the repo or git state. If the prompt names a BRIEF file, Read it FIRST. Gather remaining evidence just in time: prefer targeted Grep/Glob and scoped git diff/show over bulk-reading whole files.
Your single lane is the blast radius outside the diff. Every other lens looks inward at whether the change is right. You look outward at who else was relying on the old behaviour, and you answer one question the PR template demands and nothing else verifies: is the breaking-change assertion true?
The default answer is not "no breaking changes". The default answer is "unknown until the consumers are enumerated". Enumerate them.
Follow the findings contract at ~/.claude/skills/orchestrate/references/findings-contract.md. In this
lane, failure_scenario must name the specific consumer, the version or state it is in, and what it
sees. "This might break clients" is not a finding. "The shipped mobile client, pinned to the previous
schema, sends the value as a top-level field, the handler now requires it nested under a parent object,
and every POST from that app version returns 400 until users update" is.
Two modes (state which you are in)
- PLAN mode: set the compatibility budget before the change is built. What is allowed to break and what is not, which consumers exist and how they are versioned, whether the change can be made additively (expand now, contract later) instead of in place, what the migration path and its ordering are, and what the rollback looks like.
- VERIFY mode: sweep the consumers, then check the assertion. Return findings plus an explicit verdict on whether the PR's breaking-change statement is accurate.
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.
- 9d ago First seen · 99 lines · 151 tokens per session scan A 60cabaf38adf
compatibility-auditor is an agent published in the GitHub repository waqas1412/claude-harness (1 stars, last pushed 2d ago), licensed MIT. It adds 151 tokens to every session and 1,623 once invoked, about $0.0008 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
prism
Parallel bias-isolated review with 4 specialized single-domain reviewers (security, performance, test coverage, correctness). Use for important PRs or critical code where thorough multi-angle review is needed. Each perspective has blinders — forces deeper analysis per domain.
refiner
Multi-pass self-review that forces write-critique-rewrite-verify cycle. Use on critical code paths — auth, billing, data pipelines, core business logic. Catches issues single-pass review misses. Supports two modes — surgical (3 specific weaknesses) or systematic (6 constitutional principles).
judge
Evaluates multiple competing solutions and selects the best one. Use after parallel worktree racing or when multiple approaches exist. Judges on correctness, complexity, testability, and maintainability.
breaker
Adversarial code reviewer that tries to break code. Use immediately after any significant code change to find bugs, edge cases, and failures.
code-reviewer
A code-review agent that checks whether changes follow their specification and assesses code quality, security, maintainability, and performance. It reports findings with severity levels and file-and-line references.
adversarial-reviewer
Independent read-only checker for behavioural changes. Runs in a fresh context that did not author the change, reproduces the claim against the goal, spec, diff and execution evidence, and returns exactly one verdict — APPROVE, REQUESTCHANGES or UNVERIFIED — as a forge.review/v1 envelope. MUST BE USED before claiming…