test-audio
Test audio system (AudioSource loading, playback state, stop, spatial audio) against the audio 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-audio/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 concrete actions and tools, making it distinctive. However, it lacks an explicit 'Use when...' clause, which limits its completeness score. The trigger terms are somewhat jargon-heavy and may not match natural user language patterns.
Suggestions
Add a 'Use when...' clause, e.g., 'Use when the user wants to test or verify audio functionality, sound playback, or spatial audio features in the iwsdk project.'
Include more natural trigger terms that users might say, such as 'test audio', 'sound testing', 'audio playback verification', or 'audio bugs'.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions: AudioSource loading, playback state, stop, spatial audio testing, and mentions the specific tool (iwsdk CLI) and testing against an audio example. | 3 / 3 |
Completeness | Clearly answers 'what' (test audio system components against the audio example using iwsdk CLI), but lacks an explicit 'Use when...' clause or equivalent trigger guidance, which caps this at 2 per the rubric guidelines. | 2 / 3 |
Trigger Term Quality | Includes relevant technical terms like 'AudioSource', 'playback', 'spatial audio', 'iwsdk CLI', but these are fairly domain-specific jargon. Missing more natural user phrases like 'test audio', 'audio tests', 'sound system testing'. Users might say 'test audio' but less likely to say 'AudioSource loading'. | 2 / 3 |
Distinctiveness Conflict Risk | Very specific niche: testing audio systems with the iwsdk CLI against an audio example. The combination of 'audio system', 'AudioSource', and 'iwsdk CLI' makes this highly distinctive and unlikely to conflict with other skills. | 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 well-structured, highly actionable test procedure with clear sequencing, explicit assertions, and good error recovery guidance. Its main weakness is length — the inline MCPCALL function definition, repeated warnings about boolean values, and the detailed component schema inflate the token count. Progressive disclosure could be improved by extracting the shell helper and known issues into separate files.
Suggestions
Extract the MCPCALL shell function into a separate helper script file (e.g., `mcpcall.sh`) and reference it from the skill to reduce inline verbosity.
Consolidate the three separate warnings about boolean values into a single mention in the Known Issues section, removing the inline IMPORTANT note and the Suite 2 repetition.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is fairly long but most content is necessary for the 6 test suites. However, the MCPCALL shell function is verbose (could be referenced from a file), the 'Known Issues' section repeats some warnings already stated inline (e.g., boolean values warning appears three times), and some explanatory text could be trimmed. | 2 / 3 |
Actionability | Every step has concrete, executable bash commands with exact tool names, JSON argument structures, and specific assertions with field names and expected values. The commands are copy-paste ready with clear placeholders like `<audio>` that are explained. | 3 / 3 |
Workflow Clarity | The workflow is clearly sequenced (install → start server → verify connectivity → run suites → cleanup) with explicit validation at each step, sleep/wait instructions, retry/recovery procedures, and a clear feedback loop for transient failures. Pre-test setup has ordered steps with timing. Failure conditions are handled with skip-to-cleanup instructions. | 3 / 3 |
Progressive Disclosure | The content is a monolithic document with no references to external files. The MCPCALL shell function (~30 lines) could be extracted to a helper script. The Known Issues section and the detailed component schema could be separate reference files. However, for a test procedure skill, having everything in one place has some justification. | 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.