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, highly actionable body: every primitive has executable code, decision criteria are explicit, and the writing stays lean and project-specific. The main weaknesses are the absence of any progressive-disclosure structure (everything lives in one ~200-line SKILL.md with no reference files) and minor redundancy between the naming-convention and marker-decision sections.
Suggestions
Move stable reference material — the naming-conventions table, the dev-mode warnings list, and the architecture/file map — into a references/ file (e.g. references/conventions.md), keeping SKILL.md as a lean overview with clearly signaled links, to improve progressive disclosure.
Deduplicate the marker-decision guidance: the 'Don't' bullets under naming conventions and the 'Should I add a `__SLOT__` marker at all?' section cover overlapping ground; consolidate into one place.
Add a short verification step to the checklist (e.g. render the compound with duplicate and wrapped children in dev mode and confirm no warnings fire) to close the workflow-clarity validation gap.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is dense with project-specific, non-obvious conventions (SSR constraints, single-match semantics, lint-rule workaround, marker-copy wrapping) and avoids explaining generic React concepts, matching the score-4 anchor of efficient with minor trimmable instances. It falls short of 5 because of slight redundancy — the 'Don't' bullets under naming conventions restate points from the 'Should I add a `__SLOT__` marker at all?' section, and the old-vs-new `asSlot` comparison adds length — but it is nowhere near the over-explanation of the score-3 example. | 4 / 5 |
Actionability | Every section ships copy-paste-ready TypeScript/TSX: a complete `useSlots` consumer example, both matcher styles, the `__SLOT__` marker assignment with typed variants, a full `asSlot` wrapper example with usage, and an `isSlot` snippet, covering the common cases per the score-5 anchor. It exceeds the score-4 anchor because no example is pseudocode or missing key details — even the import paths are given. | 5 / 5 |
Workflow Clarity | The 'Quick checklist for a new compound component' provides a clear 5-step sequence, and decision guidance (when slots are/aren't the right tool, when to add a marker) plus the `grep "isSlot.*ComponentName"` check act as checkpoints, matching the score-4 anchor. It is not 5 because there are no explicit validation/feedback steps for verifying the built component works (e.g. confirming the warning-free dev behavior the skill itself documents), though this is a convention skill, not a destructive/batch operation, so no cap applies. | 4 / 5 |
Progressive Disclosure | The body has good section structure (TL;DR, Architecture, per-topic sections, checklist) but is a single ~200-line file with no bundle files and no one-level-deep references, and content that could be split out (naming-convention tables, dev-mode warnings, limitations) is inlined — matching the score-3 anchor of some structure with content that could be separate left inline. It is above 2 because sections are well-organized and navigable, and below 4 because nothing is offloaded to reference files despite the length exceeding the simple-skill threshold. | 3 / 5 |
Total | 16 / 20 Passed |