test-ecs-core
Test ECS core functionality (system registration, components, Transform sync, pause/step/resume, system toggle, entity discovery, snapshots) against the poke example using the iwsdk CLI.
59
68%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./.claude/skills/test-ecs-core/SKILL.mdQuality
Discovery
67%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 excels at specificity and distinctiveness by listing concrete ECS testing actions, a specific target (poke example), and a specific tool (iwsdk CLI). Its main weakness is the absence of an explicit 'Use when...' clause, which would help Claude know exactly when to select this skill. The trigger terms are relevant but highly technical, potentially missing more natural user phrasings.
Suggestions
Add an explicit 'Use when...' clause, e.g., 'Use when the user wants to test or verify ECS functionality, debug entity-component-system behavior, or validate the poke example with iwsdk.'
Include natural language trigger variations such as 'entity component system testing', 'ECS debugging', or 'verify ECS systems work correctly' to improve discoverability.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions: system registration, components, Transform sync, pause/step/resume, system toggle, entity discovery, snapshots. Also specifies the target (poke example) and tool (iwsdk CLI). | 3 / 3 |
Completeness | Clearly answers 'what does this do' (test ECS core functionality with specific sub-features), but lacks an explicit 'Use when...' clause or equivalent trigger guidance, which caps this at 2 per the rubric. | 2 / 3 |
Trigger Term Quality | Includes relevant technical terms like 'ECS', 'system registration', 'components', 'Transform sync', 'snapshots', 'iwsdk CLI', and 'poke example'. However, these are fairly domain-specific and may miss natural user phrasings like 'test my ECS setup' or 'debug entity component system'. No common variations are provided. | 2 / 3 |
Distinctiveness Conflict Risk | Highly specific niche: testing ECS core functionality against the poke example using the iwsdk CLI. This is unlikely to conflict with other skills due to the very targeted domain, specific tool, and specific test target. | 3 / 3 |
Total | 10 / 12 Passed |
Implementation
70%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a highly actionable and well-structured test skill with excellent workflow clarity, explicit assertions, and robust error recovery procedures. Its main weakness is that all content is packed into a single large file with no progressive disclosure — the MCPCALL helper, individual test suites, and known issues could be split into referenced files. The content is mostly concise given its scope but has some redundancy in explanatory notes.
Suggestions
Extract the MCPCALL shell helper into a separate referenced file (e.g., MCPCALL_HELPER.md or a .sh script) to reduce the main skill's size and improve progressive disclosure.
Consider splitting the 8 test suites into a separate TESTS.md file, keeping only the workflow overview (Steps 1-5) and suite summary in the main SKILL.md.
Consolidate the two IMPORTANT notes about running commands one at a time and using sleep into a single concise note to reduce repetition.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is quite long (~300+ lines) but most content is necessary test specifications with concrete assertions. However, the MCPCALL helper function is verbose and the repeated pattern explanations (e.g., explaining tool calling pattern, multiple IMPORTANT notes) add some bloat. The Known Issues section is useful but could be tighter. | 2 / 3 |
Actionability | Every test suite provides exact bash commands, specific JSON arguments, and precise assertions with expected values (e.g., exact system names, priorities, field types, tolerance values). The commands are copy-paste ready and the assertions are concrete and verifiable. | 3 / 3 |
Workflow Clarity | The workflow is clearly sequenced from install → start server → verify connectivity → run suites → cleanup. It includes explicit validation checkpoints (connectivity check before tests, console log checks), error recovery procedures with retry logic, and a dedicated Recovery section with feedback loops for transient failures. | 3 / 3 |
Progressive Disclosure | The entire skill is a monolithic document with no references to external files. All 8 test suites, the MCPCALL helper, known issues, and recovery procedures are inlined in a single file. The test specifications and helper function could be split into separate referenced files to improve navigability. | 1 / 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 |
|---|---|---|
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 10 / 11 Passed | |
- Repository
- facebook/immersive-web-sdk
- Commit
b3d1162
- 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.