Content
85%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 efficiently written, highly actionable routing body with an explicit observe→act→verify loop, strict verification discipline, and a symptom-based failure map — the body itself is near-ideal for a multi-file skill. Its one substantive defect is that the entire load-on-demand reference layer it depends on is absent from the bundle as shipped, breaking the progressive-disclosure contract.
Suggestions
Ship the referenced files (at minimum WORKFLOW.md and RUNTIME.md, plus the platform guide for the host) alongside SKILL.md so the 'Load on demand' pointers resolve, or inline a minimal quick-start for the core observe→act→verify loop so the body is self-sufficient when they are host-filtered out.
Add one or two complete example invocations (e.g., a full `click` call with its element_token payload and window target) to lift actionability from routing-level to copy-paste-ready.
State explicitly in the References section which files are guaranteed present vs. host-filtered (currently only the platform files carry that caveat), so absence can be distinguished from a broken reference.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is lean and operationally dense: every line carries tool names, parameters, or a rule ('`get_window_state({pid, window_id})`', 'a fresh snapshot replaces prior element handles'). No space is spent explaining concepts Claude already knows, and the References section explicitly instructs 'Load on demand; do not reabsorb these into this file.' | 5 / 5 |
Actionability | Concrete, executable guidance dominates: exact CLI commands ('cua-driver --version', 'status', 'doctor', 'describe <tool>'), exact tool names with parameter shapes ('`get_window_state({pid, window_id})`', '`target:{kind:"desktop",display_id:"primary"}`'), and a goal→tool routing table. It falls short of anchor 5 because full invocation syntax and argument details for most actions (click, type_text, verify_state's expect shape) are deferred to the referenced files rather than shown or exemplified inline; it is clearly above anchor 3 since what is present is real, not pseudocode. | 4 / 5 |
Workflow Clarity | The core loop is stated up front ('Operate one exact target, observe its state, act once, and verify the user's postcondition') and reinforced by the ordered Act table (find app → observe → act → verify → finish) and Rule 2 ('Observe before input and verify after it'). Validation checkpoints are explicit and strict — '`effect:"unverifiable"` and a successful exit are not task success', `verify_state({pid, window_id, expect})` — and the Failure map closes the loop with symptom→recovery-step feedback paths. | 5 / 5 |
Progressive Disclosure | The structure itself is anchor-5 quality: a concise overview, a well-signaled one-level-deep reference list, and anchored deep links (RUNTIME.md#preflight-and-transport, LINUX.md#capture-recovery). However, per the bundle-structure guideline, none of the referenced files (WORKFLOW.md, RUNTIME.md, MACOS.md, WINDOWS.md, LINUX.md, BROWSER.md, RECORDING.md, EMBEDDING.md) exist in this bundle — there are no references/, scripts/, or assets/ directories at all — so every load-on-demand pointer is a dead end and navigation fails in practice. The body's own note that 'Other platform files may be absent from a host-filtered installation' acknowledges some absence, but the core files (WORKFLOW.md, RUNTIME.md) are unconditionally referenced and still missing, which drops this below anchor 4 ('references mostly clear' with only minor gaps). | 3 / 5 |
Total | 17 / 20 Passed |