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 agentmods add skills/subhansh-dev/agent-maxxing/runtime-verifynpx skills add subhansh-dev/agent-maxxing --skill runtime-verifygit clone --depth 1 https://github.com/subhansh-dev/agent-maxxingWhat 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 | $0.00027 | $0.00883 |
| Opus 5 | $0.00014 | $0.00441 |
| Sonnet 5 | $0.00005 | $0.00177 |
| Haiku 4.5 | $0.00003 | $0.00088 |
Grade A, and why
runtime-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 yesterday.
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 — 96 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Runtime Verify — Run It, Don't Test It
Extracted from Claude Code's bundled verify skill.
Verification is runtime observation. Build the app, run it, drive it to where the changed code executes, and capture what you see. That capture is your evidence. Nothing else is.
Don't run tests. Don't typecheck. Running them proves you can run CI — not that the change works.
Don't import-and-call. import { foo } from './src/...' then console.log(foo(x)) is a unit test you wrote. The app never ran. Go to the real interface.
Find the change
Establish the full range of what changed:
git log --oneline @{u}.. # count commits
git diff @{u}.. --stat # full range
git diff origin/HEAD... --stat # no upstream
git diff HEAD --stat # uncommitted
The diff is ground truth. Any description is a claim about it. Read both. If they disagree, that's a finding.
Surface
The surface is where a user meets the change. That's where you observe.
| Change reaches | Surface | You |
|---|---|---|
| CLI / TUI | terminal | type the command, capture the output |
| Server / API | socket | send the request, capture the response |
| GUI | pixels | drive it, screenshot |
| Library | package boundary | sample code through the public export |
| Prompt / agent config | the agent | run the agent, capture its behavior |
Internal function? Not a surface. Something in the repo calls it and that caller ends at one of the rows above. Follow it there.
Drive it
Smallest path that makes the changed code execute:
- Changed a flag? Run with it.
- Changed a handler? Hit that route.
- Changed error handling? Trigger the error.
- Changed an internal function? Find the CLI command / request / render that reaches it.
The verdict is table stakes. Your observations are the signal. A PASS with three sharp "hey, I noticed..." lines is worth more than a bare PASS.
End-to-end, through the real interface. Pieces passing in isolation doesn't mean the flow works. If users click buttons, test by clicking buttons.
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.
- yesterday First seen · 96 lines · 27 tokens per session scan A be9f274f1799
runtime-verify is a skill published in the GitHub repository subhansh-dev/agent-maxxing (2 stars, last pushed 1mo ago), licensed MIT. It adds 27 tokens to every session and 883 once invoked, about $0.0001 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
feishu
Work with Feishu or Lark bots, docs, sheets, bitables, approval flows, and OpenAPI/MCP setup without hardcoding credentials.
interview
Ask one useful structured question at a time only when material product/implementation choices are genuinely missing; remember answers and produce a brief/spec. Discoverable facts should be investigated instead of asked.
writing
将共享历史中的已验证事实和计算结果整理成符合受众、格式与长度约束的成稿。.
test
Detect the project’s test stack, run the narrowest useful tests, create tests when authorized, and report coverage/gaps honestly.
verify
Exercise the real app/API/CLI and collect observable evidence; tests alone do not count as end-to-end verification.
build-teaql-app
Build or change a TeaQL application in Java, Rust, Go, Swift, Python, C#/.NET, or TypeScript, including Kotlin/JVM applications that consume Java-generated libraries. Mandatory order: first draft and save a complete KSML model, then verify the client and evaluate that saved model, repair it through repeated evaluation…