Content
77%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 well-structured skill body: clear sequencing with genuine validation checkpoints, and exemplary one-level-deep reference splitting. The weak spots are conciseness (justificatory prose in the Done section, step 4, and step 6 could be trimmed) and actionability, where several steps defer their executable detail entirely to references.
Suggestions
Tighten the Done paragraph to a plain outcome statement (e.g. "Done = a summary marking every affected route Pass/Fail/Skip with a reason per Skip, or the preflight blocker that stopped testing") and drop the meta-explanation of what the condition exists to prevent.
Trim step 4's rationale ("prose mentions in docs, examples, and troubleshooting are unreliable and false-positive-prone") to a one-line rule — "trust package.json scripts and .env files only; do not grep docs for ports" — moving the reasoning to route-and-report.md if it must be kept.
Inline one concrete example of step 3's mapping (e.g. "src/pages/about.tsx → /about") or a one-line pointer to the mapping table's location in route-and-report.md, so the core workflow step is actionable without opening the reference.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is operational throughout with real commands and no teaching of known concepts, but several passages carry justificatory prose that could be tightened: the Done paragraph ("Reaching neither, or dropping a route from the summary because nobody could reach it, is the failure this done condition exists to prevent"), step 4's explanation of why grepping docs is unreliable, and the densely hedged sentences in step 6's visibility rules. This is "mostly efficient but could be tightened" rather than "efficient with only minor trims". | 3 / 5 |
Actionability | Key steps carry exact, executable commands — `gh pr view [number] --json files -q '.files[].path'`, `git diff --name-only main...HEAD`, `scripts/resolve-port.sh`, `http://localhost:<port>` — but others remain abstract ("Map changed files to routes", "exercise the critical interactions") with the executable detail deferred to reference files. It is not 5 because the body alone is not copy-paste complete for every step; not 3 because the core steps are concretely specified. | 4 / 5 |
Workflow Clarity | Ten numbered steps in a clear sequence with explicit validation checkpoints: verify the dev server before spending the visibility question, confirm the root is served before iterating, driver-fallback rules before testing begins, and failure handling (capture error state + exact repro, then fix-or-skip). The Done condition enumerates outcome states including skip reasons. This is a non-destructive skill, so the validation cap does not apply; the full anchor — explicit validation, error-recovery loops, outcome checklist — is met. | 5 / 5 |
Progressive Disclosure | The body is an overview that splits execution detail across three references, each well-signaled with what it contains and when to read it ("Read references/route-and-report.md before step 3 … It carries the route-mapping patterns, the port and server commands, the per-page checks…"). All referenced files exist and are one level deep — they reference only scripts/resolve-port.sh, never further .md files — and the port-resolution script is bundled. Navigation is easy; this matches the top anchor. | 5 / 5 |
Total | 17 / 20 Passed |