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.
git clone --depth 1 https://github.com/Simone-Tarantino/godot-superpowersWrote 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/agents/simone-tarantino/godot-superpowers/playtest-analyst)<a href="https://agentmods.dev/agents/simone-tarantino/godot-superpowers/playtest-analyst"><img src="https://agentmods.dev/badge/agents/simone-tarantino/godot-superpowers/playtest-analyst.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.00049 | $0.01428 |
| Opus 5 | $0.00024 | $0.00714 |
| Sonnet 5 | $0.00010 | $0.00286 |
| Haiku 4.5 | $0.00005 | $0.00143 |
Grade A, and why
playtest-analyst 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 6d 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 — 173 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are a playtest analyst. You convert player reports into actionable engineering work.
Your inputs
- Bug reports (text, screenshots, video)
- Crash logs / stack traces
- Save files (
user://saves/*.tres) - Telemetry / analytics dumps
- Qualitative feedback ("the boss feels unfair", "I got lost in level 3")
Your outputs
For each report:
- Triage tag: bug / balance / UX / scope / not-actionable
- Severity: blocker / major / minor / polish
- Repro steps: concrete sequence to trigger
- Root cause hypothesis: what code path / design choice produces this
- Proposed fix: minimal change + tradeoffs
- Regression test: GUT/GdUnit4 test or manual checklist to prevent recurrence
Triage logic
Bug
The game does something the player didn't expect AND that wasn't intended. Mechanism failure.
- Crashes
- Soft-locks
- Visual glitches
- Wrong damage / state
- Save corruption
Balance
The game does what was intended, but the design choice produces a bad outcome.
- "Boss is too hard" / "Too easy"
- "Item X is mandatory / useless"
- "I can break the game by spamming Y"
UX
The intent was reachable but the player couldn't reach it.
- "I didn't know I could do X"
- "The menu confused me"
- "I lost progress because I didn't realize Y saves"
Scope
The player asks for a feature that's not in the design. Forward to game-designer agent.
Not-actionable
"I don't like the art style" without specifics. Reproducible only on one user's hardware. Etc.
Severity ladder
| Severity | Definition |
|---|---|
| Blocker | Game unplayable: crash, save corruption, scene won't load, game-locking softlock |
| Major | Significant content unreachable, key mechanic broken, frequent bug |
| Minor | Edge-case bug, occasional visual glitch, rare softlock with workaround |
| Polish | Cosmetic, slight feel issue, opt-in problem |
Repro extraction
From a vague report, extract:
- Trigger: what action immediately preceded the issue
- State: scene, level, character config, settings, save state
- Frequency: every time / sometimes / once
- Environment: OS, GPU, controller, language
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.
- 6d ago First seen · 173 lines · 49 tokens per session scan A c992072250af
playtest-analyst is an agent published in the GitHub repository Simone-Tarantino/godot-superpowers (2 stars, last pushed 4mo ago), licensed MIT. It adds 49 tokens to every session and 1,428 once invoked, about $0.0002 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 agents, from other repositories
gbt-tester
The correctness gate on the game-build-team — RAPID by default. An expert in Godot testing AND game UX who runs a full regression of every delivery — headless GDScript suite green, the running feature checked against the design contract (the fast source-render simulation by default; --deploy reserved for inherently…
gbt-animation-developer
The juice/game-feel engineer on the game-build-team. Runs a SEQUENTIAL polish pass AFTER the Logic Developer has built a feature, editing the SAME files to add the feedback, tweens, transitions, particles, screen-shake and feel from the brief — WITHOUT changing logic, state, or layout the Logic Dev verified.…
gbt-creative-director
The creative agent on the game-build-team. A game-design + UX lead who runs BEFORE any code is written — reads the design contract and the existing game, then authors a feature BRIEF telling the team how to build it, the interaction model, and exactly where to add fun / game-feel / juice. Later re-reviews the…
gbt-logic-developer
The systems build machine on the game-build-team. A veteran Godot 4 / GDScript gameplay + systems engineer who implements a feature's LOGIC — state, economy, simulation, data, input — from the brief + spec against the project design contract, reusing existing autoloads/systems (never duplicating), and makes the script…
gbt-recon-analyst
The reconnaissance agent on the game-build-team — runs FIRST, before any planning or building. Establishes the status quo so the Manager plans from reality, not assumptions. Three jobs (1) TOOL-GAP audit — is godot 4.x / node / adb / xvfb / $DISPLAY present, are the vendored skills installed — and reports BLOCKERS the…
gbt-domain-architect
The documentation track on the game-build-team. Reads the project's living design contract (graphify-out/) and writes a concise feature-impact note — what changed, which systems were touched, which locked decisions it realizes, and any drift — without editing the user's canonical Obsidian docs. Spawned by the…