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.
npx skills add yash-gadodia/claude-init --skill live-verifygit clone --depth 1 https://github.com/yash-gadodia/claude-initWrote 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/yash-gadodia/claude-init/live-verify)<a href="https://agentmods.dev/skills/yash-gadodia/claude-init/live-verify"><img src="https://agentmods.dev/badge/skills/yash-gadodia/claude-init/live-verify/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/yash-gadodia/claude-init/live-verify"><img src="https://agentmods.dev/badge/skills/yash-gadodia/claude-init/live-verify.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.00096 | $0.00785 |
| Opus 5.5 | $0.00038 | $0.00314 |
| Sonnet 5.5 | $0.00019 | $0.00157 |
| Haiku 4.5 | $0.00010 | $0.00078 |
Grade A, and why
live-verify 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 24d 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 — 45 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Live verify
Green gates (types, lint, the suite) prove the code compiles and passes the tests its author wrote. They say nothing about what the author never imagined. A behavior claim is proven only by watching the behavior happen on the real surfaces.
1. Reproduce before you fix
- Capture the exact shape that breaks from the real system: the request body, the database row, the job payload, the API response. The shape, not a description of it.
- Turn it into a fixture next to the test, named for the scenario, and anonymize it while preserving structure: field presence versus absence, nesting, empty versus null. The structure is usually where the bug lives, so a tidied fixture stops reproducing it.
- Run the test and confirm it fails for the same reason the bug happens. A test that fails for a different reason pins nothing.
- Make the minimal fix and watch the test go green.
2. The live pass, run as an attack
- List every path that reaches the behavior: each UI surface that renders it, the API route, the CLI, background jobs and cron, any bot or webhook, and every user role that can reach it. A fix wired into one path and not its sibling is the most common way a "fixed" bug ships again.
- Probe each path on the running app, as the same role and database user production uses. A dev server connected as a superuser bypasses row-level security and passes code that fails in production.
- Attack your own rule: the boundary value and one past it, empty, null, unicode, legacy rows that predate the change, and the mirror image of whatever you guarded against.
- Read the artifact, not the success message: the row in the database, the rendered page (an HTTP 200 is not proof the page rendered), the message actually sent.
- Read the attempt, not only the answer: a job that crashes and succeeds on retry looks like a slow success. Check the logs for the probe's time window, and treat any retry as a failure until explained.
- Every catch becomes a failing test before its fix (section 1). Restore any state the probes changed.
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.
- 24d ago First seen · 45 lines · 96 tokens per session scan A 79aca3ac886c
live-verify is a skill published in the GitHub repository yash-gadodia/claude-init (5 stars, last pushed 25d ago), licensed MIT. It adds 96 tokens to every session and 785 once invoked, about $0.0004 per session on Opus 5.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-26.
Other skills, from other repositories
regression-test-gen
Suggest regression coverage for changed stack behavior.
diagnose
Disciplined diagnosis loop for hard bugs and performance regressions. Reproduce → minimise → hypothesise → instrument → fix → regression-test. Use when user says "diagnose this" / "debug this", reports a bug, says something is broken/throwing/failing, or describes a performance regression.
e2e-testing
Guide for running end-to-end tests of the Qwen Code CLI, including headless mode, MCP server testing, and API traffic inspection. Use this skill whenever you need to verify CLI behavior with real model calls, reproduce user-reported bugs end-to-end, test MCP tool integrations, or inspect raw API request/response…
test-failure-explorer
Import and query an existing Vitest 3.2 JSON report to explore test failures, file-level errors and original diagnostic evidence.
verify-omnigent
Drive Omnigent the way a user does and prove a behavior with recorded evidence, using an isolated server, runner, and mock model plus a feature map of every user entry point. Load before reproducing a user-facing bug, before claiming a fix works, or when reviewing whether a change covered every surface (session vs.…
verify
Exercise the real app/API/CLI and collect observable evidence; tests alone do not count as end-to-end verification.