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 operational skill body: terse mental-model tables, a non-negotiable rules section, and best-in-class progressive disclosure through a load-condition reference table and a completion gate with validation checks. The main weaknesses are repetition of version-gated guidance across three sections, how-to details that are always deferred to references, and a completion gate without an explicit fix-and-retry loop.
Suggestions
Consolidate version-sensitive claims (3.1.6 baseline, 4.0.0-alpha.10, Node floors) into the single version-boundary blockquote and reference it from the operating procedure and mental-model table instead of restating them, reducing drift-prone repetition.
Add one-line fix-and-revalidate guidance to the Completion gate (e.g., 'if a check fails, fix and re-run before proceeding') or signpost references/troubleshooting.md as the recovery path.
Inline a minimal normalize_path / jsonScript usage example next to the rules that mandate them, so the most common cases are executable without opening references/filters.md.
Tighten the Behavioral evaluations paragraph — it currently spends ~6 lines on meta-commentary that could be reduced to two sentences plus the scenarios.json pointer.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is dense and operational (tables, priority lists, terse rules) and assumes Claude knows what Nunjucks/static sites are, but version-gated information ("Eleventy `3.1.6` is the stable production baseline", "Build Awesome `4.0.0-alpha.10`", "Node `>=22.15`") recurs across the version-boundary blockquote, operating procedure step 2, and the mental-model table instead of living in one place. The 'Behavioral evaluations' paragraph is also trimmable. Not score 3 — the padding is minor and localized; not score 5 — the repetition is real and the dated version claims add maintenance burden. | 4 / 5 |
Actionability | Concrete guidance dominates: config search order (".eleventy.js, eleventy.config.js, eleventy.config.mjs, eleventy.config.cjs"), the data-cascade priority list, the autoescape truth table, named filters ("use `jsonScript` or `jsonCompact`", "Ship `normalize_path`"), and copy-paste layout snippets. Not score 5 because several in-body rules defer their how-to entirely to references (e.g., normalize_path and jsonScript usage, CSP header examples) without a minimal inline example, leaving minor gaps for the most common cases. | 4 / 5 |
Workflow Clarity | The three-step "Operating procedure" plus the five-item "Completion gate" checklist give a clear sequence with explicit validation checkpoints ("The relevant Eleventy build, dev-server smoke check, or project test command passes", "Rendered output or generated HTML was inspected"). Not score 5 because there is no explicit fix-and-revalidate feedback loop — the gate says what to verify but not what to do when a check fails (error-recovery guidance lives in references/troubleshooting.md rather than being signposted from the gate). | 4 / 5 |
Progressive Disclosure | A clear overview with a "Reference files" table giving per-file load conditions for all 11 references — all of which exist on disk, one level deep — plus an intentional pointer to assets/evals/scenarios.json for evaluation-only use. Core defaults stay inline, details are split out, and the operating procedure explicitly says "Avoid loading every reference unless the change is large." This matches the anchor-5 example's structure exactly. | 5 / 5 |
Total | 17 / 20 Passed |