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 actually say. The technical jargon is appropriate for the domain but may limit discoverability.
Suggestions
Add a 'Use when...' clause, e.g., 'Use when the user wants to test XR interactions, verify poke/ray behavior, or run interaction tests with the iwsdk CLI.'
Include broader trigger term variations such as 'VR', 'virtual reality', 'interaction testing', 'spatial input', or 'XR testing' to improve matching with natural user queries.
| 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' (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 variations. | 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 references. | 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 procedure with excellent workflow clarity, explicit validation at every step, and robust error recovery guidance. Its main weakness is length — the monolithic structure packs all 12 test suites, recovery procedures, and known issues into a single file, which could be better organized with progressive disclosure. Minor verbosity exists in repeated patterns and some non-actionable historical notes in the Known Issues section.
Suggestions
Consider extracting the 12 test suites into a separate SUITES.md or grouping related suites (e.g., ray tests, poke tests, audio/UI tests) into separate files referenced from the main SKILL.md.
Remove the historical fix note ('Fixed: processTouchLifecycle now dispatches pointer.up()') from Known Issues — it's not actionable for the test runner and adds noise.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is quite long (~400+ lines) but most content is necessary executable commands and assertions. However, there's some redundancy in repeated patterns (e.g., sleep+query patterns repeated many times without abstraction), and the 'Known Issues & Workarounds' section includes some implementation details (like 'Fixed: processTouchLifecycle now dispatches pointer.up()') that are historical notes rather than actionable guidance. | 2 / 3 |
Actionability | Every test provides exact CLI commands with concrete JSON arguments, explicit assertions with expected values, and clear pass/fail criteria. Commands are copy-paste ready with only dynamic placeholders (like <robot>) that are clearly defined earlier in the workflow. | 3 / 3 |
Workflow Clarity | The workflow is meticulously sequenced: install → start server → verify connectivity → pre-test setup → 12 ordered suites → cleanup. Each step has explicit validation (assert statements), there's a recovery section with retry logic, and the pre-test setup includes a checkpoint for error logs before testing begins. Sleep/wait steps are explicit. | 3 / 3 |
Progressive Disclosure | The content is a monolithic document with all 12 test suites inline. While the structure uses clear headers and horizontal rules for navigation, the sheer volume (recovery procedures, known issues, 12 detailed suites) could benefit from splitting into separate files. No bundle files are provided, so there's no external reference structure to leverage. | 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 (605 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
3a08b40
- 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.