agentsclimarketplace

Agent verify

Skill kmloureiro/agent-verify

Token-minimal CLI verification harness for AI coding agents. Build the check with the feature; agents read PASS/FAIL, not DOM dumps. ~20 tokens, not 20,000.

Install
npx -y skills add kmloureiro/agent-verify

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

This skill should be used when building or changing a feature in an app, API, or site and you want to verify it works WITHOUT burning tokens on browser automation, screenshots, or DOM dumps. Use it to generate a token-minimal CLI verification harness alongside each feature, run checks in a sandbox, and surface only PASS/FAIL + the failing line. Triggers on "verify this works", "test this feature", "did the change break anything", "check the endpoint", "add tests", or any agent self-verification loop. Browser/visual checks are the fallback of last resort, only for genuinely visual UI, and only at the end.

SKILL.md

3.7 KB, 766 tokens by cl100k_base, as published. Nobody here has run it

agent-verify

Make the thing you build verifiable by the cheapest mechanism that can falsify it. Verify via CLI by default. The model should read ~20 tokens (PASS / FAIL: line), never a DOM dump or a screenshot.

The one rule

Use the lightest mechanism that can prove a feature wrong. Escalate only when it can't.

in-process assert  →  CLI / curl + exit code  →  DB test (TAP)  →  headless browser (visual only, last)
   cheapest                                                            most expensive

90% of what agents build (logic, data, API contracts, flows) is verifiable with zero browser. Reserve the browser for pixels.

Loop (per feature)

  1. Detect once. Run scripts/detect-stack.sh. It prints the test runner and stack in a few lines. Don't impose a new framework — use what's there.
  2. Build the feature.
  3. Write ONE token-minimal check using the stack's in-process / CLI primitive (see reference/stacks/). The check must print PASS or a single FAIL: line — never dumps.
  4. Append one line to VERIFICATION_MAP.md: feature | command | pass-signal. This is the contract the agent reads next time.
  5. Run scripts/verify.sh [feature] and read only the result. Edit → verify → repeat on the result, not on logs.

What NOT to do

  • Don't reach for Playwright/the browser to check logic, data, or API responses. That's the token leak this skill exists to stop.
  • Don't prescribe a TDD ritual. Surface which check proves this feature, not a procedure. (Procedure without targeted context measurably backfires — see reference/patterns.md.)
  • Don't return raw output to the context. Filter in the sandbox, surface the result. (console.log(result), not the 10k rows.)
  • Don't let checks grow. One feature, one fast deterministic check. Keep VERIFICATION_MAP.md short — short maps outperform long ones.

Output contract (always)

PASS auth-login
FAIL create-invoice: expected 201, got 500

Exit 0 = all pass. Non-zero = something failed. That is all the model needs.

When the browser IS unavoidable

Only for genuinely visual UI (layout, styling, visual regression) and only at the very end. Even then: one headless run, return a PASS/FAIL or a diff verdict — never a full screenshot or DOM into the context. See reference/stacks/nextjs.md.

Files

  • scripts/detect-stack.sh — prints stack + runner, token-minimal.
  • scripts/verify.sh — runs mapped checks, emits only PASS/FAIL + failing line.
  • VERIFICATION_MAP.md — the short feature→command map (the agent maintains it).
  • reference/stacks/ — copy-paste recipes: FastAPI (in-process TestClient), Supabase (seed + reset + pgTAP), Next.js (route handlers + last-resort visual), SvelteKit (load/actions/+server + RLS rolled back, Playwright CLI last).
  • reference/patterns.md — token-minimal verification patterns + the evidence behind them.
  • reference/anti-patterns.md — flaky tests, false PASS, over-engineering guards.
  • templates/ — starting points for the map, a FastAPI test, a Supabase seed.

What ships with it: 20 files

39.2 KB alongside SKILL.md, 4 of them executable

benchmark/

examples/

reference/

scripts/

templates/

Gives 0 of the 12 instructions most quality gates skills give in 766 tokens

Counted across 1,195 of the 2,094 authors here whose files we hold, read 2026-08-07

  • Read the output and check the exit codein 54 of 1195, across 14 files
  • Verify requirements using a line-by-line checklistin 53 of 1195, across 12 files
  • Identify the verification command proving the claimin 51 of 1195, across 12 files
  • Run the full verification commandin 50 of 1195, across 11 files
  • Verify output confirms the claimin 49 of 1195, across 12 files
  • Check version control diff after agent delegationin 46 of 1195, across 6 files
  • State claim with evidencein 44 of 1195, across 4 files
  • Run the test suitein 33 of 1195, across 26 files
  • Keep state in memory by defaultin 27 of 1195, across 6 files
  • Make prototype runnable with one commandin 26 of 1195, across 5 files
  • Produce a verification reportin 25 of 1195, across 14 files
  • Detect the package manager from lockfilesin 24 of 1195, across 5 files

Said here and by no other author read

  • use the lightest mechanism that can prove a feature wrong
  • verify via CLI by default
  • use the existing stack and test runner
  • write one token-minimal check per feature
  • print only PASS or a single FAIL line
  • append one line to VERIFICATION_MAP.md per feature

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 326,984. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.