test-environment

Test environment system (DomeGradient, IBLGradient, default lighting, component schemas) against the poke example using the iwsdk CLI.

Quality

—

Does it follow best practices?

Impact

—

No eval scenarios have been run

Securityby

Passed

No known issues

Quality

Content

92%

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

The body is highly actionable with excellent sequencing and validation checkpoints, but it is a monolithic single-file skill with no external references despite being well over 50 lines. Splitting the large default/schema tables into a reference file would improve progressive disclosure.

Suggestions

Extract the DomeGradient/IBLGradient default-value tables and component schema tables into a references/ file (e.g. ENVIRONMENT_DEFAULTS.md) and link to it from Suites 1 and 3.

Move the "Known Issues & Workarounds" section into a separate reference file referenced once from the body, reducing inline length and repetition.

Deduplicate the boolean-must-be-JSON guidance: state it once in the tool-call conventions block and link rather than repeating in Test 5.2 and Known Issues.

Dimension	Reasoning	Score
Conciseness	Lean and command-driven throughout: concrete npx iwsdk invocations with full --input-json payloads and assertion tables, with no padding explaining concepts Claude already knows; the only redundancy is the boolean-must-be-JSON note repeated across sections.	3 / 3
Actionability	Fully executable, copy-paste-ready commands with exact JSON arguments and precise expected values (e.g. DomeGradient sky "[0.2423, 0.6172, 0.8308, 1.0]"), leaving nothing abstract or pseudocode.	3 / 3
Workflow Clarity	Clear Step 1–5 / Suite 1–6 sequence with explicit assertion checkpoints after each command, connectivity verification with fallbacks, and a recovery feedback loop (stop, restart, retry once, then fail).	3 / 3
Progressive Disclosure	Well-sectioned but monolithic: no bundle files exist and the detailed default-value tables and Known Issues live inline in a 270-line SKILL.md rather than being split into one-level-deep reference files.	2 / 3
	Total	11 / 12 Passed

Description

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 specific and distinctive about what it tests, but it omits explicit trigger guidance and relies on technical jargon over natural user phrasing. Adding a "Use when..." clause would resolve the main gap.

Suggestions

Append an explicit trigger clause, e.g. "Use when verifying the environment/lighting system after changes to DomeGradient, IBLGradient, or default lighting in the poke example."

Add natural-language keywords users might actually say (e.g. "test lighting", "verify environment", "check gradient defaults") alongside the technical component names.

Keep the third-person voice but lead with the user-facing verb ("Tests ...") to strengthen trigger discoverability.

Dimension	Reasoning	Score
Specificity	Names concrete test targets ("DomeGradient, IBLGradient, default lighting, component schemas") plus a specific tool ("iwsdk CLI") and fixture ("poke example"), listing multiple specific capabilities rather than vague actions.	3 / 3
Completeness	Clearly states what the skill does ("Test environment system ... against the poke example using the iwsdk CLI") but provides no "Use when..." clause or equivalent explicit trigger guidance, so the "when" is only implied.	2 / 3
Trigger Term Quality	Contains some relevant terms ("environment system", "default lighting", "component schemas") but leans heavily on domain jargon (DomeGradient, IBLGradient, iwsdk) and omits common natural variations a user might say.	2 / 3
Distinctiveness Conflict Risk	The niche is distinct and unlikely to misfire — references to iwsdk CLI, the poke example, and named gradient components make it clearly separable from unrelated skills.	3 / 3
	Total	10 / 12 Passed

Validation

93%

Warnings & errors only

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 15 / 16 Passed

Validation for skill structure

Criteria	Description	Result
frontmatter_unknown_keys	Unknown frontmatter key(s) found; consider removing or moving to metadata	Warning

	Total	15 / 16 Passed

Repository: facebook/immersive-web-sdk
Commit: 42af866

Reviewed: 6 days ago

Table of Contents

Discovery Implementation Validation

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.