Content
78%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.
An exceptionally actionable, information-dense review skill: it encodes non-obvious project rules with exact paths, APIs, and canonical fixes, and sequences review work around four recurring defect classes. Its weaknesses are structural — a monolithic ~150-line body with no bundle files, so material like the logging severity ruleset and PR hygiene guidance that belongs in one-level-deep reference files is inlined — plus minor prose that could be tightened.
Suggestions
Split the deep-dive material into one-level-deep bundle files (e.g., references/defect-classes.md, references/logging-rules.md, references/pr-hygiene.md) and keep SKILL.md as a compact overview that signals them explicitly, e.g., '**Logging severity gates**: See [references/logging-rules.md](references/logging-rules.md)'.
Trim the explanatory prose around the checklist items in sections A and 8 (e.g., the multi-paragraph Crashlytics/Datadog rationale) down to the rule plus a one-line reason, moving extended rationale into the reference files.
Add a short 'Review procedure' section that states the ordered end-to-end pass (defect classes first → checklist categories → test-coverage impact analysis → moved-code diff → output format), so the phases read as an explicit sequence rather than being implied by section order.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Nearly every line carries project-specific knowledge Claude cannot infer (e.g., 'safeCatching {} from core:common instead of runCatching {}', 'CMP only supports %N$s and %N$d', the Crashlytics/Datadog asymmetry rules). It does not explain general concepts, but at ~150 lines / 18KB some prose could be trimmed — the explanatory paragraphs in defect class A and section 8's rationale run longer than the checklist items need — so 'efficient with minor instances of over-explanation' (4) fits better than 5. | 4 / 5 |
Actionability | Guidance is fully concrete and executable: exact API mappings ('java.util.concurrent.locks.* -> kotlinx.coroutines.sync.Mutex'), exact file paths ('core/database/schemas/org.meshtastic.core.database.MeshtasticDatabase/<n>.json'), exact commands ('./gradlew :desktopApp:runRelease'), and canonical patterns with reference examples ('NotificationPrefsImpl.setGeofenceAlertOptIn'). As an instruction-only review skill the guidance is maximally actionable — specific examples cover the common cases, matching the 5 anchor; there are no gaps that would drop it to 4. | 5 / 5 |
Workflow Clarity | The review process is clearly sequenced: 'Recurring Defect Classes (check these first)' establishes priority, then eight checklist categories, then explicit output rules ('One problem per comment', 'Problems only'), plus impact-analysis and moved-code procedures. Checkpoints exist (verify migration test accompanies schema bump, check existing review threads before adding a finding, release smoke-test), but there is no single end-to-end procedure statement tying the phases into an ordered pass, leaving minor validation/sequencing gaps — a 4 rather than 5. | 4 / 5 |
Progressive Disclosure | The body is well-sectioned with headers, but no references/, scripts/, or assets/ bundle files exist — everything, including the lengthy logging/severity ruleset (section 8), the four defect-class deep dives, and Git/PR hygiene rules, is inlined in one ~150-line file. That matches 'some structure but content that should be separate is inline' (3). It is above 2 because headers and the 'check these first' framing make it navigable, and below 4 because substantial reference-worthy material (e.g., the ExpectedCondition/severity-gating rules, PR hygiene) is not split out into one-level-deep bundle files. | 3 / 5 |
Total | 16 / 20 Passed |