Content
78%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 lean, well-structured rules skill with no wasted tokens and sound architectural principles (progressive enhancement, HTTP-post fallbacks, server as source of truth). Its weakness is actionability: the rules are stated as principles without a single concrete example of an htmx attribute pattern, partial endpoint, or filter composition, leaving the reader to translate each rule into code unaided.
Suggestions
Add one short concrete example per core rule — e.g., an `hx-get="/partials/items" hx-include="[name='q']" hx-trigger="keyup changed delay:300ms"` snippet showing a filter control that composes with existing state.
Show what a partial endpoint returning 'meaningful HTML on its own' looks like (a minimal templ block or route signature), since that rule is currently the most open to interpretation.
Make the filter-state rule checkable: replace 'preserve the active state users would expect' with a specific test such as 'after a partial update, active filter values must round-trip in the URL or the hx-include scope'.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Every line is a directive with no concept explanations or padding — 'Server-rendered HTML is the product; htmx enhances it, it does not replace it' assumes the reader's competence and earns its tokens. Nothing explains what htmx or templ is. | 5 / 5 |
Actionability | The body names concrete attributes ('Prefer simple `hx-get` and `hx-include`') and gives one hard rule ('must still work as normal HTTP posts'), but there is no example of applying them — no attribute pattern for a filter control, no example partial endpoint, and 'preserve the active state users would expect' is abstract. For an instruction-only skill, the guidance is specific in places but missing the key application details. | 3 / 5 |
Workflow Clarity | As a short rules-based skill it needs no multi-step sequence, and it is well organized across 'When to Use', 'HTMX Rules', and 'Interaction Rules'. 'Toggle actions must visibly reflect the resulting server state' functions as a checkpoint, but forms that mutate system state get no explicit verification step, and 'active state users would expect' leaves the filter check implicit. | 4 / 5 |
Progressive Disclosure | The skill is under 50 lines with no bundle files (no references/, scripts/, or assets/ exist) and nothing that warrants external material. Its three well-organized sections are the appropriate structure for content of this size, matching the simple-skill exception. | 5 / 5 |
Total | 17 / 20 Passed |