Content
82%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, well-sectioned instruction skill: every workflow comes with exact commands, explicit fallbacks, and a clear docs-vs-source-vs-templates reuse policy. Its main costs are duplicated passages about the headless/app-agent tools and one peripheral section (visual docs blocks) that inflates length without serving the core lookup task.
Suggestions
Merge the two duplicated passages about headless `pnpm agent` / built-in app agent tool availability into one statement in the How section, and drop the second 'From a generated app directory' framing to remove the repeated reader listings.
Move the 'Authoring visual docs blocks' section into a separate reference file (or the framework's own docs slug), since it is a rendering-style guide unrelated to the docs/source lookup workflow.
Make the decision flow explicit as a short ordered list (framework-search → focused reader → corpus install fallback → direct rg fallback), so the sequence currently spread across prose sections is scannable.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is dense and assumes competence — it jumps straight to commands and file paths with no library-primer padding, and every section carries skill-specific knowledge (version-matched sourcing, corpus install, override ladder). Not a 5 due to real redundancy: tool availability is stated twice ("The same tool is available in the headless `pnpm agent` loop and every built-in app agent" vs. "The headless `pnpm agent` loop and built-in app agent also expose... tools") and "From a generated app directory" appears twice with overlapping reader listings. | 4 / 5 |
Actionability | Fully executable, copy-paste-ready commands throughout: `pnpm action framework-search --pattern "defineAction"`, `docs-search --slug <slug>`, the corpus install command with the version pin, `rg -n ... node_modules/...`, and a `cp` of a named template file to a named destination. The commands cover the common cases (docs lookup, source grep, template reuse, fallback when the action runner is missing), matching the top anchor. | 5 / 5 |
Workflow Clarity | There is a clear decision sequence — unified `framework-search` first, then focused readers, with explicit fallback branches ("If source-search reports that template source is unavailable, install the matching corpus package...", "If the action runner is unavailable, search the package directly") and an instruction to refine rather than accept truncated results. Not a 5 because the sequencing is implicit across sections rather than laid out as an ordered flow, and the section ordering interleaves fallback and primary paths; not a 3 because checkpoints and error-recovery branches are explicitly present. | 4 / 5 |
Progressive Disclosure | No bundle files exist (references/, scripts/, assets/ are absent), and the body is a self-contained, well-sectioned ~150-line document with clear headers (Rule, Why, How, Useful Slugs, Don't) — good structure with appropriate placement of most content. Not a 5 because some content is inline that could plausibly live in reference files (the "Authoring visual docs blocks" section and the "Useful Slugs" table are peripheral to the lookup workflow), and the repeated reader/tool listings blur the navigation slightly. | 4 / 5 |
Total | 17 / 20 Passed |