Content
50%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-structured and appropriately points to references/rule.md for implementation details, but its core guidance is abstract: no validator, command, or code example is named in the Check/Fix steps, and there is no explicit post-fix re-validation checkpoint. It reads as an outline of a workflow rather than executable instructions.
Suggestions
Name concrete validation tooling in the Check section (e.g., the W3C/Nu HTML validator, `validator.nu`, or browser devtools) so "Validate the HTML structure" becomes an executable step.
Include a minimal bad-vs-good HTML snippet in the Fix section, or point directly to the code example in references/rule.md, so the fix guidance is concrete rather than descriptive.
Add an explicit re-validation checkpoint after Fix (re-run the validator against the rendered page output and only report success when it passes) to close the workflow's feedback loop.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is short and mostly lean, but the intro sentence ("Malformed HTML can cause rendering issues across browsers and may prevent search engine crawlers from accurately parsing and indexing your content") explains impact Claude already knows, and the "Quick Reference" bullets substantially restate the Check and Fix sections. Mostly efficient with some unnecessary explanation and tightening opportunities, matching anchor 3 rather than anchor 4's "minor instances". | 3 / 5 |
Actionability | "Validate the HTML structure of the page to identify any unclosed tags" names no validator, tool, or command, and "Correct the malformed HTML by properly closing tags" is a high-level hint with no example of what to change. The body provides minimal concrete guidance with missing specific execution steps, matching anchor 2; it does not reach anchor 3 because no partially complete concrete mechanism (tool, command, or example) appears in the body itself. | 2 / 5 |
Workflow Clarity | A recognizable sequence exists (Quick Reference -> Check -> Fix -> Explain -> Code Review), but validation is only implicit ("describe how to verify the final page output") with no explicit re-validation checkpoint or feedback loop after fixing. Steps are listed with validation gaps, matching anchor 3; it is above anchor 2 because the sequence is coherent and reasonably defined, and below anchor 4 because checkpoints are missing rather than minor. | 3 / 5 |
Progressive Disclosure | The body is a short (~35 line) overview with clear sections and a well-signaled, one-level-deep pointer ("For full implementation details, code examples, and framework-specific guidance, see references/rule.md") to a file that exists and contains exactly those details plus a code example. Clean overview/detail split with easy navigation, matching anchor 5. | 5 / 5 |
Total | 13 / 20 Passed |