CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

game-playtest

Run browser-game playtests and frontend QA. Use when the user asks for smoke tests, screenshot-based verification, browser automation, HUD or overlay review, or structured issue-finding in a browser game.

64

Quality

80%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./plugins/game-studio/skills/game-playtest/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

71%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

A lean, well-organized QA-checklist skill that assumes Claude's competence and wastes no tokens, with a clear sequenced workflow and a concrete reporting standard. Its weaknesses are the total absence of executable specifics (no commands or examples for boot, automation, or screenshot capture) and a References section whose four target paths do not exist in the bundle.

Suggestions

Add one minimal executable example for the core loop (e.g., a Playwright snippet or command pattern for launching the game and capturing a screenshot of the first actionable screen) so the 'Tooling Guidance' section has copy-paste-ready anchor points.

Fix the References section: either move the playtest checklist and WebGL debugging notes into the skill's own references/ directory so the paths resolve, or drop the dangling cross-skill paths that cannot be verified from the bundle.

Add a short failure-handling branch to the workflow (what to do when the game fails to boot, or when automation is impossible mid-session) so the sequence closes its validation gap.

DimensionReasoningScore

Conciseness

The body is lean checklist-style guidance with no re-teaching of concepts Claude already knows — every bullet ('sprite alignment and baseline consistency', 'WebGL context loss or renderer fallback behavior') is task-specific signal. Not 4 because there is no padding or over-explanation anywhere to trim.

5 / 5

Actionability

The workflow and reporting standard are concrete in direction, and tools are named ('Prefer Playwright or equivalent', 'use SpectorJS'), but there is not a single executable command, code snippet, or example invocation — how to boot the game or capture screenshots is left entirely implicit. Not 4 because anchor 4 expects concrete code/commands with only minor gaps; this has none.

3 / 5

Workflow Clarity

'Boot the game and confirm the first actionable screen' through 'Report findings in severity order with reproduction steps' is a clear, ordered sequence with an early checkpoint. Not 5 because there is no feedback loop or guidance for what to do when a step fails (e.g., game fails to boot); not 3 because the sequence is well-defined with explicit output format.

4 / 5

Progressive Disclosure

Sections are well-organized and inline content is appropriately placed, but the References section points entirely outside the bundle ('../web-game-foundations/SKILL.md', '../../references/playtest-checklist.md') and none of those files exist in the skill's bundle, so navigation is unverifiable/dangling. Not 4 because dangling references are more than a minor organization gap; not 2 because the body itself is properly structured and references are clearly labeled, not buried.

3 / 5

Total

15

/

20

Passed

Description

78%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

A strong description with an explicit what and a well-built 'Use when' clause full of natural trigger terms, clearly scoped to browser games. Its only real gaps are a thin action list in the what-statement and generic QA terms that create minor overlap risk with general web-QA skills.

DimensionReasoningScore

Specificity

The what-clause is 'Run browser-game playtests and frontend QA' — domain named with roughly two concrete actions, while the fuller capability list (HUD/overlay review, screenshot verification) lives only in the when-clause. Not 4 because the action list in the what-statement itself is minimal compared to the multi-action anchor examples.

3 / 5

Completeness

It explicitly answers both what ('Run browser-game playtests and frontend QA') and when ('Use when the user asks for smoke tests, screenshot-based verification...'), matching the anchor-5 pattern of concrete trigger phrases attached to an explicit Use-when clause. Not 4 because the when-clause is already specific and trigger-phrase-driven, not merely serviceable.

5 / 5

Trigger Term Quality

Natural phrases users would say are present: 'smoke tests', 'screenshot-based verification', 'browser automation', 'HUD or overlay review', 'structured issue-finding'. Not 5 because common synonyms like 'visual regression', 'cross-browser', or 'playtesting' as a request phrasing are absent.

4 / 5

Distinctiveness Conflict Risk

The 'browser game' scope carves a clear niche with game-specific triggers (HUD, overlay, playfield), but generic terms like 'frontend QA', 'smoke tests', and 'browser automation' overlap general web-QA skills. Not 5 due to that overlap risk with closely related frontend/browser skills; not 3 because the game framing dominates the trigger set.

4 / 5

Total

16

/

20

Passed

Validation

100%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository

openai/plugins

Path

plugins/game-studio/skills/game-playtest/SKILL.md

Reviewed

Table of Contents

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.