test-interactions
Test XR interactions (ray, poke/touch, dual-mode, audio, UI panel) against the poke example using the iwsdk CLI.
60
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-interactions/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 technically specific and clearly identifies a narrow domain (XR interaction testing with iwsdk CLI), making it distinctive. However, it lacks an explicit 'Use when...' clause and could benefit from more natural trigger terms that users might employ when requesting this type of work.
Suggestions
Add an explicit 'Use when...' clause, e.g., 'Use when the user wants to test XR interactions, verify poke/ray/touch behavior, or run interaction tests with the iwsdk CLI.'
Include broader natural trigger terms such as 'VR testing', 'virtual reality interactions', 'spatial interaction tests', or 'XR input testing' to improve discoverability.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions: testing ray interactions, poke/touch interactions, dual-mode, audio, and UI panel interactions. Also specifies the tool (iwsdk CLI) and reference (poke example). | 3 / 3 |
Completeness | Clearly answers 'what does this do' (test XR interactions against the poke 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 domain-specific terms like 'XR interactions', 'ray', 'poke', 'touch', 'iwsdk CLI', and 'UI panel', which are relevant but fairly technical. Missing common user phrasings like 'test VR', 'virtual reality', 'interaction testing', or broader trigger terms a user might naturally say. | 2 / 3 |
Distinctiveness Conflict Risk | Highly specific niche: XR interaction testing with the iwsdk CLI against a poke example. This is unlikely to conflict with other skills due to the very specialized domain and tooling mentioned. | 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 excellent workflow clarity — every step has concrete commands, explicit assertions, and proper sequencing with validation checkpoints and recovery procedures. Its main weakness is length: all 12 test suites are inline in a single file, which consumes significant token budget. Some minor verbosity exists in the helper function and known issues section, but the content is overwhelmingly practical and executable.
Suggestions
Split the 12 test suites into separate files (e.g., suite-ray.md, suite-poke.md, suite-audio.md) and keep SKILL.md as a concise overview with setup/teardown and references to each suite file.
Consider moving the MCPCALL shell function definition to a separate shell script file (e.g., mcpcall.sh) that can be sourced, reducing the SKILL.md body by ~30 lines.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is very long (~500+ lines) but most content is actionable test steps with concrete commands. Some sections could be tightened (e.g., the MCPCALL shell function is verbose, the Known Issues section explains things Claude could infer), but overall the length is justified by the 12 test suites. The hardcoded absolute paths are appropriate for a project-specific skill. | 2 / 3 |
Actionability | Every test suite provides exact bash commands with concrete arguments, specific assertions (component present/absent, field values), and clear expected outcomes. The MCPCALL helper is fully executable, and placeholder syntax like `<robot>` is well-explained with discovery steps. | 3 / 3 |
Workflow Clarity | The workflow is meticulously sequenced: install → start server → verify connectivity → run suites in order → cleanup. Each suite has explicit validation assertions after every action, sleep commands for timing, and the Recovery section provides a clear retry loop. The 'run one command at a time' instruction and pre-test setup are excellent checkpoints. | 3 / 3 |
Progressive Disclosure | The content is a monolithic document with all 12 test suites inline. While the structure uses clear headers and numbered steps, the sheer volume (entity discovery, ray, poke, dual-mode, audio, UI, stability) could benefit from splitting suites into separate files with a summary overview in the main SKILL.md. No bundle files are provided to offload content. | 2 / 3 |
Total | 10 / 12 Passed |
Validation
81%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 9 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
skill_md_line_count | SKILL.md is long (665 lines); consider splitting into references/ and linking | Warning |
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 9 / 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.