dojo-init
Initialize new Dojo projects with proper directory structure, configuration files, and dependencies. Use when starting a new Dojo game project or setting up the initial project structure.
80
70%
Does it follow best practices?
Impact
100%
1.47xAverage score across 3 eval scenarios
Advisory
Suggest reviewing before use
Optimize this skill with Tessl
npx tessl skill review --optimize ./.agents/skills/dojo-init/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.
The description is well-structured with a clear 'what' and 'when' clause, and targets a distinct niche (Dojo game project initialization). Its main weakness is moderate specificity—it could enumerate more concrete actions—and it could include more natural trigger term variations that users might use when requesting project scaffolding.
Suggestions
Add more specific concrete actions, e.g., 'Creates Scarb.toml, sets up src/ directory with systems and components, configures world manifest'
Include additional trigger term variations users might say, such as 'scaffold', 'bootstrap', 'create new project', 'dojo init', or 'starter template'
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (Dojo projects) and some actions (initialize, directory structure, configuration files, dependencies), but doesn't list specific concrete actions like which config files, what directory structure, or what dependencies are set up. | 2 / 3 |
Completeness | Clearly answers both 'what' (initialize new Dojo projects with proper directory structure, configuration files, and dependencies) and 'when' (Use when starting a new Dojo game project or setting up the initial project structure) with an explicit 'Use when...' clause. | 3 / 3 |
Trigger Term Quality | Includes relevant terms like 'Dojo', 'project', 'initialize', 'directory structure', 'dependencies', but misses common variations users might say such as 'scaffold', 'bootstrap', 'create new project', 'dojo init', 'setup', or 'boilerplate'. | 2 / 3 |
Distinctiveness Conflict Risk | The description is clearly scoped to Dojo game project initialization, which is a distinct niche unlikely to conflict with other skills. The combination of 'Dojo' and 'initialize/setup' creates a clear trigger boundary. | 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 project initialization skill with excellent actionability—concrete commands, complete config files, and a clear project structure. Its main weaknesses are moderate verbosity (redundant summary sections, descriptions of template contents that Claude could infer) and missing validation checkpoints in the workflow. The progressive disclosure to related skills is well done but the inline content could be trimmed.
Suggestions
Remove the 'When to Use This Skill' and 'What This Skill Does' sections—these repeat information from the title and description and consume tokens without adding value.
Add a validation step after initialization (e.g., 'Verify: `sozo build` should complete without errors') and between build/migrate steps in the Development Workflow.
Trim the 'Starter Template Contents' section—Claude doesn't need descriptions of what Position and Moves models contain; a brief note that the starter includes example models, systems, and tests suffices.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill includes some unnecessary sections like 'When to Use This Skill' trigger phrases and 'What This Skill Does' summary that largely repeat the heading/description. The starter template contents section describes things Claude could infer from the code. However, the configuration examples and project structure are genuinely useful reference material. | 2 / 3 |
Actionability | Provides fully executable commands (sozo init, katana, sozo build && sozo migrate), complete configuration file examples that are copy-paste ready, and a concrete project structure. The Scarb.toml and dojo_dev.toml examples include specific version numbers and realistic values. | 3 / 3 |
Workflow Clarity | The Development Workflow section provides a clear numbered sequence, but lacks validation checkpoints. There's no verification step after initialization (e.g., checking the project was created correctly), no error handling guidance if sozo init fails, and no validation between build and migrate steps. | 2 / 3 |
Progressive Disclosure | The skill references related skills (dojo-model, dojo-system, etc.) which is good progressive disclosure, but the main content is somewhat monolithic. The configuration file examples and starter template contents could potentially be referenced rather than inlined, as they make the skill quite long. The 'Related Skills' and 'Next Steps' sections provide good navigation. | 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 | |
- Repository
- steebchen/proof-of-war
- Commit
44466c6
- 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.