Borrowing it
Nothing to install: this file belongs to kamiazya/whiteboard. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.
curl -O https://raw.githubusercontent.com/kamiazya/whiteboard/main/.claude/skills/diagnosis-evidence/SKILL.mdgit clone --depth 1 https://github.com/kamiazya/whiteboardWrote 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/skills/kamiazya/whiteboard/diagnosis-evidence)<a href="https://agentmods.dev/skills/kamiazya/whiteboard/diagnosis-evidence"><img src="https://agentmods.dev/badge/skills/kamiazya/whiteboard/diagnosis-evidence/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/skills/kamiazya/whiteboard/diagnosis-evidence"><img src="https://agentmods.dev/badge/skills/kamiazya/whiteboard/diagnosis-evidence.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector warn
SkillSpector: 2 findings, up to high
These are SkillSpector’s own severities. On a checked sample its high-severity flags on skills were ~96% false positives — a documented command, a public API, a “never do X” rule — so we show them as a caution to read, not a verdict. Why →
- high Tool Misuse · line 111 Tool calls are chained to bypass individual safety checks or escalate capabilities beyond what any single tool call would allow.Fix: Limit tool chaining depth and validate the output of each tool before passing it to the next. Require explicit user approval for multi-step chains.
- high Tool Misuse · line 124 Tool calls are chained to bypass individual safety checks or escalate capabilities beyond what any single tool call would allow.Fix: Limit tool chaining depth and validate the output of each tool before passing it to the next. Require explicit user approval for multi-step chains.
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.00057 | $0.02080 |
| Opus 5 | $0.00028 | $0.01040 |
| Sonnet 5 | $0.00011 | $0.00416 |
| Haiku 4.5 | $0.00006 | $0.00208 |
Grade A, and why
diagnosis-evidence 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 — 180 lines — stays where its author put it; the contents beside it link to each section on GitHub.
A diagnosis is only as good as the proof that you measured what you think
measured-change is about instrumenting a CHANGE whose effect you cannot see.
This is about the step before: a FAILURE you are explaining, or a fix you are
calling verified. Both fail the same way — a number arrives, it looks like
evidence, and nothing in it says what was actually exercised.
Every rule below cost a wrong public conclusion in one session.
Pick an observation that could REFUTE the claim
The rule the others are instances of. Three wrong conclusions in one session shared this shape: the observation taken was CONSISTENT with the claim and could not have contradicted it, so it read as confirmation while testing nothing.
- A mutant reported
failed 1 testand was read as killed. The failing test was a flake, in a file the mutated line cannot reach; three full runs of the mutated build all passed. One failure is equally consistent with killed and with a flake — only WHICH test failed tells them apart. - A survivor at
elements[0]?.attrs?.[name]was hand-checked by mutating both optional chains. It went red, and the reported mutant was only one of them. Mutating more than what was reported can only produce red; red then says nothing about the reported mutant. okSecondwas called unreachable after measuring thatzeroBendFacingFirstnever returns two pairs. True, and about a different question: the two pushes are mutually exclusive, so a single pair can arrive from either. Measured on the branch that actually answers the claim, 242 of 7893 firings came from the non-dominant one.
So before running the observation, name the outcome that would make you say the claim is WRONG. If no outcome of this observation would, you are about to confirm rather than test — take the discriminator instead: the failing test's NAME rather than the count, the reported mutant's exact line and columns rather than the expression around it, the branch the claim is about rather than the one beside it.
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 Changed · +28 lines 0cac7d0a47c6
- 12d ago First seen · 152 lines · 57 tokens per session scan A 7524441a8ef7
diagnosis-evidence is a skill published in the GitHub repository kamiazya/whiteboard (6 stars, last pushed today), licensed Apache-2.0. It adds 57 tokens to every session and 2,080 once invoked, about $0.0003 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 skills, from other repositories
systematic-debugging
4-phase root cause debugging: understand bugs before fixing.
langsmith-observability
LLM observability platform for tracing, evaluation, and monitoring. Use when debugging LLM applications, evaluating model outputs against datasets, monitoring production systems, or building systematic testing pipelines for AI applications.
experimental-code-coverage-local-debugger
Runs code coverage locally via Universal Test Runner (UTR) or helper scripts, mimicking LUCI trybots. Activate when CQ tryjobs fail or underreport coverage, to test local GN/recipe repairs before uploading, or to debug hermetic crashes.
adversarial-reviewer
Adversarial code review that assumes bugs exist and hunts for them. Use when asked to review code, find bugs, audit for correctness, stress-test a PR, or when someone says "tear this apart" or "what's wrong with this". Give no benefit of the doubt — every line is guilty until proven innocent.
cli-e2e
Write, modify, or debug Docker-based Composio CLI end-to-end tests under ts/e2e-tests/cli, including binary invocation, fixture isolation, output assertions, and package manifests. Use for CLI E2E test suites only; use cli-command for CLI source implementation.
work
Deliver one maintainer-approved EmDash issue, choosing the bug-fix path for a defect and the direct implementation path for an enhancement or task.