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 strong instruction-heavy skill body: every section carries specific, non-obvious design guidance with explicit validation stages, and the single bundle reference is well-signaled with clear when-to-read conditions. The main room for improvement is trimming the cross-section repetition and adding one worked example to make the guidance copy-paste concrete.
Suggestions
Consolidate the model-provider advice: the "Installing a provider plugin by reflex" common-mistake bullet and the verification triples in "Before you write code", "Verify before you call it done", and "Related skills" repeat points already made in "Models" — a one-line back-reference ("see 'Models' above") per section would trim tokens without losing guidance.
Add one minimal worked example of the core pattern — e.g., a two-agent greeting → intake → resolution handoff sketch or a mutating tool with its paired guard request — so the mutation-semantics and handoff rules have a concrete shape to follow rather than principle-only guidance.
Join the pre-code checklist, build, test, and ship stages into one explicit end-to-end sequence (with the validate → fix → retry loop spelled out for the failing-test pair) so the workflow reads as a single coherent process rather than distributed sections.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is dense with non-obvious domain guidance and explains nothing Claude already knows, but there is minor redundancy: Inference advice appears in both "Models" and the "Common mistakes" bullet "Installing a provider plugin by reflex", and verification guidance is repeated across "Before you write code", "Verify before you call it done", and "Related skills". Trimming these overlaps would reach the lean top anchor; it is noticeably above the mostly-efficient midpoint, so not a 3. | 4 / 5 |
Actionability | Concrete, executable guidance throughout: named env vars ("LIVEKIT_URL, LIVEKIT_API_KEY, LIVEKIT_API_SECRET, usually in .env"), precise mutation rules ("omission preserves; missing, empty, unknown, and cleared are four different things; collections get application-issued ids"), and a concrete test structure (failing complete-path test paired with the first refusing guard). It stops short of the copy-paste-ready top anchor — no worked example of a handoff or tool shape — which is a minor gap given API specifics are deliberately delegated to reading-livekit-docs. | 4 / 5 |
Workflow Clarity | "Before you write code" is a clear numbered 4-step sequence (load docs, confirm connection, decide structure, plan verification), and validation checkpoints are explicit: drive a failing complete-path test first, "keep that pair green while you add everything else", then per-stage verification (debugging while building, tests before done, simulations before shipping). Not a 5 because the end-to-end sequence is distributed across separate sections rather than one coherent workflow with error-recovery loops, and "Keep that pair green" is the only implicit validate-fix-retry step. | 4 / 5 |
Progressive Disclosure | The SKILL.md is an overview with a single, well-signaled one-level-deep reference — "The full treatment — including closing, output ownership, and how text and audio input take different hook paths — is in references/state-and-effects.md. Read it before building anything that books, edits, confirms, or ends calls" — and that file exists with no nested references. The "Related skills" section maps the rest of the ecosystem, making navigation easy. | 5 / 5 |
Total | 17 / 20 Passed |