Content
67%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 a well-structured, concise reference covering Core Web Vitals, profiling workflow, bundle/runtime analysis, and quick wins, with a real executable script and a clear measure-identify-fix-validate loop. Its main weakness is actionability: most optimization 'actions' are short hints rather than concrete commands or code.
Suggestions
Turn the 'Optimization Actions' and 'Quick Win Priorities' tables into concrete, runnable examples (e.g. the exact compression/caching config or a code-split import snippet) rather than short hint phrases.
Replace the vague 'When to Use' line with a concrete trigger list mirroring the description, or remove it to save tokens.
Add a concrete validation step to the 4-step workflow (e.g. re-run `scripts/lighthouse_audit.py <url>` and compare the performance score to the baseline) so the loop has a real feedback/retry checkpoint.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is table-driven and dense, does not over-explain concepts Claude already knows (it does not define Lighthouse or Core Web Vitals), and mostly earns its tokens; minor trims like the generic 'When to Use' line and the decorative emoji headers keep it just below the lean level-5 anchor. | 4 / 5 |
Actionability | It offers one fully executable command (the lighthouse_audit.py invocation, backed by a real script) and clear tool-selection tables, but most 'actions' ('Import specific modules', 'Dedupe, update versions', 'Enable compression', 'Code split') are high-level hints without specific commands or code, matching the 'some concrete guidance but incomplete; missing key details' anchor. | 3 / 5 |
Workflow Clarity | The 4-step process (BASELINE -> IDENTIFY -> FIX -> VALIDATE) is a clearly sequenced loop with an explicit validation step, matching 'clear sequence with most checkpoints present'; it stops short of 5 because validation is conceptual ('Confirm improvement') rather than a concrete feedback/retry loop with error recovery. | 4 / 5 |
Progressive Disclosure | Content is well-organized into clearly headed sections and the one bundle file (scripts/lighthouse_audit.py) is real and surfaced in a clearly signaled table at one level of depth; it is not 5 because all detailed reference tables are inlined rather than split into separate reference files for deeper material. | 4 / 5 |
Total | 15 / 20 Passed |