test-setup

Scaffold the test framework and CI — tests/ directory, engine test runner, GitHub Actions workflow. Once, before the first sprint.

Quality

76%

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

Fix and improve this skill with Tessl

tessl review fix ./.claude/skills/test-setup/SKILL.md

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.

An exceptionally actionable, well-sequenced operational skill whose body is dense with non-obvious engine-specific knowledge. Its weaknesses are structural: three engine branches fully inlined in one monolithic file with no progressive disclosure, and noticeable redundancy from restating the same rules across phases.

Suggestions

Split each engine's runner and CI detail into references/godot.md, references/unity.md, and references/unreal.md, keeping shared phases in SKILL.md and loading only the detected engine's file — this alone would roughly halve the body.

State the engine-test-root rule once authoritatively (e.g., in Phase 1 or the README template) and reference it elsewhere instead of restating it in Phases 1, 2, 3, and the summary.

Trim motivational framing and fold the scattered exit-code interpretations into one compact per-engine table near each run command.

Dimension	Reasoning	Score
Conciseness	Most content is hard-won operational knowledge Claude does not have (gdUnit4 exit codes, Unity false-pass traps, UnrealBuildTool quirks), but the engine-test-root rule is restated in Phases 1, 2, 3, and 6, and motivational framing ('costs 30 minutes… costs 3 sprints') plus long inline YAML comments add padding. It is more than minor over-explanation (not 4) yet far from concept-explaining filler (not 2).	3 / 5
Actionability	Fully executable throughout: complete per-engine CI YAML, exact runner commands with every required flag, copy-paste asmdef JSON, and literal file contents for every artifact. Placeholders like [ProjectName] are appropriately parameterized project values, and the skill explains how to resolve each one.	5 / 5
Workflow Clarity	Six clearly sequenced phases with validation up front (engine-detection stop condition, existing-infrastructure check, approval gate, never-overwrite guardrail) and explicit exit-code interpretation for verifying runs. A minor gap keeps it from 5: there is no post-creation verification step (e.g., triggering or dry-running the CI workflow once to confirm it works).	4 / 5
Progressive Disclosure	The skill is a ~590-line monolith with no bundle files at all; three full engine branches (~300 lines of per-engine runner and CI detail) are inlined where a one-level-deep references/<engine>.md structure would let Claude load only the detected engine's content. Phase organization is good (not 2), but content that clearly belongs in separate files is inline and no references exist (not 4+).	3 / 5
	Total	15 / 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 strong description: concise, third-person, and specific about the artifacts it creates, with an explicit one-time pre-sprint usage window. Its main gaps are missing natural trigger variations (unit tests, automated testing) and a 'when' phrased as lifecycle timing rather than a user-situation trigger.

Dimension	Reasoning	Score
Specificity	The description lists several concrete artifacts — 'tests/ directory, engine test runner, GitHub Actions workflow' — matching the anchor for several specific actions with minor gaps. It falls short of 5 because it omits scope the skill actually covers (smoke test seed, engine test roots, production/qa/evidence).	4 / 5
Completeness	Clear 'what' ('Scaffold the test framework and CI — tests/ directory, engine test runner, GitHub Actions workflow') and an explicit 'when' ('Once, before the first sprint') that qualifies as equivalent trigger guidance, so the missing-'Use when' cap does not apply. It is not 5 because the 'when' is lifecycle timing rather than a concrete user-intent trigger phrase.	4 / 5
Trigger Term Quality	Natural terms present: 'test framework', 'test runner', 'CI', 'GitHub Actions', 'tests/'. Good keyword coverage, but common variations users would say — 'unit tests', 'automated testing', 'set up tests' — are missing, so it does not reach the comprehensive-synonym level of 5.	4 / 5
Distinctiveness Conflict Risk	A clear niche — scaffolding test infrastructure and CI wiring, not writing tests — with distinct triggers ('test framework', 'GitHub Actions workflow'). Minor overlap risk with general test-writing or CI-setup skills keeps it below 5.	4 / 5
	Total	16 / 20 Passed

Validation

81%

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 — 13 / 16 Passed

Validation for skill structure

Criteria	Description	Result
skill_md_line_count	SKILL.md is long (601 lines); consider splitting into references/ and linking	Warning
allowed_tools_field	'allowed-tools' contains unusual tool name(s)	Warning
frontmatter_unknown_keys	Unknown frontmatter key(s) found; consider removing or moving to metadata	Warning

	Total	13 / 16 Passed

Repository: Donchitos/Claude-Code-Game-Studios
Path: .claude/skills/test-setup/SKILL.md
Commit: b21fa0f

Reviewed: 3 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.