Content
75%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.
A tight, well-structured operational skill: executable probe code, a disciplined interaction loop with capture/verify steps, and thoughtful guardrails against selector staleness and privacy leaks. Its weaknesses are mild — a small redundancy with the description, no failure path after verification, and a body that could shed ~40 lines by moving the harness code into bundle files.
Suggestions
Add a failure branch to the Interaction Loop, e.g. "If the expected state change did not occur, re-capture and diff against the before snapshot before retrying or reporting."
Trim the "What It Is Used For" section, which largely repeats the frontmatter description, or fold its one new item (before/after evidence for verify-this) into the opening paragraph.
Consider moving the two full harness code blocks into a scripts/ or references/ file and keeping only a one-line invocation in SKILL.md to reduce always-loaded tokens.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is lean — terse bullets, two short code probes, no explanations of concepts Claude already knows (no "what is CDP" primer). Minor trimmable fat remains: the "What It Is Used For" list partially restates the frontmatter description's use cases. Not score 5 because of that redundancy; not score 3 because almost every token carries operational guidance. | 4 / 5 |
Actionability | Two near-executable Playwright probes (web and CDP) plus concrete steps ("Select the correct page by stable app markers, not by tab order alone", "Prefer accessibility roles, labels, and stable data-* selectors") give directly usable guidance. Not score 5 because the code contains repo-dependent placeholders ("<port>", "<app-root-selector>") and, appropriately flagged, is not literally copy-paste ready; not score 3 because the placeholders are explicitly explained and the examples cover the common web and Electron cases. | 4 / 5 |
Workflow Clarity | The Setup Pattern (6 ordered steps) and Interaction Loop (snapshot → one action → snapshot → verify expected state) are clearly sequenced, and page selection has an error-recovery fallback ("If no page matches, list available page titles and URLs instead of guessing" plus the thrown error in code). Not score 5 because the interaction loop's "Verify the expected state change" step has no explicit failure path (what to do when verification fails); not score 3 because checkpoints are largely explicit and the operations are not destructive or batch. | 4 / 5 |
Progressive Disclosure | No bundle files exist, and the self-contained body is well organized into clearly labeled sections (Setup Pattern, Generic Web Harness, Generic CDP Harness, Interaction Loop, CDP Capabilities, Page Selection, Guardrails) with no nested or buried references. Not score 5 because the body runs ~105 lines — past the point where the short self-contained exception applies — and the two harness probes or the CDP Capabilities list could live in a scripts/ or references/ file; not score 3 because everything inline is compact, appropriately placed, and easy to navigate. | 4 / 5 |
Total | 16 / 20 Passed |