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/hecer/yoke/visual-verificationnpx skills add HECer/yoke --skill visual-verificationgit clone --depth 1 https://github.com/HECer/yokeWhat 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.00092 | $0.00579 |
| Opus 5 | $0.00046 | $0.00290 |
| Sonnet 5 | $0.00018 | $0.00116 |
| Haiku 4.5 | $0.00009 | $0.00058 |
Grade A, and why
visual-verification 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 2d 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.
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.
What it actually says
Visual verification
Unit tests don't see a blank page, an unwired route, a runtime console error, or AI-slop design.
Make the loop's gate catch them by widening verify, since the loop trusts verify as truth.
1. Compose the verify pipeline
Set verify.command (in .yoke/config.yaml) to chain, fail-fast:
<typecheck> && <unit tests> && yoke design-scan . && yoke flow-smoke .
e.g. tsc --noEmit && vitest run && yoke design-scan . && yoke flow-smoke .. Any red step blocks the story.
2. Flow-smoke with the built-in gate
Configure the key user flows once in .yoke/config.yaml:
smoke:
baseUrl: http://localhost:3000
flows:
- name: home
path: /
landmark: "main h1"
- name: login
path: /login
landmark: "form"
With that in place, the yoke flow-smoke . step from the section-1 pipeline is live.
yoke flow-smoke loads each route against the running dev server, waits for the landmark,
fails on any console error, and always saves a screenshot to .yoke/proof/<story>/
(the loop labels the folder with the current story id via YOKE_STORY; standalone runs use
latest, or pass --label=). Requires Playwright in the project:
npm i -D playwright && npx playwright install chromium. Start the dev server before verify
(e.g. via start-server-and-test).
3. Video only when necessary
yoke flow-smoke records video per flow and keeps it only on failure
(.yoke/proof/<story>/<flow>.webm). When a flow goes red: watch that clip first, then use the
wired Playwright MCP to reproduce interactively. Never record every run manually — the gate
already handles the failure case.
Rule
Green pipeline = types + units + no design-slop over budget + every flow renders without console errors, with a screenshot to prove it. Only then is the story actually done.
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.
- 2d ago First seen · 55 lines · 92 tokens per session scan A 23f05b894856
visual-verification is a skill published in the GitHub repository HECer/yoke (2 stars, last pushed 12d ago), licensed MIT. It adds 92 tokens to every session and 579 once invoked, about $0.0005 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
testing-mcp-with-cli-agents
Test an MCP server by driving real CLI agents (Claude, Codex, Cursor, Gemini, Grok, agy, opencode) against it, using isolated tmux sockets and send-keys instead of trusting unit tests alone. Use this whenever verifying MCP-server behavior end-to-end, checking that a local branch or checkout works across installed…
add-new-agent-support
Add a new agent (tool) support to agent-command-sync following the registry pattern.
with-config
A Codex skill with openai.yaml configuration.
standard-skill
A standard test skill for Gemini.
test-skill
A test skill for chimera.
basic-skill
A basic test skill for Claude.