code-commenting
Guidelines for writing self-explanatory code with minimal comments. Covers when to comment (WHY not WHAT), anti-patterns to avoid, annotation tags, and public API documentation. Use when writing or reviewing code comments, docstrings, TODO/FIXME tags, code readability, or inline comments.
100
100%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
Quality
Discovery
100%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This is a well-crafted skill description that clearly defines its scope around code commenting best practices. It effectively combines a concise 'what' statement with an explicit 'Use when' clause containing natural trigger terms. The description uses third person voice appropriately and covers both the philosophical approach (WHY not WHAT) and practical elements (annotation tags, API docs).
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions and topics: writing self-explanatory code, when to comment (WHY not WHAT), anti-patterns to avoid, annotation tags, and public API documentation. These are concrete, actionable areas. | 3 / 3 |
Completeness | Clearly answers both 'what' (guidelines for self-explanatory code with minimal comments, covering WHY not WHAT, anti-patterns, annotation tags, API docs) and 'when' (explicit 'Use when' clause listing writing/reviewing code comments, docstrings, TODO/FIXME tags, code readability, inline comments). | 3 / 3 |
Trigger Term Quality | Includes strong natural keywords users would say: 'code comments', 'docstrings', 'TODO/FIXME tags', 'code readability', 'inline comments', 'reviewing code'. These cover common variations of how users would phrase requests about commenting practices. | 3 / 3 |
Distinctiveness Conflict Risk | Has a clear niche focused specifically on code commenting practices and documentation style. The specific triggers like 'TODO/FIXME tags', 'docstrings', and 'inline comments' are distinct enough to avoid conflicts with general coding or documentation skills. | 3 / 3 |
Total | 12 / 12 Passed |
Implementation
100%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is an exemplary skill file that is maximally concise while remaining highly actionable. It uses tables for quick-reference decisions, concrete code examples showing good and bad patterns, and a final checklist for validation. The content respects Claude's intelligence by never explaining obvious concepts and focusing entirely on the specific conventions to follow.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Extremely lean and efficient. Uses tables for quick scanning, provides only what Claude wouldn't inherently know (project-specific conventions), and every line earns its place. No unnecessary explanations of what comments are or how JavaScript works. | 3 / 3 |
Actionability | Provides concrete, executable JavaScript examples showing both anti-patterns (✗) and correct patterns (✓). The JSDoc example is copy-paste ready, the decision table gives clear action for each situation, and annotation tags are specific and immediately usable. | 3 / 3 |
Workflow Clarity | This is a single-purpose instructional skill (commenting guidelines), not a multi-step destructive process. The decision table ('When to Comment') provides a clear workflow for deciding whether/how to comment, and the checklist at the end serves as a validation checkpoint for reviewing comments. | 3 / 3 |
Progressive Disclosure | For a skill under 50 lines with no need for external references, the content is excellently organized with clear sections (When to Comment, Examples, Public APIs, Annotation Tags, Anti-Patterns, Checklist) that allow quick navigation without requiring separate files. | 3 / 3 |
Total | 12 / 12 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 — 11 / 11 Passed
Validation for skill structure
No warnings or errors.
- Repository
- monkilabs/opencastle
- Commit
18c6f2c
- 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.