test-all
Parallel test orchestrator. Runs all 9 test suites concurrently via Task sub-agents and the iwsdk CLI. Handles build, example setup, dev servers, agent launch, polling, retries, and result aggregation.
61
72%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Advisory
Suggest reviewing before use
Optimize this skill with Tessl
npx tessl skill review --optimize ./.claude/skills/test-all/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 strong on specificity and distinctiveness, clearly enumerating concrete actions and referencing a specific tool (iwsdk CLI) and architecture (Task sub-agents). However, it lacks an explicit 'Use when...' clause, which caps completeness, and the trigger terms lean toward implementation jargon rather than natural user language.
Suggestions
Add an explicit 'Use when...' clause, e.g., 'Use when the user wants to run the full test suite, execute parallel tests, or validate all test cases.'
Include more natural trigger terms users might say, such as 'run tests', 'test runner', 'run all tests', 'CI tests', or 'test validation'.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions: runs 9 test suites concurrently, handles build, example setup, dev servers, agent launch, polling, retries, and result aggregation. These are concrete, specific capabilities. | 3 / 3 |
Completeness | Clearly answers 'what does this do' with detailed actions, but lacks an explicit 'Use when...' clause or equivalent trigger guidance. The 'when' is only implied by the nature of the actions described. | 2 / 3 |
Trigger Term Quality | Includes some relevant terms like 'test suites', 'retries', 'build', and 'iwsdk CLI', but misses common user-facing trigger terms. Users might say 'run tests', 'test runner', 'parallel tests', or 'CI' — some of these are partially covered but the description leans more toward implementation detail than natural user language. | 2 / 3 |
Distinctiveness Conflict Risk | Highly specific niche: parallel test orchestration using Task sub-agents and the iwsdk CLI with exactly 9 test suites. This is very unlikely to conflict with other skills due to its specificity to a particular testing framework and workflow. | 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 strong orchestration skill with excellent workflow clarity and actionability — every phase has concrete commands, clear sequencing, and explicit validation checkpoints. The main weaknesses are moderate verbosity in the 'Key Design Decisions' section (which explains rationale Claude doesn't need to act on) and the length of the monolithic file, which could benefit from splitting reference material into supporting files.
Suggestions
Move the 'Key Design Decisions' section to a separate DESIGN.md or remove it entirely — most of these rationale explanations don't change Claude's behavior and consume tokens unnecessarily.
Consider moving the 'Troubleshooting' section to a separate TROUBLESHOOTING.md referenced from the main skill, to keep the primary workflow leaner.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is mostly efficient but includes some unnecessary sections like 'Key Design Decisions' that explain rationale Claude doesn't need (e.g., why ports aren't pre-assigned, why sub-agents read skill files). The troubleshooting section is useful but some entries are obvious. The test map table and phase structure are well-organized and earn their tokens. | 2 / 3 |
Actionability | Provides concrete, executable bash commands at every step, specific sub-agent prompt templates, exact tool parameters (subagent_type, mode, run_in_background), a clear data structure for tracking agents, and a precise output format for the results table. Nearly everything is copy-paste ready. | 3 / 3 |
Workflow Clarity | The 7-phase workflow is clearly sequenced with explicit stop-on-failure checkpoints (Phase 1), validation steps (server readiness polling with timeout in Phase 3), retry logic with clear limits (Phase 6), and a well-defined cleanup sequence (Phase 7). The feedback loop for retries distinguishes transient vs assertion failures and caps retries at 1. | 3 / 3 |
Progressive Disclosure | The skill references 9 sub-skill files (e.g., test-interactions/SKILL.md) which is good progressive disclosure, but no bundle files are provided to verify they exist. The main file itself is quite long (~200 lines) and the 'Key Design Decisions' and 'Troubleshooting' sections could potentially be split into a separate reference file. The structure within the file is well-organized with clear headers. | 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
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.