Content
96%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 model of lean, high-density skill authoring: the body is pure routing (what to do, in what order, with which exact command or tool, and what to do when it fails) and delegates all depth to per-topic files via clearly signaled, anchor-linked references. The one material defect is bundle completeness: every file the body routes to is absent from the evaluated bundle, which leaves the otherwise excellent navigation unresolvable.
Suggestions
Ship (or restore) the referenced bundle files next to SKILL.md — WORKFLOW.md, RUNTIME.md, BROWSER.md, RECORDING.md, EMBEDDING.md, and the current-host platform guide — so the body's routing table and failure-map deep links resolve; without them every 'Read when needed' pointer is a dead link.
If this bundle is intentionally host-filtered, state that in the body: the current note only covers platform files ('Other platform files may be absent from a host-filtered installation'), but WORKFLOW.md and RUNTIME.md are core dependencies and their absence is unexplained.
Consider one short inline example of a minimal observe→act→verify exchange (e.g., a two-line get_window_state → click(element_token) sequence) so the mainline loop is executable even when WORKFLOW.md is unavailable in a filtered installation.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The ~76-line body is entirely operational with zero padding: a one-line north star ('Operate one exact target, observe its state, act once, and verify the user's postcondition'), a goal→tool routing table, seven dense rules, and a symptom→next-step failure map. It explains nothing Claude already knows, matching the lean/every-token-earns-its-place anchor rather than the 4 anchor's 'minor instances of over-explanation'. | 5 / 5 |
Actionability | For an instruction-only skill, guidance is concrete throughout: exact commands ('cua-driver --version, status, doctor, describe <tool>'), argument-shaped tool calls ('get_window_state({pid, window_id})', 'verify_state({pid, window_id, expect})', 'target:{kind:"desktop",display_id:"primary"}'), and explicit sequences ('start_recording → actions → stop_recording'). Specific commands cover the common cases across observe, act, verify, desktop, browser, and recording, satisfying the fully-executable anchor; it sits above the 4 anchor because no mainline step is left at the hint level. | 5 / 5 |
Workflow Clarity | The sequence (observe → act once → verify → stop after proof) is stated in the summary, Rules #2, and the Act table's row order, with explicit validation checkpoints ('verify_state({pid, window_id, expect}) or a fresh snapshot', 'effect:"unverifiable" and a successful exit are not task success'). Feedback loops are present in the Failure map (e.g., 'Text did not visibly change → Reobserve before retrying') and the history section is a fully-branched decision flow, matching the anchor for clear sequence, explicit validation, and error-recovery loops. | 5 / 5 |
Progressive Disclosure | The on-paper structure is anchor-5 quality: a lean overview delegating all detail one level deep, a 'Read when needed' column, deep links to specific anchors (e.g., 'RUNTIME.md#preflight-and-transport', 'WORKFLOW.md#act-once'), and an annotated References section with 'Load on demand; do not reabsorb these into this file'. However, none of the eight referenced files (WORKFLOW.md, RUNTIME.md, MACOS.md, WINDOWS.md, LINUX.md, BROWSER.md, RECORDING.md, EMBEDDING.md) exist in the provided bundle — there is no references/ directory and no such files beside SKILL.md — so every navigation target dangles in practice. | 4 / 5 |
Total | 19 / 20 Passed |