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 phuonghx/aim-cli --skill verify-changesgit clone --depth 1 https://github.com/phuonghx/aim-cliWrote 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/phuonghx/aim-cli/verify-changes)<a href="https://agentmods.dev/skills/phuonghx/aim-cli/verify-changes"><img src="https://agentmods.dev/badge/skills/phuonghx/aim-cli/verify-changes/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/phuonghx/aim-cli/verify-changes"><img src="https://agentmods.dev/badge/skills/phuonghx/aim-cli/verify-changes.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.00092 | $0.00962 |
| Opus 5.5 | $0.00037 | $0.00385 |
| Sonnet 5.5 | $0.00018 | $0.00192 |
| Haiku 4.5 | $0.00009 | $0.00096 |
Grade A, and why
verify-changes scanned grade A with 1 finding 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 1mo 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.
Makes network callslowCapability
Not a fault in itself. Listed so you know the mod talks to something, and to what.
curl -s http://localhost:3000/api/orders | jq . How it starts
The opening of the file, as written. The whole thing — 125 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Verify Changes
Existing code and working code are not the same thing. Reading a function tells you what it looks like; running it tells you what it does. This skill is about closing that gap with evidence you can point to.
The distinction that matters
Inspecting: "the function is right there, so it should work" -> not verified
Assuming: "the types line up, so it must be correct" -> not verified
Executing: "I ran it; here is the output; it works, because X" -> verified
Only the third kind counts. Everything else is a hypothesis.
How to verify
1. Pin down what changed
- Which files did you touch?
- What behavior should now be different?
- What was the original requirement or bug?
2. Match the change to a method
| Kind of change | How you prove it works |
|---|---|
| Bug fix | Re-run the exact scenario that failed; confirm it no longer does |
| New feature | Drive the feature end to end; confirm the output matches intent |
| Refactor | Run the existing tests; confirm nothing regressed |
| API change | Call the endpoint; confirm the response shape and status |
| UI change | Render the component; confirm what appears on screen |
| Config change | Load the app with it; confirm the new values take effect |
| Build / infra | Run the build or pipeline; confirm it completes |
3. Actually run it
# JavaScript / TypeScript project
npm run build # does it compile?
npm test # do the tests pass?
npm run dev # does it boot?
# Smoke-test a single module
node -e "require('./src/parser'); console.log('module loads')"
# Hit an HTTP endpoint
curl -s http://localhost:3000/api/orders | jq .
# Exercise a CLI
python -m mytool --check
4. Write down the evidence
## Verification
Changed
- src/orders/total.ts — corrected rounding on multi-currency carts
Ran
- npm run build, npm test, manual curl against /api/orders
Result
- Build: compiled clean
- Tests: 58 passed, 0 failed
- Runtime: server boots; /api/orders returns the expected JSON
- Edge case: empty cart returns 0, not NaN
Still open
- Load behavior under concurrency not yet measured
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.
- 1mo ago First seen · 125 lines · 92 tokens per session scan A a1647557fe8a
verify-changes is a skill published in the GitHub repository phuonghx/aim-cli (1 stars, last pushed 4mo ago), licensed MIT. It adds 92 tokens to every session and 962 once invoked, about $0.0004 per session on Opus 5.5. A static security scan graded it A with 1 finding (makes network calls). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-09-03.
Other skills, from other repositories
evidence-audit
Evidence-led audit/fix rounds for any codebase in any language. Finds only defects that a runnable proof reproduces on current code, applies the narrowest in-scope patch, verifies with a second proof, promotes high-risk proofs to permanent regression tests, and reports exact validation results. Use whenever the user…
debugging
Use this skill when something is broken and the cause is unknown — a failing test, a crash, an error message, wrong output, a regression, a hang, or behaviour that differs between environments — and it has to be found and fixed at the root. Also use it to build the failing proof for a suspected defect before fixing…
claim-check
Claim checker that audits a coding agent's statements that tests pass or a build is clean against its own session transcripts: whether a matching run happened before the claim, whether it passed, and whether code changed after it. Use when the user asks whether the agent really ran the tests, how often it said tests…
backpropagation
Trace runtime bugs back to spec gaps — identify missing acceptance criteria, update specs, generate regression tests, and detect patterns.
triage-bug
Use when triaging a bug from session evidence (evidence-capture JSONL, replay JSONL, telemetry, repo-audit) instead of from a live user description, and producing a TDD fix plan plus a docs/bugs/{slug}.md triage artifact.
audit-then-fanout-fix
When a class of bug keeps slipping through tests, run a coverage-matrix audit first, then fan out fix agents per gap — don't whack-a-mole individual failures.