test-locomotion
Test locomotion system (slide, snap turn, teleport, jump) against the locomotion example using the iwsdk CLI.
61
72%
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-locomotion/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 is strong in specificity and distinctiveness, clearly naming concrete locomotion actions and the specific CLI tool. However, it lacks an explicit 'Use when...' clause, which weakens completeness, and the trigger terms are somewhat technical without covering natural user phrasing variations.
Suggestions
Add a 'Use when...' clause, e.g., 'Use when the user wants to test or verify locomotion features like sliding, snap turning, teleporting, or jumping using the iwsdk CLI.'
Include natural language variations users might say, such as 'movement testing', 'VR locomotion', 'player movement', or 'locomotion QA'.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions: 'slide, snap turn, teleport, jump' as locomotion types, and specifies the tool ('iwsdk CLI') and target ('locomotion example'). Very concrete. | 3 / 3 |
Completeness | Clearly answers 'what' (test locomotion system components against the locomotion example using iwsdk CLI), 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 domain-specific terms like 'locomotion', 'slide', 'snap turn', 'teleport', 'jump', and 'iwsdk CLI', but these are fairly technical. Missing common variations a user might say like 'movement testing', 'VR locomotion', or 'player movement'. | 2 / 3 |
Distinctiveness Conflict Risk | Highly specific niche: testing a locomotion system with specific movement types using the iwsdk CLI. Very unlikely to conflict with other skills due to the unique combination of domain (locomotion) and tool (iwsdk CLI). | 3 / 3 |
Total | 10 / 12 Passed |
Implementation
77%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 executable commands, clear assertions, and robust error recovery procedures. Its main weakness is length — the monolithic structure could benefit from splitting reference material (input mappings, known issues, the MCPCALL helper) into separate files. Conciseness could be improved by trimming some explanatory text that Claude doesn't need.
Suggestions
Extract the MCPCALL shell function, input mapping reference table, and known issues into separate bundle files (e.g., MCPCALL_HELPER.md, INPUT_MAPPING.md, KNOWN_ISSUES.md) to improve progressive disclosure.
Trim explanatory sentences like 'The helper below keeps the existing MCP-style tool names, but it resolves them through iwsdk mcp inspect and then executes the matching CLI command directly' — Claude can infer this from the code.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is fairly long but most content is necessary (executable commands, assertions, input mapping table). However, the MCPCALL shell function definition is verbose and the explanatory text around tool calling patterns could be tightened. Some instructions like explaining what MCPCALL does are somewhat redundant given the inline code. | 2 / 3 |
Actionability | Every step has fully executable bash commands with exact arguments, specific JSON payloads, concrete assertions with expected values, and clear pass/fail criteria. The input mapping reference table is excellent. Commands are copy-paste ready. | 3 / 3 |
Workflow Clarity | The workflow is clearly sequenced across 5 steps with explicit validation checkpoints (verify connectivity before testing, check console logs, assert entity existence). Recovery procedures with retry logic are well-defined, and the pre-test setup includes explicit wait times and verification. Feedback loops are present (retry once, then mark FAIL). | 3 / 3 |
Progressive Disclosure | The document is a monolithic ~300-line file with no references to external files. The input mapping table, known issues, and recovery sections could be split into separate reference files. However, the internal structure with clear headers and numbered steps provides reasonable navigation within the single file. | 2 / 3 |
Total | 10 / 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.