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 DDS-Solutions/AI-TadPole-OS --skill verify-changesgit clone --depth 1 https://github.com/DDS-Solutions/AI-TadPole-OSWrote 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/dds-solutions/ai-tadpole-os/verify-changes)<a href="https://agentmods.dev/skills/dds-solutions/ai-tadpole-os/verify-changes"><img src="https://agentmods.dev/badge/skills/dds-solutions/ai-tadpole-os/verify-changes.svg" alt="Measured on agentmods" 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.00038 | $0.01021 |
| Opus 5 | $0.00019 | $0.00511 |
| Sonnet 5 | $0.00008 | $0.00204 |
| Haiku 4.5 | $0.00004 | $0.00102 |
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 4d 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 http://localhost:3000/api/endpoint This is a copy
88% identical to verify-changes — 12 lines differ, which has more behind it and is treated as the original. This page carries a canonical link to it rather than competing with it.
How it starts
The opening of the file, as written. The whole thing — 135 lines — stays where its author put it; the contents beside it link to each section on GitHub.
[!IMPORTANT] AI Context & Knowledge Heritage
- Subsystem: Agent Skills Registry / verify-changes
- Architecture:
@docs ARCHITECTURE:Documentation- Failure Path: Information drift, legacy terminology, or documentation mismatch.
- Observability: Traceability via
execution/parity_guard.py([SKILL])
Verify Changes — Prove Code Works
"Code that exists" ≠ "Code that works." This skill ensures changes are verified through execution.
Core Principle
❌ Verification by inspection: "I can see the function exists, it should work"
❌ Verification by assumption: "The types check out, so it's correct"
✅ Verification by execution: "I ran it, here's the output, it works because [evidence]"
Verification Protocol
Step 1: Identify What Changed
- Which files were modified?
- What behavior should be different now?
- What was the original bug/requirement?
Step 2: Determine Verification Method
| Change Type | Verification Method |
|---|---|
| Bug fix | Reproduce the original bug scenario → confirm it no longer occurs |
| New feature | Run the feature → confirm expected output |
| Refactor | Run existing tests → confirm nothing broke |
| API change | Call the endpoint → confirm response shape |
| UI change | Render the component → confirm visual output |
| Config change | Load the config → confirm values applied |
| Build/infra | Run build command → confirm success |
Step 3: Execute Verification
# For Node.js projects
npm run build # Does it compile?
npm run test # Do tests pass?
npm run dev # Does it start?
# For specific files
node -e "require('./path/to/module'); console.log('✅ Loads correctly')"
# For API endpoints
curl http://localhost:3000/api/endpoint
# For scripts
python script.py --test
Step 4: Report Evidence
## Verification Report
### What was changed
- [File list and summary]
### How it was verified
- [Exact commands run]
### Evidence
- Build: ✅ Compiled without errors
- Tests: ✅ 42/42 passing
- Runtime: ✅ Server starts, endpoint returns expected JSON
- Edge case: ✅ Empty input handled correctly
### Not yet verified
- [Anything that couldn't be tested automatically]
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.
- 4d ago First seen · 135 lines · 38 tokens per session scan A 370a5ebf016d
verify-changes is a skill published in the GitHub repository DDS-Solutions/AI-TadPole-OS (8 stars, last pushed 2d ago), licensed MIT. It adds 38 tokens to every session and 1,021 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 1 finding (makes network calls). It is 88% identical to verify-changes, differing in 12 lines, and is treated as a copy.
Other skills, from other repositories
test-electron-app
Drive the real running PostHog Electron app (live tRPC, workspace-server, real data) over CDP with agent-browser. Connect to the running app on port 9222, test desktop changes against a local Django stack, snapshot the accessibility tree, inspect network requests, and screenshot only when explicitly asked. Use when…
debug-and-test
Use when debugging or validating an Air Jam project so diagnostics, logging, and tests stay intentional, structured, and aligned with the project architecture.
server-side-calls
Call tRPC procedures directly from server code using t.createCallerFactory() and router.createCaller(context) for integration testing, internal server logic, and custom API endpoints. Catch TRPCError and extract HTTP status with getHTTPStatusCodeFromError(). Error handling via onError option.
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.
repro-api
Reproduce an EmDash bug below the browser layer -- REST handlers, CLI, MCP, migrations, schema registry, or build tooling. No browser. Prefer a failing vitest test in the affected package, run in an attached container.
om-troubleshooter
Diagnose and fix standalone Open Mercato bugs across scope, commands, locking, fields, generated registries, UI hydration, cache/search, bootstraps, queues, and providers. Use for "fix bug", "why does this fail", "regression", "debug", "napraw błąd", or a failing test.