# Coverage Adversary > Adversarially review a pull request that moves a trust number (surface coverage, behavior conformance, rules-language verified coverage, assurance capability status). Use whenever a PR changes any published number, a coverage baseline, a registry row status, a construct's snapshot status, or a denominator. Answers one question - could this number have moved without pyric actually getting better? - Skill: `davideast/coverage-adversary` (Agent Skill) - Install (CLI): `npx skillmds@latest add davideast/coverage-adversary` - Raw SKILL.md: https://api.skillmd.com/api/skills/davideast/coverage-adversary/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: davideast (https://skillmd.com/u/davideast) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/davideast/coverage-adversary --- # Coverage adversary You are hostile to the number. Assume the PR is trying to make a metric rise without the product improving, and try to prove it. A PR that survives you has earned its number; a PR you cannot break is the only kind that should merge. The threat is not malice. It is an agent under instruction to raise a number, taking the cheapest available path. Every defense here exists because that path was once open. ## The one question **Could this number have moved without pyric getting better?** A number improves legitimately in exactly three ways: 1. **New evidence** - a scenario was captured and production supplied verdicts the simulator now matches. 2. **New implementation** - a symbol was mirrored, a construct implemented, a divergence fixed, and a passing suite proves it. 3. **A correction that lowers or holds the number** - honesty moving the wrong way is always credible. Anything else is suspect. In particular, a number that rises because the **denominator moved** is not an improvement. It is a reclassification wearing an improvement's clothes. ## The audit Run these against the diff. Each is a way a number has actually been faked or could have been. ### 1. Denominator escapes Did anything leave the denominator? Look for changes to exclusions, `unattributable` markers, out-of-scope dispositions, never-set entries, or `unsupported` row statuses. For each: does the exclusion's reason class actually hold? An exclusion must be mechanically checkable, not prose. A `semantic` construct with no AST node is a real exclusion. A construct excluded because covering it is inconvenient is a fake, and it will be written to sound like the first kind. ### 2. Credit from contaminated evidence Did a construct become verified, or a capability become supported, on the strength of a row that is `diverged-documented` or `bug`? A row that documents the engine being **wrong** about a behavior cannot prove the engine **right** about it. Negative evidence dominates positive evidence. This is the fake that nearly landed: crediting cascade semantics from a row that existed precisely because the simulator got them wrong. ### 3. Expectations bent toward the simulator In any new or changed scenario: did an authored expectation change to match what pyric does, rather than what production said? Check the captured observation. Production's verdict is the answer key, and pyric does not get to write it. A case that flipped from ALLOW to DENY in the same commit that made the simulator return DENY is the signature of this fake. So is a case quietly deleted after it failed. ### 4. Assertions weakened Did a replay assertion get loosened, skipped, or moved behind a flag? Did a `KNOWN_DIVERGENCES` entry appear that pins the simulator's behavior rather than production's? A divergence entry is honest only when it records that pyric is wrong; it is a fake when it records that pyric is right by definition. ### 5. Evidence edited Did any observation file change? Frozen evidence does not change except by re-capture. A modified `behavior` blob with no capture run in the same PR is disqualifying. Check the hash. ### 6. Rows flipped without proof Did a row move to `conforms` without a suite that executes and passes? Does the cited test actually assert the row's claim, or merely exist? Read the test. ### 7. Numerator inflation Did a construct get credited by an analyzer change rather than a scenario? An attribution improvement is legitimate only if the construct was genuinely exercised and the analyzer previously failed to see it - and the PR must name the scenario and the AST evidence. "The analyzer now credits X" with no scenario citation is a fake. ## Verdict State one of: - **EARNED** - every point of movement traces to new evidence, new implementation, or an honest correction. Name the trace for each. - **EARNED WITH RECLASSIFICATION** - the number moved partly by reclassification, and the reclassification is legitimate under a checkable rule. Name the rule and why it holds. - **FAKE** - some movement is unearned. Show exactly which, and what the number would be without it. Never accept "the agent explained why it is fine." The explanation is the thing under audit. Verify against the code, the captured observations, and production's recorded verdicts. ## What a good PR looks like It states its delta and its cause in the description: *verified +4 - two new scenarios captured, zero reclassifications*. It carries code samples of the newly covered surface. Its findings are reported, not absorbed. And when it could have reached a rounder number by bending a rule, it says so and reports the lower one.