Content
50%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a well-structured domain guide for wsh visual feedback that covers overlays and panels comprehensively with good design guidance and practical patterns. Its main weaknesses are: examples use a descriptive pseudocode notation rather than executable commands (actionability gap), the document is somewhat long for a single file with no supporting references, and it lacks explicit validation/verification steps in its workflows. The content is genuinely useful and domain-specific, but could be tighter and more actionable.
Suggestions
Add explicit validation steps to workflows — e.g., after creating an overlay, read the screen to verify it rendered at the expected position, and include a concrete example of this verify-then-adjust loop.
Make examples more actionable by showing actual tool calls or curl commands alongside the pseudocode notation, or at minimum clarify the mapping between the descriptive syntax and the actual wsh_* tool parameters.
Consider splitting composition patterns and pitfalls into a separate reference file (e.g., PATTERNS.md) to reduce the main skill's length and improve progressive disclosure.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is fairly long (~300 lines) and includes some content Claude could infer (e.g., explaining what x/y coordinates mean, that (0,0) is top-left). However, most content is domain-specific guidance about wsh overlays/panels that Claude wouldn't inherently know, and the design patterns are genuinely useful. Some sections like 'Visual Structure: Borders and Padding' could be tightened since box-drawing is a well-known technique. | 2 / 3 |
Actionability | The skill provides many concrete examples with JSON span structures and pseudocode-like descriptions of operations (e.g., 'create panel (bottom, height: 2)'), but these are not fully executable — they use a descriptive notation rather than actual API calls or tool invocations. The execution context preamble explicitly defers API details elsewhere, which means the skill intentionally avoids copy-paste-ready commands, leaving a gap in actionability. | 2 / 3 |
Workflow Clarity | The skill covers lifecycle management (create → update → delete), cleanup patterns, and pitfalls like stale elements and coordinate drift. However, there are no explicit validation checkpoints or feedback loops — for example, no step saying 'verify the overlay rendered correctly by reading the screen' or 'check screen dimensions before positioning.' The lifecycle section mentions tracking IDs but doesn't provide a clear sequential workflow with verification steps. | 2 / 3 |
Progressive Disclosure | The content is well-organized with clear section headers and a logical progression from concepts → design patterns → composition → pitfalls. However, it's a monolithic document with no references to supporting files. Given its length (~300 lines), some sections like composition patterns or the full pitfalls guide could be split into separate reference files. The execution context preamble references 'skills/core/SKILL.md' for API details, which is good progressive disclosure for the API layer. | 2 / 3 |
Total | 8 / 12 Passed |