Content
88%Weight 40%Scale 1-5Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
An efficient, highly actionable skill body: concrete tool parameter shapes, a screenshot budget constraint, a sequenced workflow with error-recovery loops, and hard validation gates. The two minor gaps are the absence of a complete evaluate_script example and an external config reference that cannot be verified in the bundle.
Suggestions
Include one complete, copy-paste-ready evaluate_script call (e.g. the exact {function: '() => !!document.querySelector(...)'} payload) so the arrow-function-string convention is unambiguous.
Clarify where insightSetId comes from in the performance trace flow (e.g. the return value of performance_start_trace) to make the perf-trace steps fully executable.
Verify the .opencastle/stack/testing-config.md path exists in the target project (or mark it as project-provided) so the lone external reference is not a dead pointer.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is lean and operational throughout — "Screenshots are expensive. **MAX 3 per session**, reserved for failures" — with zero background on what Chrome DevTools or MCP is, and no padded sections. Every line teaches something Claude would not already know (uid-not-selector semantics, screenshot budget, wait_for failure diagnosis), matching the 'every token earns its place' anchor; it is not 4 because no section reads as over-explanation. | 5 / 5 |
Actionability | Tool calls come with concrete parameter shapes ("`click` and `type` take a `uid` from a prior snapshot, not a CSS selector", "`evaluate_script` — `{ function: '() => ...' }` (an arrow function *string*)"), plus named assertion patterns. It falls short of the fully copy-paste-ready anchor: there is no complete example `evaluate_script` invocation, and the perf-trace flow references `insightSetId` without stating where it comes from — minor gaps rather than vague guidance. | 4 / 5 |
Workflow Clarity | The workflow is a clearly sequenced chain ("Navigate → `wait_for` anchor text → assert via `evaluate_script` → ... → `list_console_messages`") with an explicit error-recovery feedback loop ("any error: fix source, rebuild, reload, restart from navigate") and hard validation gates ("Every test must pass before writing the updated `result.json`. Do not stop on partial green"), plus a troubleshooting heuristic for wait_for timeouts. This matches the anchor requiring explicit validation steps and feedback loops; no destructive/batch cap applies. | 5 / 5 |
Progressive Disclosure | The skill is under 50 lines with no bundle files and well-organized sections, which would qualify for the top anchor — but the single referenced path, ".opencastle/stack/testing-config.md", does not exist in this tree, leaving the one external pointer unverifiable. That is a minor organization gap versus the 'well-signaled one-level-deep references' anchor rather than a structural problem. | 4 / 5 |
Total | 18 / 20 Passed |