Borrowing it
Nothing to install: this file belongs to kamwoh/yume. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.
curl -O https://raw.githubusercontent.com/kamwoh/yume/master/.claude/skills/yume-visual-tester/SKILL.mdgit clone --depth 1 https://github.com/kamwoh/yumeWrote 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/kamwoh/yume/yume-visual-tester)<a href="https://agentmods.dev/skills/kamwoh/yume/yume-visual-tester"><img src="https://agentmods.dev/badge/skills/kamwoh/yume/yume-visual-tester/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/kamwoh/yume/yume-visual-tester"><img src="https://agentmods.dev/badge/skills/kamwoh/yume/yume-visual-tester.svg" alt="Reviewed on agentmods" width="80" 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.00119 | $0.02600 |
| Opus 5 | $0.00060 | $0.01300 |
| Sonnet 5 | $0.00024 | $0.00520 |
| Haiku 4.5 | $0.00012 | $0.00260 |
Grade A, and why
yume-visual-tester 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 12d 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.
How it starts
The opening of the file, as written. The whole thing — 271 lines — stays where its author put it; the contents beside it link to each section on GitHub.
/yume-visual-tester
You are the visual tester for Yume. You walk a built game's
JSON content + the assertion + priors libraries, and emit a
concrete visual_test_plan.json that the ADR 0056 runner can
execute. Distinct from yume-visual-designer — that one is the
art director (subjective rubric); you are the unit-test author
(objective binary assertions).
This skill loads into the orchestrator's main context (Tier 2.6 — no subagent spawn).
Per docs/guideline/00_what_yume_is.md, the visual-QA layer is content, not
engine. Test plans are JSON. They are generated from world
inspection and shipped as artifacts the runner consumes.
Why this skill exists
Hand-authoring visual_test_plan.json per game is busywork that
scales badly. A 10-entity game needs ~6 tests; a 300-entity game
needs ~15 tests but you don't want to write them by hand each
iteration. Most tests are derivable from:
- World priors — common-sense rules ("trees > characters",
"structures rest on ground", "animated rigs have foot-pivot").
These live in
data/lib/visual_qa/priors.jsonand apply to any game whose entities match the priors' triggers. - Game entities —
levels/<level>/entities.jsonhas the concrete instances to test. The skill walks these and matches them against priors. - Recent changes —
git diff HEAD~Nreveals which entities were just modified. Tests targeting these get prioritized at the head of the plan. - GDD aesthetic targets —
docs/games/<game>/GDD.mdsays "Fellowship aesthetic" → emitdistinct_silhouettestests for named-NPC pairs.
The skill composes these inputs into a visual_test_plan.json
that the runner can execute without any further authoring.
Inputs
- game: e.g.
demo_aldenmere - level: e.g.
level_proto_village(defaults to the game's starting level fromflow.jsonif omitted) - Optional: diff_base (default
HEAD~1) — git ref to compute recent changes against - Optional: max_tests (default 12) — soft cap; the skill prioritizes high-priority priors + recently-changed entities, then fills with medium/low until cap reached
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.
- 12d ago First seen · 271 lines · 119 tokens per session scan A ffd9ab3b2433
yume-visual-tester is a skill published in the GitHub repository kamwoh/yume (21 stars, last pushed 2mo ago), licensed MIT. It adds 119 tokens to every session and 2,600 once invoked, about $0.0006 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-30.
Other skills, from other repositories
smoke-check
Run the critical path smoke test gate before QA hand-off. Executes the automated test suite, verifies core functionality, and produces a PASS/FAIL report. Run after a sprint's stories are implemented and before manual QA begins. A failed smoke check means the build is not ready for QA.
hearth-playtest
Let the engine hunt bugs for you — bot playtesting via hearth sweep. Seeded bot policies (mash/idle/wander/seek) play a scene headlessly across many seeds and report softlocks, crashes, stuck states, and unmet objectives as a compact evidence report; objectives double as executable acceptance criteria; a failing seed…
godot-testing-qa
Domain skill — Run a sequence of runtime actions and assertions. Assert runtime node existence and properties. Assert visible runtime text. Compare two PNGs using bounded pixel sampling. Sample runtime performance for a bounded frame count. Return the latest runtime test report.
qa-plan
Generate a QA test plan for a sprint or feature. Reads GDDs and story files, classifies stories by test type (Logic/Integration/Visual/UI), and produces a structured test plan covering automated tests required, manual test cases, smoke test scope, and playtest sign-off requirements. Run before sprint begins or when…
automated-smoke-test
Run an automated smoke test using the godot-mcp server. Launches the project, captures debug output, and checks for errors or crashes.
cgs-architecture-review
Use for architecture review tasks that review architecture for layer violations, scalability risks, engine misuse, testing seams, and production readiness; produce verification evidence, changed or proposed files, and handoff boundaries.