CtrlK
BlogDocsLog inGet started
Tessl Logo

docstring

Document a Python module and its classes using Google style

70

1.43x
Quality

55%

Does it follow best practices?

Impact

95%

1.43x

Average score across 3 eval scenarios

SecuritybySnyk

Passed

No known issues

Optimize this skill with Tessl

npx tessl skill review --optimize ./.claude/skills/docstring/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

77%

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

This is a solid, actionable skill with clear workflow and comprehensive examples for every docstring format. Its main weakness is length — the extensive format templates and examples make it verbose for a skill file, though most content is project-specific and justified. The checklist provides good validation, and the disambiguation logic for class name resolution shows thoughtful workflow design.

Suggestions

Consider extracting the detailed format examples (module, class, constructor, method, dataclass, enum) into a separate FORMATS.md reference file, keeping SKILL.md as a concise overview with one representative example.

Remove writing style guidelines that Claude already knows (e.g., 'No casual language or filler words', 'Concise and professional') and keep only project-specific conventions like the backtick usage rule and the 'Parameters:' vs 'Args:' distinction.

DimensionReasoningScore

Conciseness

The skill is fairly well-structured but includes some redundancy. Multiple format sections (module, class, constructor, method, dataclass, enum) each have both a template and an example, which adds length. The writing style guidelines section includes some obvious advice Claude would already know (e.g., 'No casual language or filler words'). However, most content is project-specific conventions that earn their place.

2 / 3

Actionability

The skill provides fully concrete, copy-paste-ready docstring templates and examples for every documentation type (module, class, constructor, method, dataclass, enum). The step-by-step instructions for identifying what to document are specific and executable, including search commands and disambiguation logic.

3 / 3

Workflow Clarity

The workflow is clearly sequenced: determine target → read module → apply documentation in specified order → skip specified items → verify with checklist. The checklist at the end serves as an explicit validation checkpoint. The disambiguation step (multiple matches → ask user) is a good feedback loop for ambiguous inputs.

3 / 3

Progressive Disclosure

The content is well-organized with clear section headers, but it's a long monolithic file (~180 lines) with no references to external files. The detailed format examples for each documentation type (module, class, constructor, method, dataclass, enum, deprecation) could potentially be split into a reference file, keeping the SKILL.md as a concise overview. However, given no bundle files exist, this is somewhat expected.

2 / 3

Total

10

/

12

Passed

Description

32%

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

The description is too terse and lacks a 'Use when...' clause, making it incomplete for skill selection purposes. While it identifies a specific domain (Python, Google style docs), it doesn't enumerate concrete actions or provide trigger terms that would help Claude reliably select this skill over alternatives.

Suggestions

Add a 'Use when...' clause with trigger terms like 'docstrings', 'Google-style documentation', 'document Python code', 'module documentation', 'class documentation'.

List specific concrete actions such as 'Generate Google-style docstrings for modules, classes, methods, and functions, including parameter types, return values, exceptions, and usage examples'.

Include common file/term variations users might mention: 'docstring', '.py files', 'API docs', 'autodoc', 'Sphinx-compatible'.

DimensionReasoningScore

Specificity

It names the domain (Python module documentation) and a specific style (Google style), but doesn't list concrete actions beyond 'document'. It could mention generating docstrings, parameter descriptions, return types, class attributes, etc.

2 / 3

Completeness

It partially answers 'what' (document a Python module) but has no 'when' clause or explicit trigger guidance. Per the rubric, a missing 'Use when...' clause caps completeness at 2, and the 'what' is also weak, so this scores a 1.

1 / 3

Trigger Term Quality

Includes relevant terms like 'Python module', 'classes', and 'Google style' which users might say, but misses common variations like 'docstrings', 'documentation strings', 'Google-style docstrings', 'autodoc', or 'API documentation'.

2 / 3

Distinctiveness Conflict Risk

The mention of 'Google style' and 'Python module' provides some distinctiveness, but it could overlap with general Python documentation skills, code commenting skills, or other docstring-related skills.

2 / 3

Total

7

/

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.

Validation11 / 11 Passed

Validation for skill structure

No warnings or errors.

Repository
pipecat-ai/pipecat
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.