CtrlK
BlogDocsLog inGet started
Tessl Logo

code-review

Review a Meshtastic-Android change against KMP architecture, Compose Multiplatform and Modern Android Development conventions, starting from the four defect classes that keep recurring because neither the compiler, detekt nor spotless can see them. Use this for any PR review, for self-review before pushing, and whenever asked whether a change is safe to merge.

67

Quality

81%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Passed

No findings from the security scan

SKILL.md
Quality
Evals
Security

Quality

Content

78%Weight 40%Scale 1-5

Reviews 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.

DimensionReasoningScore

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

Description

83%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

A strong description: it states a concrete, well-scoped capability and gives explicit, natural-language trigger guidance covering PR review, self-review, and merge-safety questions. The only real gap is that it alludes to 'the four defect classes' without naming them, which slightly limits specificity and leaves a minor overlap surface with generic PR-review skills.

DimensionReasoningScore

Specificity

Names the domain ('Meshtastic-Android change') and concrete review actions with specific convention frameworks ('KMP architecture, Compose Multiplatform and Modern Android Development conventions, starting from the four defect classes'). It names one primary action (review) with rich detail rather than a list of several distinct capabilities, so it sits between the 'several specific actions' (4) and '1-2 concrete actions' (3) anchors — clearly above 3 because the scope (defect classes, compiler/detekt/spotless blindness) is concrete, but below 5 because the four defect classes themselves are not enumerated.

4 / 5

Completeness

Explicitly answers 'what' ('Review a Meshtastic-Android change against KMP architecture, Compose Multiplatform and Modern Android Development conventions, starting from the four defect classes') and 'when' with a clear 'Use this for...' clause listing three concrete trigger scenarios. Both halves are explicit and concrete, matching the 5 anchor; not a 4 because the 'when' is not vague or under-specified.

5 / 5

Trigger Term Quality

Natural trigger phrases are present: 'any PR review', 'self-review before pushing', 'whether a change is safe to merge' — phrases users would actually say. A few common variations are missing (e.g., 'code review', 'pull request', 'review my diff'), keeping it below the comprehensive-synonym coverage of a 5 but comfortably above the sparse keyword coverage of a 3.

4 / 5

Distinctiveness Conflict Risk

The tight repo scoping ('Meshtastic-Android', KMP/CMP/MAD conventions) gives it a clear niche with minimal conflict risk, but the broad trigger 'Use this for any PR review' could overlap with a generic code-review skill when the repo context is absent. Mostly distinct with minor overlap risk against a closely related general review skill — a 4, not 5; clearly not a 3 since the domain lock makes confusion unlikely.

4 / 5

Total

17

/

20

Passed

Validation

100%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository
meshtastic/Meshtastic-Android
Reviewed

Table of Contents

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.