Agent Skills - Documentation
Table of Contents
1. Documentation Skills
Skills for maintaining and improving documentation.
1.1. Documentation Completeness Checker
Ensure comprehensive documentation automatically.
---
name: Documentation Completeness Checker
description: Automatically check for missing or incomplete documentation when viewing code, preparing for code review, or when documentation quality is a concern
allowed-tools:
- Read
- Grep
- Write
---
# Documentation Completeness Checker
## Activation Triggers
Activate when:
- Viewing undocumented code files
- Adding new public APIs or functions
- Preparing for pull request or code review
- User mentions documentation, docs, or comments
- README or documentation files are opened
- User asks "is this documented?"
## Check Criteria
### Function/Method Documentation
For each public function, check:
- [ ] **Purpose** clearly stated
- [ ] **Parameters** documented with types and descriptions
- [ ] **Return value** documented with type and meaning
- [ ] **Exceptions/Errors** documented (what errors can occur)
- [ ] **Usage examples** provided for complex functions
- [ ] **Edge cases** noted (boundary conditions, special handling)
- [ ] **Time complexity** noted for algorithms (if relevant)
**Example - Well Documented:**
```typescript
/**
* Calculates the total price including tax and discount.
*
* @param items - Array of items in the cart
* @param taxRate - Tax rate as decimal (e.g., 0.08 for 8%)
* @param discountCode - Optional discount code to apply
* @returns Total price after tax and discount
* @throws {InvalidDiscountError} If discount code is invalid
*
* @example
* const total = calculateTotal(
* [{ price: 10 }, { price: 20 }],
* 0.08,
* 'SAVE10'
* );
*/
function calculateTotal(
items: Item[],
taxRate: number,
discountCode?: string
): number {
// implementation
}
```
### Class/Module Documentation
For classes and modules, check:
- [ ] **Overview** of responsibility and purpose
- [ ] **Public API** all public methods documented
- [ ] **Usage examples** showing typical usage patterns
- [ ] **Dependencies** external requirements noted
- [ ] **Thread safety** concurrency considerations (if applicable)
- [ ] **Design patterns** patterns used (if notable)
**Example:**
```typescript
/**
* UserService handles user account operations.
*
* Provides methods for creating, updating, and authenticating users.
* All methods are async and use the database connection from the
* constructor.
*
* @example
* const userService = new UserService(database);
* const user = await userService.createUser({
* name: 'John',
* email: 'john@example.com'
* });
*/
class UserService {
// implementation
}
```
### File/Package Documentation
For files and packages, check:
- [ ] **File header** explaining purpose and contents
- [ ] **Exports** what's exposed to other modules
- [ ] **Module overview** high-level description
- [ ] **Usage examples** how to use the module
- [ ] **License** licensing information (if applicable)
### README Documentation
For README files, check:
- [ ] **Project description** what the project does
- [ ] **Installation instructions** how to install
- [ ] **Quick start** basic usage example
- [ ] **Configuration** how to configure
- [ ] **API documentation** or link to it
- [ ] **Examples** practical usage examples
- [ ] **Contributing guidelines** how to contribute
- [ ] **License** license information
- [ ] **Contact/Support** how to get help
### API Documentation
For API endpoints, check:
- [ ] **Endpoint description** what it does
- [ ] **HTTP method and path** clearly stated
- [ ] **Request parameters** query params, body, headers
- [ ] **Request examples** sample requests
- [ ] **Response format** what's returned
- [ ] **Response examples** sample responses
- [ ] **Status codes** possible HTTP status codes
- [ ] **Error responses** error formats and codes
- [ ] **Authentication** auth requirements
## Documentation Levels
Assess and report on documentation level:
**Level 5 - Excellent:**
- All public APIs fully documented
- Examples provided for complex functions
- Edge cases and errors documented
- README comprehensive
- Usage patterns clear
**Level 4 - Good:**
- Most public APIs documented
- Basic examples provided
- Common errors documented
- README covers essentials
**Level 3 - Adequate:**
- Core APIs documented
- Some examples present
- README exists with basics
- Missing some details
**Level 2 - Minimal:**
- Some APIs documented
- Few or no examples
- Basic README only
- Many gaps
**Level 1 - Poor:**
- Little to no documentation
- No examples
- Missing or bare README
- Major documentation gaps
## Output Format
When checking documentation, provide:
### 1. Summary
- Overall documentation level (1-5)
- Percentage of public APIs documented
- Number of missing doc blocks
### 2. Missing Documentation
List what's undocumented:
```
Missing documentation:
- Function `processPayment` (src/payment.ts:42)
- Class `UserCache` (src/cache.ts:15)
- API endpoint POST /api/users (src/routes.ts:89)
```
### 3. Incomplete Documentation
List what's partially documented:
```
Incomplete documentation:
- Function `validateEmail`: missing examples
- Class `Database`: missing constructor docs
- README: missing configuration section
```
### 4. Priorities
Rank by importance:
```
High Priority:
- Public API functions (user-facing)
- Security-sensitive operations
- Complex algorithms
Medium Priority:
- Internal modules
- Utility functions
- Helper classes
Low Priority:
- Private methods
- Simple getters/setters
- Test utilities
```
### 5. Offer to Help
After reporting:
- "Would you like me to generate documentation for the missing items?"
- "I can create JSDoc comments for these functions"
- "Should I draft a README section for configuration?"
## Best Practices
### Document Intent, Not Implementation
**Good:**
```typescript
/**
* Validates user input to prevent SQL injection attacks.
*/
```
**Bad:**
```typescript
/**
* Uses regex pattern to check string.
*/
```
### Use Examples for Complex Functions
For anything non-obvious, show usage:
```typescript
/**
* @example
* // Simple case
* const result = parseDate('2024-01-15');
*
* @example
* // With timezone
* const result = parseDate('2024-01-15', 'America/New_York');
*/
```
### Document Edge Cases
Explain boundary conditions:
```typescript
/**
* @param age - User's age (must be 0-150)
* @throws {RangeError} If age is negative or over 150
*/
```
### Keep Documentation Updated
Flag outdated documentation:
- Function signature changed but docs didn't
- New parameters not documented
- Return type changed but docs still show old type
## Language-Specific Formats
**JavaScript/TypeScript:** JSDoc
**Python:** Docstrings (Google or NumPy style)
**Java:** Javadoc
**C/C++:** Doxygen
**Go:** Go doc comments
**Rust:** Rustdoc
**Ruby:** RDoc or YARD
Use the appropriate format for the language.
## When to Skip
Don't be overly pedantic about:
- Private helper functions (use discretion)
- Test code (unless it's a test utility library)
- Obvious trivial getters/setters
- Generated code
Focus on user-facing, public, and complex code.