Content
57%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.
The body is well organized with a clean section structure and an exemplary progressive-disclosure pointer to a real references/rule.md file. However, it reads as a templated checklist: guidance stays at the level of 'scan the page' and 'update the link' without concrete scanning commands or an explicit post-fix verification step, and the intro plus Quick Reference add duplication rather than new information.
Suggestions
Add concrete, executable scanning guidance to the Check section — e.g., extract external hrefs from the rendered HTML and probe each with `curl -sI -o /dev/null -w '%{http_code}' <url>`, treating 4xx/5xx (and long-held 301s to expired domains) as broken.
Insert an explicit verification step in the Fix workflow (re-check the updated link's response, confirm the rendered HTML no longer contains the dead URL, re-crawl a representative page set after deployment) so the batch/destructive operation has a feedback loop.
Trim the generic intro sentence and merge the Quick Reference bullets into Check/Fix to remove duplication, or differentiate them (e.g., Quick Reference as a one-line summary only).
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body opens with an explanation Claude already knows ("Broken links provide a poor user experience and can signal to search engines that your content is outdated") and the Quick Reference bullets ("Regularly scan for external links returning 4xx or 5xx", "Update broken links to the new correct URL or remove them") substantially duplicate the Check and Fix sections. This matches anchor 3 — mostly efficient but includes some unnecessary explanation and could be tightened — rather than 4, whose 'minor instances of over-explanation' would not cover both a padded intro and a duplicated section. | 3 / 5 |
Actionability | There is some concrete direction — check for 4xx/5xx error codes, "Verify the rendered HTML and HTTP response rather than relying only on source files", update or remove the link — but no executable specifics: no command or tool for scanning links (e.g., curl -I per URL, a link checker, or a crawler), no threshold for what counts as broken, and no example of how to flag the offending route or template. This lands on anchor 3 ('some concrete guidance but incomplete') rather than 4, which requires mostly executable guidance; note the skill is instruction-only, so the absence of code itself is not the penalty. | 3 / 5 |
Workflow Clarity | A rough sequence is present (Quick Reference → Check → Fix → Explain → Code Review, i.e., scan → update/remove → explain → review), but there is no explicit validation checkpoint after fixing, and the Code Review section only asks Claude to "describe how to verify the final page output" rather than giving a verification loop. Since scanning a page's external links is a batch operation and removing links is destructive, the rubric's cap applies: missing validation steps cap this at 3 regardless of the skill's simplicity. | 3 / 5 |
Progressive Disclosure | The body is a short, well-sectioned overview (Quick Reference, Check, Fix, Explain, Code Review) with a clearly signaled one-level-deep pointer — "For full implementation details, code examples, and framework-specific guidance, see `references/rule.md`" — and references/rule.md exists and contains that deeper material (code example, why-it-matters, exceptions, verification steps). This matches the 5 anchor: clear overview, well-signaled reference, easy navigation with no nesting. | 5 / 5 |
Total | 14 / 20 Passed |