CtrlK
BlogDocsLog inGet started
Tessl Logo

code-commenting

Guidelines for writing self-explanatory code with minimal comments. Covers when to comment (WHY not WHAT), anti-patterns to avoid, annotation tags, public API documentation. Use when writing or reviewing code comments, docstrings, TODO/FIXME tags, code readability, or inline comments.

74

Quality

91%

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

92%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 exemplarily lean, well-organized instruction skill that assumes Claude's competence and adds only genuinely non-obvious guidance. The single gap is the absence of a good-vs-bad comment example to make the WHY-not-WHAT rule concrete.

Suggestions

Add a two-line good-vs-bad example contrasting a WHAT comment ('// increment i by 2') with a WHY comment ('// step by 2: column pairs share a row') to make the core rule copy-paste concrete.

Include one short example of a well-formed TODO or FIXME tag showing the expected owner/date/note format, so the tag guidance is directly executable.

DimensionReasoningScore

Conciseness

Twelve lean lines with zero padding: every token adds non-obvious guidance ('Comment WHY, not WHAT', 'delete it; git has the history') and nothing explains concepts Claude already knows.

5 / 5

Actionability

Concrete, specific instruction-only guidance — 'rename instead of commenting', an explicit do-comment list, and per-tag semantics like 'HACK … say why and when it can go' — but no worked example contrasting a WHY comment against a WHAT comment, which is the skill's core instruction.

4 / 5

Workflow Clarity

A single, unambiguous action for a simple skill under 50 lines, so the simple-skill exception applies; there are no destructive or batch operations that would demand validation checkpoints.

5 / 5

Progressive Disclosure

Under 50 lines with no need for external references, and the content is well organized into clear sections (intro, Annotation Tags, Never), satisfying the simple-skill exception for a 5.

5 / 5

Total

19

/

20

Passed

Description

91%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 in third-person voice with an explicit 'Use when' trigger clause and excellent natural keyword coverage. Its only weaknesses are minor: coverage is framed as topics rather than concrete actions, and 'code readability' introduces slight overlap risk with general style skills.

DimensionReasoningScore

Specificity

Names the domain plus several concrete coverage areas — 'when to comment (WHY not WHAT), anti-patterns to avoid, annotation tags, public API documentation' — but they read as topic coverage rather than the comprehensive list of concrete actions the 5-anchor describes.

4 / 5

Completeness

Explicitly answers both: a clear 'what' ('Guidelines for writing self-explanatory code with minimal comments. Covers…') and an explicit trigger clause ('Use when writing or reviewing code comments, docstrings, TODO/FIXME tags…') with concrete trigger phrases.

5 / 5

Trigger Term Quality

Covers the natural phrasings users would actually say — 'code comments, docstrings, TODO/FIXME tags, code readability, or inline comments' — including tag synonyms users type verbatim; no file extensions apply to this domain, so nothing relevant is missing.

5 / 5

Distinctiveness Conflict Risk

Clear commenting niche with distinct triggers (docstrings, TODO/FIXME), but 'code readability' is a broad term that could overlap with general code-style or refactoring skills, leaving minor conflict risk.

4 / 5

Total

18

/

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.

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository
monkilabs/opencastle
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.