playbook/outfitter-agents/plugins/outfitter/skills/docs-audit/references/completeness-checklist.md

5.3 KiB

Documentation Completeness Checklist

Use this checklist when auditing documentation for coverage and required content.

Export Coverage

TypeScript/JavaScript

Every public export should have documentation:

// ✅ Documented export
/**
 * Processes user input and returns validated result.
 * @param input - Raw user input string
 * @returns Validated and sanitized input
 * @throws {ValidationError} If input fails validation
 */
export function processInput(input: string): ValidatedInput { ... }

// ❌ Undocumented export
export function processInput(input: string): ValidatedInput { ... }

Check coverage:

# Count exports
EXPORTS=$(grep -c "^export " src/**/*.ts)
# Count documented exports (/** before export)
DOCUMENTED=$(grep -B1 "^export " src/**/*.ts | grep -c "/\*\*")
# Coverage = DOCUMENTED / EXPORTS * 100

Python

Every public function/class should have a docstring:

# ✅ Documented
def process_input(input: str) -> ValidatedInput:
    """Process user input and return validated result.

    Args:
        input: Raw user input string

    Returns:
        Validated and sanitized input

    Raises:
        ValidationError: If input fails validation
    """
    ...

# ❌ Undocumented
def process_input(input: str) -> ValidatedInput:
    ...

Rust

Every public item should have doc comments:

// ✅ Documented
/// Processes user input and returns validated result.
///
/// # Arguments
/// * `input` - Raw user input string
///
/// # Returns
/// Validated and sanitized input
///
/// # Errors
/// Returns `ValidationError` if input fails validation
pub fn process_input(input: &str) -> Result<ValidatedInput, ValidationError> { ... }

// ❌ Undocumented
pub fn process_input(input: &str) -> Result<ValidatedInput, ValidationError> { ... }

Go

Every exported function should have a godoc comment:

// ✅ Documented
// ProcessInput processes user input and returns validated result.
// It returns a ValidationError if input fails validation.
func ProcessInput(input string) (ValidatedInput, error) { ... }

// ❌ Undocumented
func ProcessInput(input string) (ValidatedInput, error) { ... }

Required Sections by Document Type

README.md

  • Title - Clear project name
  • Description - What it does (1-2 sentences)
  • Installation - How to install/setup
  • Quick Start - Minimal working example
  • Usage - Basic usage patterns
  • License - License type or link

Nice to have:

  • Badges (build status, version, etc.)
  • Table of contents (for long READMEs)
  • Contributing guidelines or link
  • Changelog or link

API Reference

  • Overview - What the API does
  • Authentication - How to authenticate
  • Base URL - API endpoint base
  • Endpoints - All public endpoints documented
  • Request/Response - Schemas for each endpoint
  • Errors - Common error codes and meanings

Configuration Reference

  • Overview - What can be configured
  • File Location - Where config lives
  • Format - JSON, YAML, TOML, etc.
  • All Options - Each config key documented
  • Defaults - Default values listed
  • Examples - Working config examples

CLI Reference

  • Installation - How to install
  • Commands - All commands documented
  • Options - Global and command-specific options
  • Examples - Common usage examples
  • Exit Codes - What different exit codes mean

Contributing Guide

  • Setup - Development environment setup
  • Workflow - How to submit changes
  • Standards - Code style, testing requirements
  • Review Process - What to expect

Changelog

  • Version Numbers - Semantic versioning
  • Dates - Release dates
  • Categories - Added, Changed, Fixed, Removed
  • Migration Notes - For breaking changes

Cross-Reference Completeness

  • All mentioned features link to their docs
  • Related concepts are cross-linked
  • No dead internal links
  • Dependencies link to their docs
  • Standards link to specifications
  • Tools link to official sites

Example Completeness

Code Examples Should Include

  • Necessary imports
  • Variable declarations with types
  • Error handling (where appropriate)
  • Expected output (for non-obvious cases)

Example Types Needed

  • Minimal - Simplest possible usage
  • Typical - Common real-world usage
  • Advanced - Complex scenarios (if applicable)
  • Edge Cases - Unusual but valid inputs

Accessibility

  • Alt text - Images have descriptive alt text
  • Headings - Proper heading hierarchy (h1 > h2 > h3)
  • Code blocks - Language specified for syntax highlighting
  • Tables - Headers on tables

Severity Classification

Severity Criteria Example
Critical Core functionality undocumented No installation instructions, main API undocumented
High Important features undocumented Missing error handling docs, no config reference
Medium Nice-to-have sections missing No contributing guide, missing advanced examples
Low Polish items Missing badges, no table of contents