Write tests for Dojo models and systems using spawn_test_world, cheat codes, and assertions. Use when testing game logic, verifying state changes, or ensuring system correctness.
79
70%
Does it follow best practices?
Impact
99%
2.02xAverage score across 3 eval scenarios
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./skills/dojo-test/SKILL.mdQuality
Discovery
75%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This is a solid description that clearly communicates both what the skill does and when to use it, with domain-specific terminology (Dojo, spawn_test_world, cheat codes) that creates strong distinctiveness. The main weakness is that the specific actions could be more granular—'write tests' is somewhat broad—and trigger terms could include more user-facing variations beyond the framework-specific jargon.
Suggestions
Add more specific concrete actions like 'mock contract state, simulate transactions, test model field updates, validate system dispatch behavior'
Include additional natural trigger terms users might say, such as 'unit test', '#[test]', 'test contract', 'test world setup', or 'Cairo tests'
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (Dojo testing) and some specific tools (spawn_test_world, cheat codes, assertions), but doesn't list multiple concrete actions beyond 'write tests'. The specific tools mentioned add some concreteness, but the actions themselves remain somewhat general. | 2 / 3 |
Completeness | Clearly answers both 'what' (write tests for Dojo models and systems using spawn_test_world, cheat codes, and assertions) and 'when' (use when testing game logic, verifying state changes, or ensuring system correctness) with explicit trigger guidance. | 3 / 3 |
Trigger Term Quality | Includes relevant terms like 'tests', 'Dojo models', 'systems', 'spawn_test_world', 'cheat codes', 'game logic', 'state changes', and 'system correctness'. However, it misses common variations users might say like 'unit tests', '#[test]', 'testing framework', or specific Dojo testing patterns. | 2 / 3 |
Distinctiveness Conflict Risk | The combination of 'Dojo', 'spawn_test_world', and 'cheat codes' creates a very specific niche that is unlikely to conflict with general testing skills or other framework-specific skills. The domain is clearly scoped to Dojo game engine testing. | 3 / 3 |
Total | 10 / 12 Passed |
Implementation
64%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a solid, highly actionable skill with excellent executable code examples covering the full spectrum of Dojo testing patterns. Its main weaknesses are moderate verbosity from unnecessary framing sections (trigger phrases, interactive mode descriptions) and the lack of explicit error-handling/debugging guidance in the workflow. The content would benefit from trimming the preamble and either adding failure-recovery guidance or splitting advanced patterns into a referenced file.
Suggestions
Remove or significantly trim the 'When to Use This Skill', 'What This Skill Does', and 'Quick Start' sections—they explain Claude's own behavior rather than providing actionable testing guidance.
Add a brief troubleshooting section or inline notes about common test failures (e.g., missing model registration, permission errors) and how to resolve them, which would improve workflow clarity.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is mostly efficient but includes some unnecessary sections like 'When to Use This Skill' trigger phrases, 'What This Skill Does' summary, and 'Quick Start' interactive/direct mode descriptions that don't add actionable value. The core test examples are well-written but the framing adds bloat. | 2 / 3 |
Actionability | Provides fully executable, copy-paste ready Cairo code examples covering unit tests, integration tests, cheat codes, model read/write, panic testing, and multi-player scenarios. The code is complete with proper imports and realistic assertions. | 3 / 3 |
Workflow Clarity | The test structure and organization are clearly presented, and the 'Next Steps' section provides a sequence. However, there are no explicit validation checkpoints or feedback loops for when tests fail—no guidance on interpreting test failures, debugging common issues, or iterating on broken tests. | 2 / 3 |
Progressive Disclosure | The content is well-structured with clear headers and a useful reference table, but it's quite long (~200+ lines of inline content) with detailed code examples that could be split into separate reference files. The references to related skills at the end are good, but the main body could benefit from moving advanced patterns to a separate file. | 2 / 3 |
Total | 9 / 12 Passed |
Validation
90%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 10 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
allowed_tools_field | 'allowed-tools' contains unusual tool name(s) | Warning |
Total | 10 / 11 Passed | |
52a1507
Table of Contents
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.