test-environment
Test environment system (DomeGradient, IBLGradient, default lighting, component schemas) against the poke example using the iwsdk CLI.
52
58%
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 identifies a narrow, specific domain involving testing environment systems with the iwsdk CLI, which gives it good distinctiveness. However, it lacks a 'Use when...' clause entirely, and the actions described are limited to a single vague verb ('test...against'). The technical jargon, while appropriate for the domain, is not supplemented with natural language trigger terms a user might employ.
Suggestions
Add an explicit 'Use when...' clause, e.g., 'Use when the user wants to run environment tests, validate lighting configurations, or test component schemas using the iwsdk CLI.'
Expand the action verbs to be more specific about what testing entails, e.g., 'Validates environment lighting (DomeGradient, IBLGradient), verifies component schemas, and runs integration tests against the poke example.'
Include natural language trigger terms users might say, such as 'run tests', 'validate environment', 'check lighting', or 'iwsdk test'.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description names a specific domain (test environment system) and mentions concrete elements like DomeGradient, IBLGradient, default lighting, component schemas, and the poke example. However, the actual actions are limited to just 'test...against' which is somewhat vague about what testing entails. | 2 / 3 |
Completeness | The description addresses 'what' (test environment system against the poke example) but completely lacks a 'Use when...' clause or any explicit trigger guidance for when Claude should select this skill. Per the rubric, a missing 'Use when...' clause caps completeness at 2, and the 'what' itself is also somewhat unclear, warranting a score of 1. | 1 / 3 |
Trigger Term Quality | Includes domain-specific terms like 'DomeGradient', 'IBLGradient', 'iwsdk CLI', 'poke example', and 'component schemas' which are relevant but highly technical. Missing natural language variations a user might say, such as 'run tests', 'validate environment', or 'check lighting setup'. | 2 / 3 |
Distinctiveness Conflict Risk | The description is highly specific to a particular toolchain (iwsdk CLI) and particular components (DomeGradient, IBLGradient, poke example), making it very unlikely to conflict with other skills. It occupies a clear, narrow niche. | 3 / 3 |
Total | 8 / 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 high-quality, actionable test procedure with excellent workflow clarity, precise assertions, and concrete CLI commands throughout. Its main weakness is moderate verbosity from repeated warnings and a monolithic structure that could benefit from splitting reference material (component schemas, known issues) into separate files. The recovery procedures and error handling guidance are particularly strong.
Suggestions
Remove duplicate boolean warning — state it once prominently at the top and remove the repetition in Known Issues and Suite 5 comments.
Consider extracting the component schema tables and Known Issues into a separate reference file (e.g., ENVIRONMENT_REFERENCE.md) to reduce the main skill's length.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is mostly efficient and avoids explaining basic concepts, but there's some redundancy — the boolean warning appears three times (intro, Suite 5, Known Issues), and the Known Issues section repeats information already covered inline. The tables and structure are well-used but could be tighter. | 2 / 3 |
Actionability | Every step has concrete, copy-paste-ready CLI commands with exact flags, JSON inputs, and specific expected values in tables. Assertions are precise with exact color arrays and field values. The placeholder `<root>` is clearly defined and referenced throughout. | 3 / 3 |
Workflow Clarity | The workflow is clearly sequenced with numbered steps, explicit validation checkpoints (connectivity check, pre-test assertions, per-suite assertions), error recovery procedures with retry logic, and clear fail-fast conditions (e.g., skip to Step 5 if server doesn't start). The recovery section provides a structured feedback loop. | 3 / 3 |
Progressive Disclosure | The content is well-structured with clear sections and headers, but it's a long monolithic document (~200+ lines) with no references to external files. The Known Issues section and detailed component schemas could be split into separate reference files. However, since no bundle files are provided, this is evaluated in isolation and the single-file approach is somewhat justified. | 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
e8f9df1
- 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.