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 Kerliula/ship-me --skill verify-megit clone --depth 1 https://github.com/Kerliula/ship-meWrote 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/kerliula/ship-me/verify-me)<a href="https://agentmods.dev/skills/kerliula/ship-me/verify-me"><img src="https://agentmods.dev/badge/skills/kerliula/ship-me/verify-me.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.00174 | $0.02976 |
| Opus 5 | $0.00087 | $0.01488 |
| Sonnet 5 | $0.00035 | $0.00595 |
| Haiku 4.5 | $0.00017 | $0.00298 |
Grade A, and why
verify-me 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 8d 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.
then hits the real running app with curl — golden path, edge cases, and How it starts
The opening of the file, as written. The whole thing — 319 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Verify Me — Prove It Actually Works
Your job is to find out whether the built feature really does what the problem and solution said it should — by using it, the way a real user or an outside API caller would. You are not reading the code to judge it. You are poking the running app and writing down what happens.
You do not write unit tests, feature tests, or any other code. You do not fix bugs. You observe, compare against what was promised, and report — cleanly.
Input
You need three things:
- The problem write-up (from
/grill-me, e.g.docs/grilling/<topic>.md). - The solution write-up (from
/solve-me, e.g.docs/solutions/<topic>.md). - What was actually built (from
/build-me— recent commits, changed files, or just ask the developer what to verify).
If any of these are missing, ask for them or the file paths. Don't guess at what "correct" means — pull it from the problem's rules and edge cases and the solution's chosen options.
Confirm with the developer before touching anything
Even when all three inputs are handed to you, stop once, ask, and wait before running the first request. Keep it to one short round — propose your own answers so they can just say "yes":
- What am I verifying? — the list of R-numbers / behaviors you intend to hit, and anything you're deliberately skipping.
- Where do I run it? — which base URL / environment, and is the server already running or should you start it.
- Is this database safe to write dummy data to? — say exactly what rows you'd create and how they'll be recognisable.
- Anything I need to log in as? — which user/role, and how to authenticate.
If the developer doesn't answer, don't proceed on assumptions — verification against the wrong environment or the wrong account is worse than no verification.
If the prompt that launched you already carries the developer's
answers to all four questions (e.g. /ship-me collected them before
spawning), don't re-ask — restate them in one line ("Verifying R1–R4
on , dummy rows tagged , as — starting") and
proceed. Stop and ask only if any of the four is missing or unclear.
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.
- 8d ago First seen · 319 lines · 174 tokens per session scan A 38b2e22cffd0
verify-me is a skill published in the GitHub repository Kerliula/ship-me (1 stars, last pushed 10d ago), licensed MIT. It adds 174 tokens to every session and 2,976 once invoked, about $0.0009 per session on Opus 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-08-31.
Other skills, from other repositories
agent-browser
Automates browser interactions for web testing, form filling, screenshots, and data extraction. Use when the user needs to navigate websites, interact with web pages, fill forms, take screenshots, test web applications, or extract information from web pages.
playwright-cli
Automates browser interactions for testing and validating your own web applications using playwright-cli. Use when you need terminal-first browser control for navigation, form filling, screenshots, tracing, bound browser sessions, debugging, or generating Playwright test code. Only use against applications you own or…
webapp-testing
Toolkit for interacting with and testing local web applications using Playwright. Supports verifying frontend functionality, debugging UI behavior, capturing browser screenshots, and viewing browser logs.
devlab-web-visual-ops
A browser-based operations guide for web applications, including single-page apps, micro-frontends, and multi-page sites. It covers observing, navigating, interacting, inspecting, validating, and capturing pages with browser automation and visual fallbacks.
e2e-playwright
Use when writing end-to-end browser tests with Playwright. Covers resilient locators, auto-waiting, network interception, authentication reuse, parallelization, and eliminating flakiness.
web-app-testing
Use when testing a web application interactively — verifying a feature, reproducing a bug, or checking a flow in a real browser. Covers systematic exploration, console and network inspection, and reporting what you find.