test-helpers

Generate engine-specific test helper libraries — assertion utilities, factory functions, mocks in the engine's test folder. Reduces boilerplate.

Quality

73%

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-helpers/SKILL.md

Quality

Content

70%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 strong, highly actionable body with a clear six-step workflow, per-engine executable templates, and unusually good validation gates (never-overwrite, ask-before-write, refuse-to-guess the framework API). Its weaknesses are systematic repetition of the assertion-resolution rule, inlining all three engines' templates in one file, and a mocks deliverable promised by the description but never templated.

Suggestions

Move each engine's code templates into references/<engine>.md and load only the one matching the detected engine — the other two engines' templates are dead context for any given project.

State the resolve-the-assertion-API rule once in §2 and mark placeholders with a single short comment; delete the repeated "# FRAMEWORK ASSERT — resolve per the rule above" comments and condense the 17-line blockquote to two or three lines.

Add a mock/stub helper template (or drop "mocks" from the description) so the body delivers everything the description promises.

Dimension	Reasoning	Score
Conciseness	The body is code-forward and mostly efficient, but the §2 no-bare-assert() rule is restated at length in a ~17-line blockquote ("sixty lines below §2 forbidding it…") and the comment "# FRAMEWORK ASSERT — resolve per the rule above; do not emit assert()" is repeated four times within one code block — unnecessary explanation that could be tightened to one mention.	3 / 5
Actionability	Guidance is highly executable — exact Glob patterns per engine, config keys with a fallback chain, a full Grep invocation with -A 30, scripted user prompts, and complete Unity/Unreal templates; the Godot FAIL_IF placeholder is non-executable but explicitly justified, which the rubric exempts. Held at 4 rather than 5 because the description promises "mocks" yet no mock/stub helper template exists, and the system-specific example covers only Godot.	4 / 5
Workflow Clarity	Six numbered steps in coherent order with explicit validation gates: engine-configured check ("Engine not configured. Run /setup-engine first."), never-overwrite check with a scripted report message, ask-before-write permission, and a resolve-the-assertion-API-or-generate-nothing feedback loop with error recovery.	5 / 5
Progressive Disclosure	No bundle files exist and sections are clearly headed, but ~250 lines of per-engine code templates are inlined when only one engine's templates are ever relevant per project — the classic content that belongs in one-level-deep references/<engine>.md files loaded after engine detection.	3 / 5
	Total	15 / 20 Passed

Description

66%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, largely well-targeted description that names concrete deliverables and their destination, written in third person. Its main weakness is the complete absence of when-to-use trigger guidance, plus missing engine-name keywords that users would naturally say.

Suggestions

Add a "Use when…" clause with concrete triggers, e.g. "Use when tests repeat the same setup boilerplate, when writing tests for a new system, or when the user asks for test helpers, factories, or mocks."

Include the engine names (Godot, Unity, Unreal) as trigger terms — users will naturally say "write test helpers for Godot" or "Unity test factory".

Differentiate from the sibling `/test-setup` skill, e.g. "Run after /test-setup scaffolds the framework" so the two skills' trigger zones don't overlap.

Dimension	Reasoning	Score
Specificity	"assertion utilities, factory functions, mocks in the engine's test folder" lists three concrete action types plus placement, but "Reduces boilerplate" is a benefit tag rather than an action and coverage stops at the three named items — several specific actions with minor gaps rather than comprehensive.	4 / 5
Completeness	The "what" is clear — generate engine-specific helper libraries with assertions, factories, and mocks in the engine's test folder — but there is no "Use when…" clause or equivalent trigger guidance, which caps completeness at 3.	3 / 5
Trigger Term Quality	Natural terms users would say are present ("test helper", "assertion utilities", "factory functions", "mocks", "boilerplate"), but the engine names (Godot, Unity, Unreal) and common variations like "unit tests" are missing.	4 / 5
Distinctiveness Conflict Risk	The niche (generating test helper libraries for game engines) is distinct and unlikely to trigger unrelated skills, but it overlaps with a sibling `/test-setup` skill that scaffolds the test framework, which the description does not differentiate from.	4 / 5
	Total	15 / 20 Passed

Validation

87%

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

Validation for skill structure

Criteria	Description	Result
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	14 / 16 Passed

Repository: Donchitos/Claude-Code-Game-Studios
Path: .claude/skills/test-helpers/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.