Content
71%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 compact, well-sectioned audit skill that keeps itself lean and correctly pushes code examples and framework guidance into references/rule.md, with explicit validation checkpoints. The main costs are redundancy — the required-field list is repeated nearly identically across Quick Reference, Fix, and Code Review — and a largely-educational Explain section that spends tokens on background Claude already has.
Suggestions
Consolidate the three near-duplicate required-property lists (Quick Reference, Fix, Code Review) into one canonical field list referenced by the other sections.
Trim the Explain section to one sentence of non-obvious value (e.g. that schema powers the local map pack and that NAP data must match on-page text) and drop the generic 'tells Google the essential details' framing.
Merge or clearly differentiate 'Check' and 'Code Review' — they describe the same inspection with different field lists — and add an explicit 'if validation fails, fix these fields and re-test' step to close the feedback loop.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is mostly efficient, but the required-property list is stated three times with variations (Quick Reference: 'name, address (PostalAddress), telephone'; Fix: 'streetAddress, addressLocality, addressRegion, postalCode, addressCountry'; Code Review: 'name, address.streetAddress, … telephone, url'), and the Explain section ('This data powers the Knowledge Panel… the local pack (map pack)… Google has to guess business details') covers background Claude largely already knows. This matches 'mostly efficient but includes some unnecessary explanation or could be tightened' — not anchor 2's level of padding, but short of anchor 4's trim efficiency. | 3 / 5 |
Actionability | Guidance is concrete and specific down to individual address sub-fields ('streetAddress, addressLocality, addressRegion, postalCode, addressCountry'), names the exact detection pattern ("JSON-LD script block with @type matching 'LocalBusiness' or a sub-type"), and gives a specific validation tool ("Google's Rich Results Test"), fitting 'mostly executable guidance; concrete code or commands with minor gaps'. It stops short of anchor 5's copy-paste-ready examples in the body itself — code examples are deferred to references/rule.md — which is acceptable for an instruction-style skill per the scoring notes, but the body still leaves the actual JSON-LD template one file away. | 4 / 5 |
Workflow Clarity | The Check → Fix → Explain → Code Review ordering presents a clear audit-then-remediate sequence, and validation checkpoints are explicit ("Validate with Google's Rich Results Test" in Check; "Validate with Google's Rich Results Test API" in Code Review), matching 'clear sequence with most checkpoints present'. It is below anchor 5 because there is no feedback loop (what to do when validation fails, e.g. which fields to re-inspect), and the overlap between 'Check' and 'Code Review' leaves the intended pass order implicit. | 4 / 5 |
Progressive Disclosure | The 45-line body is a well-organized overview that defers code examples and framework-specific guidance via an explicit, clearly signaled one-level-deep pointer ("For full implementation details, code examples, and framework-specific guidance, see `references/rule.md`") to a real bundle file (references/rule.md, 153 lines, containing exactly those materials with no chained references). This matches 'clear overview with well-signaled one-level-deep references; content appropriately split; easy navigation'. | 5 / 5 |
Total | 16 / 20 Passed |