threejs-qa-release

Verify and release Three.js browser games: playtest QA, automated bot playtests, mobile and responsive checks, production builds, static-hosting base paths, debug gating, bundle review, screenshots, visual regression baselines, canvas-pixel inspection with measured metrics, and release risk reports.

Quality

80%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Passed

No findings from the security scan

Quality

Content

86%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 tight, well-structured overview: lean prose, a reference table with explicit read-when triggers, executable inspector tooling, and a sequenced QA/release workflow with concrete validation criteria. The only meaningful gap is that error-recovery loops are implied rather than explicit, and the QA steps are behavioral rather than command-driven.

Dimension	Reasoning	Score
Conciseness	The body is lean and dense — every line is instruction or evidence criteria with zero concept explanations, e.g. 'Screenshots alone do not cover gameplay changes' and 'passing pixels and acknowledged state hooks do not establish aesthetic quality'. It fully assumes Claude's competence; every token earns its place.	5 / 5
Actionability	The canvas-inspector section gives a copy-paste-ready command with real flags ('node <this-skill-dir>/scripts/inspect-threejs-canvas.mjs --manifest artifacts/evidence.json --url http://127.0.0.1:5188 --seed 42') plus flag semantics, but the 10-step QA pass is behavioral direction ('Exercise the main input, objective progression...') rather than executable steps. Not 5 because the common-case flow is not uniformly copy-paste ready; not 3 because the key tooling is fully executable.	4 / 5
Workflow Clarity	The QA pass is a clearly numbered 10-step sequence with validation checkpoints (capture console/page/network errors, 'Confirm non-blank, visually varied canvas pixels', 'blank-canvas or error conditions exit non-zero') and scoping/repetition rules. Not 5 because an explicit fix-and-re-run feedback loop is only implicit ('Repeat only after relevant changes, failures, or unresolved concerns') rather than a step-by-step validate→fix→retry pattern.	4 / 5
Progressive Disclosure	A well-signaled 'Read it when' reference table points to three real one-level-deep files (references/release-checks.md, visual-test-harness.md, playtest-bot.md — all present in the bundle), the executable tooling lives in scripts/inspect-threejs-canvas.mjs, and the body stays a concise overview. This matches the clear-overview anchor exactly.	5 / 5
	Total	18 / 20 Passed

Description

75%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 specific, comprehensive, third-person description of what the skill does with a well-defined niche. Its main weakness is the complete absence of a 'Use when...' trigger clause, which caps completeness at 3 and leaves triggering to keyword inference alone.

Suggestions

Append an explicit trigger clause, e.g. 'Use when the user asks to test, QA, verify, or release a Three.js or browser game, or mentions playtests, production builds, or shipping a game.'

Add a few natural synonyms users would say, such as 'deploy', 'ship', 'regression testing', and 'cross-browser/mobile testing', to broaden trigger-term coverage.

Consider naming the primary artifacts users mention ('bot playtest metrics', 'release risk report') as trigger phrases so requests for those outputs route to this skill.

Dimension	Reasoning	Score
Specificity	The description lists many concrete, distinct capabilities — 'playtest QA, automated bot playtests, mobile and responsive checks, production builds, static-hosting base paths, debug gating, bundle review, screenshots, visual regression baselines, canvas-pixel inspection with measured metrics, and release risk reports' — matching the comprehensive multi-action anchor.	5 / 5
Completeness	The 'what' is clearly and concretely answered, but there is no 'Use when...' clause or equivalent explicit trigger guidance, which caps completeness at 3 per the judging guidelines. It is not a 2 because the 'what' is detailed and specific, not vague.	3 / 5
Trigger Term Quality	Good natural keyword coverage ('Three.js browser games', 'playtest', 'release', 'screenshots', 'production builds', 'responsive') that users would plausibly say, but a few common variations like 'deploy', 'ship', or 'QA testing' are missing. It sits above the 'a few natural terms missing' threshold of 3 but is not the comprehensive synonym coverage of 5.	4 / 5
Distinctiveness Conflict Risk	'Verify and release Three.js browser games' defines a clear niche with distinct triggers (Three.js, browser games, playtest, release builds) and minimal conflict risk with other skills. Not 4, because the scope is narrowly and unmistakably tied to Three.js game QA/release rather than overlapping generic QA or build skills.	5 / 5
	Total	17 / 20 Passed

Validation

93%

Warnings & errors only

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

Validation — 15 / 16 Passed

Validation for skill structure

Criteria	Description	Result
referenced_paths_exist	Referenced path issues: 1 missing	Warning

	Total	15 / 16 Passed

Repository: majidmanzarpour/threejs-game-skills
Path: skills/threejs-qa-release/SKILL.md
Commit: 8286774

Reviewed: 4 days ago

Table of Contents

Discovery Implementation Validation

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.