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 Bulugulu/game-qa --skill requesting-game-qagit clone --depth 1 https://github.com/Bulugulu/game-qaWrote 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/bulugulu/game-qa/requesting-game-qa)<a href="https://agentmods.dev/skills/bulugulu/game-qa/requesting-game-qa"><img src="https://agentmods.dev/badge/skills/bulugulu/game-qa/requesting-game-qa/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/bulugulu/game-qa/requesting-game-qa"><img src="https://agentmods.dev/badge/skills/bulugulu/game-qa/requesting-game-qa.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.00093 | $0.01109 |
| Opus 5 | $0.00046 | $0.00554 |
| Sonnet 5 | $0.00019 | $0.00222 |
| Haiku 4.5 | $0.00009 | $0.00111 |
Grade A, and why
requesting-game-qa 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 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.
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 — 85 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Requesting Game QA
You are the feature owner. You built the feature; now you're the PM driving it through verification. This skill is for browser-game features only — not tools, not build scripts, not generic code review.
Core principle: You own the feature's quality bar. QA executes; you set scope, sign off the plan, and unblock as findings stream.
The Iron Law
GAME FEATURES ONLY.
NO BRIEF, NO QA. NO SIGN-OFF, NO EXECUTION.
WATCH TICKETS LIVE — DON'T WAIT FOR THE VERDICT.
What Will Happen
You don't run QA yourself — your context is full of feature code. You spawn sub-agents to do the work, while you stay in your own context to fix what they find.
- Write the brief. One file, every field filled.
- Spawn enumerator sub-agent with the brief → it invokes
enumerating-game-test-cases, writestest-cases.json, terminates. Short interaction. - Sign off the plan. Read
test-cases.json. Edit / cull / question. Confirm it matches what you actually built and care about. - Spawn QA Lead sub-agent with the signed-off plan → it invokes
game-qa. The Lead validates adapter coverage, then spawns its own engineers and reviewers in parallel, rolls up tickets, returns one verdict. - Watch
<artifactDir>/tickets/continuously during step 4. Fix bugs as they land —capability-gaptickets first (they block QA), then bugs at your own pace. - Lead returns
verdict.json. You read it, decide ship / no-ship.
Two spawns from you. Inside the Lead's spawn, more sub-agents work — but you never see them. You see only the brief, the plan (for sign-off), tickets (streamed), and the final verdict.
What to Produce (this skill)
<artifactDir>/brief.md:
feature: <slug>
spec: <design-doc path + section anchor>
goals: <one paragraph — what player promise this ships, in your own words>
scope:
in: [<player promise>, <player promise>, ...]
out: [<deferred>, <covered by unit tests>, ...]
unitCoverage:
- <path>: <count> asserts (what unit tests already cover — don't re-test)
arrangePrimitivesNeeded: [<your best guess at adapter actions QA will need>]
severity: blocking-for-merge | nice-to-have | quick-spotcheck
artifactDir: qa-runs/<date>_<feature>/
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 · 85 lines · 0 tokens per session scan A 1fdb6f9e8545
requesting-game-qa is a skill published in the GitHub repository Bulugulu/game-qa (1 stars, last pushed 3mo ago), licensed MIT. It adds 93 tokens to every session and 1,109 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
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…
game-playtesting
Test a game end to end like a player across boot, controls, gameplay loops, UI, save state, failure recovery, rendering, audio, performance, and platform behavior. Use after game implementation or for regression investigation.
gm-evaluate
Evaluate the current tag's quality: enforce the playable-closed-loop gate, maintain a single cross-tag e2e/ suite that always reflects the current game (add tests for new mechanics, prune tests for mechanics this tag deliberately removed), and reason about gameplay quality. Independent from the build process — fresh…
godot-e2e
Write and run E2E (end-to-end) game tests using the godot-e2e framework. Python controls a live Godot game over TCP — Locator-based semantic queries, expect() auto-retry assertions, and engine log capture make failures self-diagnosing. Use this skill whenever you need to: Test actual gameplay: player movement…
screenshot
Capture gameplay screenshots using godot-e2e for visual verification. Use when you need to: take a screenshot of the running game, capture multiple screenshots during an E2E scenario, generate reference.png, visually verify game state, or provide screenshots for VQA analysis. Triggers: "screenshot", "capture…