Code Documenter

Automatically generate and improve code documentation following language-specific standards.

Overview

This skill automates documentation generation for development teams. It detects your codebase language, applies appropriate docstring standards (Google/NumPy for Python, JSDoc/TSDoc for TypeScript, Javadoc for Java, godoc for Go, rustdoc for Rust), and validates documentation quality.

What it automates:

• •Detection of language and existing documentation style
• •Generation of missing docstrings for public APIs
• •Validation of documentation completeness and quality
• •Suggestions for documentation improvements

Language Support

Workflow

Step 1: Detect Language and Style

First, I'll scan your codebase to identify:

• •Primary programming language(s)
• •Existing documentation conventions (if any)
• •Public API surface that needs documentation

Step 2: Analyze Coverage

I'll check current documentation status:

• •Files with existing documentation
• •Public functions/classes missing documentation
• •Documentation quality issues (incomplete params, missing returns)

Step 3: Generate Documentation

For undocumented code, I'll generate:

• •One-line summary describing purpose
• •Parameter documentation with types and descriptions
• •Return value documentation
• •Exception/error documentation where applicable
• •Usage examples for complex functions

Step 4: Validate Quality

I'll verify documentation meets quality standards:

• •No placeholder content (TODO, TBD, ...)
• •All parameters documented
• •Return types specified
• •Consistent style throughout

Triggers

Run this skill when:

• •Adding new functions or classes
• •Preparing code for review
• •Onboarding new team members
• •Setting up documentation infrastructure

Verification

Success Indicators

• •All public APIs have docstrings
• •Documentation style is consistent
• •No placeholder content remains
• •Parameters and returns documented

Coverage Report

After running, I'll provide:

• •Documentation coverage percentage
• •List of newly documented items
• •Remaining items needing manual attention

Examples

Example 1: Document a Python Module

User: Document the functions in src/utils/helpers.py
Assistant: Analyzing src/utils/helpers.py...

Found 5 public functions, 2 already documented.

Generating documentation for 3 functions using Google style:

def calculate_discount(price: float, percentage: float) -> float:
    """Calculate discounted price.

    Args:
        price: Original price in dollars.
        percentage: Discount percentage (0-100).

    Returns:
        Final price after applying discount.

    Raises:
        ValueError: If percentage is not between 0 and 100.
    """

[Continues for remaining functions...]

Coverage: 100% (5/5 functions documented)

Example 2: Audit TypeScript Documentation

User: Check documentation coverage in src/components/
Assistant: Scanning TypeScript files in src/components/...

Documentation Report:
- Total exports: 24
- Documented: 18 (75%)
- Missing: 6

Missing documentation:
1. src/components/Button.tsx: ButtonProps interface
2. src/components/Modal.tsx: useModal hook
3. src/components/Form.tsx: validateField, submitForm, resetForm

Would you like me to generate TSDoc comments for these?

Example 3: Set Up Documentation Standards

User: Help us establish documentation standards for our Python project
Assistant: I'll analyze your current codebase and recommend a standard.

Current state:
- 3 files use Google-style docstrings
- 2 files use NumPy-style docstrings
- 5 files have no docstrings

Recommendation: Standardize on Google style (most common in your codebase).

I'll create:
1. Documentation style guide (CONTRIBUTING.md section)
2. Pre-commit hook to validate docstring format
3. Generate missing docs in Google style

Proceed? (y/n)

Configuration

Style Preferences

When multiple styles are valid, I'll ask which you prefer:

Scope Control

Safety

Idempotency

Running multiple times is safe:

• •Existing documentation is preserved
• •Only missing documentation is added
• •Style conflicts are flagged, not overwritten

Reversibility

All changes are made through standard file edits:

• •Use git diff to review changes
• •Use git checkout to revert if needed

Output Checklist

Before considering documentation complete:

• • All public functions have docstrings
• • Parameter types and descriptions present
• • Return values documented with type
• • Exceptions documented where thrown
• • No placeholder content (TODO, TBD, FIXME)
• • Consistent style across codebase
• • At least one example for complex functions