test-environment
Test environment system (DomeGradient, IBLGradient, default lighting, component schemas) against the poke example using the iwsdk CLI.
50
55%
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-environment/SKILL.mdQuality
Discovery
40%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 highly domain-specific which helps with distinctiveness, but it lacks a 'Use when...' clause and reads more like a task instruction than a skill description. The technical jargon may help with precise matching but could miss natural user queries, and the absence of explicit trigger guidance significantly weakens its utility for skill selection.
Suggestions
Add a 'Use when...' clause specifying trigger conditions, e.g., 'Use when the user wants to test or validate environment lighting systems, component schemas, or run iwsdk CLI tests against the poke example.'
Include more natural language trigger terms alongside the technical ones, such as 'run tests', 'validate environment setup', 'test lighting configuration', or 'verify component schemas'.
Expand the 'what' portion to clarify the concrete actions performed, e.g., 'Runs validation tests on environment system components (DomeGradient, IBLGradient, default lighting, component schemas) using the iwsdk CLI against the poke example, reporting pass/fail results.'
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description names a specific domain (test environment system) and lists some concrete elements (DomeGradient, IBLGradient, default lighting, component schemas) and mentions a specific tool (iwsdk CLI) and example (poke example), but the actual actions are limited to just 'test...against'. | 2 / 3 |
Completeness | The description addresses 'what' (test environment system against poke example) but completely lacks a 'Use when...' clause or any explicit trigger guidance for when Claude should select this skill. Per rubric guidelines, a missing 'Use when...' clause should cap completeness at 2, and the 'what' itself is also somewhat unclear, warranting a score of 1. | 1 / 3 |
Trigger Term Quality | Includes some relevant technical keywords like 'DomeGradient', 'IBLGradient', 'iwsdk CLI', 'poke example', and 'component schemas', but these are highly specialized jargon. Missing common natural language terms a user might say like 'run tests', 'validate environment', or 'check lighting setup'. | 2 / 3 |
Distinctiveness Conflict Risk | The description is highly specific to a particular toolchain (iwsdk CLI), specific components (DomeGradient, IBLGradient), and a specific example (poke example), making it very unlikely to conflict with other skills. | 3 / 3 |
Total | 8 / 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 procedure with clear sequencing, validation checkpoints, recovery procedures, and concrete expected values. Its main weakness is that it's a large monolithic document—the shell helper, known issues, and individual test suites could benefit from being split into referenced files. The content is slightly verbose in places but generally earns its length through specificity.
Suggestions
Extract the MCPCALL shell function into a separate helper script file (e.g., mcpcall.sh) and reference it from the skill, reducing the body by ~30 lines.
Move the 'Known Issues & Workarounds' section to a separate KNOWN_ISSUES.md file and link to it, keeping the main skill focused on execution steps.
Consider extracting the detailed component schema tables and default value tables into a separate EXPECTED_VALUES.md reference file.
| 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 and could be provided as a referenced script file. Some explanations (e.g., tool calling pattern details) are somewhat redundant given the shell function already encapsulates the logic. | 2 / 3 |
Actionability | Every step has concrete, executable bash commands with specific tool names, JSON arguments, and explicit assertions with expected values. The default value tables, entity discovery patterns, and verification commands are all copy-paste ready. | 3 / 3 |
Workflow Clarity | The workflow is clearly sequenced across 5 steps with explicit validation at each stage (connectivity check, pre-test assertions, per-suite assertions). Recovery procedures with retry logic are well-defined, and there are clear fail-fast instructions if the server doesn't start. | 3 / 3 |
Progressive Disclosure | This is a monolithic ~250-line document with no references to external files. The MCPCALL shell function, known issues, component schema tables, and individual test suites could all be split into separate referenced files to reduce cognitive load and token usage. | 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.