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 highly actionable, competent body: executable code, exact commands and error strings, and a well-sequenced workflow with a create-time feedback loop. Weaknesses are a dangling `rules/<rule-name>.md` reference with no corresponding bundle file, fully inlined reference-grade material, some rule repetition, and a missing render-time verification step despite render failures being called out as a primary failure mode.
Suggestions
Ship the referenced `rules/workflow.md` file (or remove the "## Rules" section): the body tells the reader to "Read `rules/<rule-name>.md` for details" but no `rules/` directory exists in the bundle, so the only progressive-disclosure pointer is broken.
Add a post-create verification step to the workflow — e.g. open the dashboard URL and check for render-time errors, with a fix-and-retry loop mirroring the existing KopaiValidationError recovery — since the skill itself warns that trees can pass `createDashboard` but fail at render.
Consolidate the repeated guidance: state the raw-query rule and the null-for-unused-props rule once each (in "Two rules") and reference them elsewhere in one line, and deduplicate the identical CLI-error fallback string used in both `!` blocks.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body assumes Claude's competence (no explanations of OTel, dashboards, or TypeScript) and is dense with Kopai-specific gotchas, but the null-prop rule is stated three times ("Two rules" #2, workflow step 3, the Components sizing note), the raw-query rule is repeated across four sections, and the identical CLI-error fallback string is duplicated in both `!` blocks. Not 5: the repetition means not every token earns its place; not 3: there is no over-explanation of known concepts, only intentional-but-trimmable rule reiteration. | 4 / 5 |
Actionability | A complete, copy-paste-ready `create-cpu-dashboard.mts` script, exact run commands (`npx tsx dashboard.mts`, `npm i @kopai/sdk`), per-tile executable `kq` query snippets in the components table, the exact render-time error strings to expect, and a concrete CLI fallback command. Not 4: the guidance is fully executable and the examples cover the common cases for every tile type. | 5 / 5 |
Workflow Clarity | Five clearly sequenced steps with an explicit feedback loop ("On a KopaiValidationError/KopaiError, re-run discoverMetrics() to recheck names and types, fix the tree, and retry") plus try/catch and stdout-id guidance. Not 5: the doc itself identifies render-time failure as a key failure mode ("passes createDashboard but fails at render"), yet step 5 only opens the view URL — there is no checkpoint to verify the dashboard renders or a recovery loop for render-time errors, a minor validation gap. | 4 / 5 |
Progressive Disclosure | Sections are well-organized and the `!` runtime blocks keep the backend schema out of context, but the body's only file reference — "Read `rules/<rule-name>.md` for details" for the `workflow` rule — is dangling: no `rules/` directory (nor references/, scripts/, assets/) exists in the bundle, so a reader following it finds nothing. Additionally, the full component/prop table and schema details are inlined in SKILL.md rather than split into a reference file. Not 4: a broken reference and wholesale inlining exceed "minor organization gaps"; not 2: the in-document structure itself is clear and navigable. | 3 / 5 |
Total | 16 / 20 Passed |