---

name: document-guideline description: Instructs AI agents on documentation standards for design docs, folder READMEs, source code interfaces, and test cases

Document Guideline

This skill instructs AI agents on how to maintain comprehensive documentation throughout the development lifecycle. It defines documentation standards that are enforced via pre-commit linting for structural requirements, while providing guidance on content quality and workflow integration.

Documentation Philosophy

Good documentation is:

• Comprehensive: Covers all code files, folders, and high-level designs
• Enforced: Structural requirements validated automatically via pre-commit linting
• Design-first: Documentation written before implementation (following TDD approach)
• Milestone-friendly: Documentation-code inconsistency acceptable during incremental development
• Self-descriptive: Each file, folder, and component documents its purpose and interfaces

Documentation Types

This project maintains three levels of documentation:

1. High-level design documents (docs/*) - Architecture and design decisions
2. Folder organization (folder README.md files) - Purpose and file organization
3. Code interface documentation (.md companions to source files) - External and internal APIs

High-Level Design Documentation

Location: docs/* directory

Purpose: Document architectural decisions, design rationale, and high-level project structure.

When to create/update:

• During planning phase (before implementation)
• When making architectural decisions
• When introducing new subsystems or major features
• When documenting workflows or processes

Not enforced by linting: Creating design documents requires human judgment about what constitutes a "high-level design" versus implementation details.

Content guidelines:

• Focus on the "why" (design rationale) not just the "what"
• Document alternatives considered and trade-offs
• Include diagrams, workflows, or examples where helpful
• Keep design docs synchronized with actual implementation

Examples of good design documents:

• docs/git-msg-tags.md - Documents commit message tag standards
• docs/developer.md - Developer workflow and contribution guidelines
• docs/options.md - SDK configuration options and usage

When NOT to create design docs:

• For simple implementation details (put in code .md files instead)
• For temporary decisions or experiments
• For information that duplicates existing documentation

Folder Organization Documentation

Requirement: Every folder (except hidden folders like .git) MUST have a README.md file.

Enforced by: Pre-commit linting (scripts/lint-documentation.sh)

Purpose: Document folder purpose and file organization so developers can quickly understand the codebase structure.

When to create:

• When creating a new folder in the project
• Before committing any code that introduces a new directory

Required content:

1. Folder purpose: What is this folder for? (1-2 sentences)
2. File organization: What types of files are in this folder?
3. Key files: Brief description of important files (optional)

Examples of good folder README.md:

# Skills Directory

This directory contains all Claude Code skills that define AI agent behavior.

## Organization

Each skill is in its own subdirectory with a `SKILL.md` file:
- `commit-msg/` - Skill for creating meaningful git commits
- `fork-dev-branch/` - Skill for creating development branches
- `milestone/` - Skill for incremental implementation with milestone commits

## Adding New Skills

Create a new subdirectory and add a `SKILL.md` file with frontmatter defining
the skill name and description.

Format flexibility:

• Can be brief (3-5 lines) for simple folders
• Can be detailed for complex subsystems
• Should reference key files if there are many files

Source Code Interface Documentation

Requirement: Every source code file MUST have a corresponding .md file documenting its interfaces.

File types requiring documentation (enforced by linting):

• Python: *.py → *.md
• C/C++: *.c, *.cpp, *.cxx, *.cc → *.md

Enforced by: Pre-commit linting (scripts/lint-documentation.sh)

Naming convention: Same prefix as source file

• foo.py → foo.md
• bar.cpp → bar.md
• baz.c → baz.md

Required sections:

1. External Interfaces (Public APIs)

Document all interfaces exposed to external callers:

• Public functions/methods with signatures
• Public classes/structures with key attributes
• Module-level exports or entry points
• Expected inputs and outputs
• Error conditions and exceptions

2. Internal Helpers (Private APIs)

Document internal implementation details:

• Private functions and their purpose
• Internal data structures
• Helper utilities
• Algorithms or complex logic explanations

Example interface documentation:

# validate_target_dir.sh

Script for validating target directories before SDK initialization.

## External Interface

### Command-line usage
```bash
./validate_target_dir.sh <target_dir> <mode>

Parameters:

• target_dir: Path to directory to validate
• mode: Either "init" or "update"

Exit codes:

• 0: Validation passed
• 1: Validation failed (directory issues)
• 2: Invalid arguments

Output: Error messages to stderr listing validation failures

Internal Helpers

check_directory_exists()

Validates that the target directory exists.

check_write_permissions()

Validates that the user has write access to the directory.

check_conflicting_files()

Scans for files that would conflict with SDK initialization. Returns list of conflicting file paths.

validate_init_mode()

Specific validation for "init" mode (directory must be empty or non-existent).

validate_update_mode()

Specific validation for "update" mode (directory must have existing SDK structure).

**When implementation changes**:
- Update interface documentation to match
- During milestones, temporary doc-code mismatch is acceptable (see below)
- Before final delivery, all documentation must match implementation

## Test Documentation

**Requirement**: Every test case **MUST** have documentation explaining what it tests.

**Enforced by**: Pre-commit linting (`scripts/lint-documentation.sh`)

**Format options**:
1. **Inline comments** within the test file (preferred for simple tests)
2. **Companion `.md` file** (for complex test suites)

**Required content**:
- What is being tested (feature or behavior)
- Expected outcome
- Any setup or preconditions

**Example with inline comments**:

```bash
#!/bin/bash
# Test suite for documentation linting
# Tests that the linter correctly identifies missing documentation

set -e

# Test 1: Linter passes with complete documentation
# Expected: Exit code 0, no errors
test_complete_documentation() {
    # Setup: Create temporary directory with all docs present
    ...
}

# Test 2: Linter fails when folder missing README.md
# Expected: Exit code 1, error message lists folder
test_missing_folder_readme() {
    ...
}

Example with companion .md file:

For test_documentation_lint.sh, create test_documentation_lint.md:

# Documentation Linter Test Suite

Tests for `scripts/lint-documentation.sh` to verify it correctly validates
documentation completeness.

## Test Cases

### test_complete_documentation
**Purpose**: Verify linter passes when all documentation is present
**Setup**: Temporary directory with source files and corresponding .md files
**Expected**: Exit code 0, no error output

### test_missing_folder_readme
**Purpose**: Verify linter catches folders without README.md
**Setup**: Create folder without README.md
**Expected**: Exit code 1, error message listing the folder

...

Linting check:

• For bash test files (test_*.sh), linter checks for either:
  • Inline comments following pattern # Test N: or # Test: or function comments
  • Companion .md file with same prefix

Documentation-Code Consistency During Milestones

Design-First TDD Workflow

This project follows strict design-first test-driven development:

1. Phase 1: Documentation - Update all relevant documentation first
2. Phase 2: Tests - Write test cases based on documentation
3. Phase 3: Implementation - Write code to make tests pass

Acceptable Documentation-Code Inconsistency

During milestone commits, documentation and code may be temporarily inconsistent:

Why this happens:

• Documentation describes the final intended state
• Implementation is incrementally catching up to match documentation
• Tests are written based on documentation (may not all pass yet)

When it's acceptable:

• During milestone commits: Documentation complete, implementation in progress
• On development branches: Work is ongoing, not ready for final delivery
• With explicit test status: Milestone commits show N/M tests passed

When it's NOT acceptable:

• Final delivery commits: All tests must pass, docs must match code
• Merging to main branch: Complete consistency required
• Production releases: Documentation must accurately reflect implementation

Pre-commit Linting and Milestones

The documentation linter (scripts/lint-documentation.sh) runs as part of the pre-commit hook and validates:

• All folders have README.md
• All source files have corresponding .md files
• All test files have documentation

Bypassing the linter:

For milestone commits where documentation is complete but implementation is incomplete:

git commit --no-verify -m "milestone: ..."

The --no-verify flag bypasses all pre-commit hooks, including:

• Documentation linting
• Test execution

IMPORTANT: Only bypass for milestone commits on development branches. Never bypass for final delivery commits or commits to main branch.

Milestone progression example:

Milestone 1: Documentation complete (bypass linting OK)
- All .md files created and document final interfaces
- Implementation: 0% complete
- Tests: 0/10 passed (expected, no implementation yet)
- Commit with: --no-verify

Milestone 2: Partial implementation (bypass linting OK)
- Documentation: Still accurate for final state
- Implementation: 60% complete
- Tests: 6/10 passed
- Commit with: --no-verify

Delivery: All tests pass (NO bypass)
- Documentation: Matches implementation exactly
- Implementation: 100% complete
- Tests: 10/10 passed
- Commit without: --no-verify (linter must pass)

Integration with Other Skills

This documentation guideline integrates with other project skills:

Integration with plan-guideline skill

When creating implementation plans, the plan-guideline skill references these documentation standards:

• Step 1 in plans should always be documentation updates
• Plans should list specific .md files to create/update
• Plans should note which documentation is enforced by linting

Integration with milestone skill

The milestone skill uses these guidelines for incremental development:

• Milestone 1 always creates documentation first
• --no-verify bypass acceptable for milestone commits
• Milestone commits track test progress (N/M tests passed)
• Final delivery requires all linting to pass

Integration with commit-msg skill

The commit-msg skill considers documentation standards:

• Commits updating only documentation use [docs] tag
• Milestone commits note test status in message
• Delivery commits confirm all lints pass

Summary

Enforced by linting (structural requirements):

• ✅ Folder README.md existence
• ✅ Source code .md file correspondence
• ✅ Test documentation presence

Guided by skill (content quality):

• High-level design document creation
• Interface documentation completeness
• Explanation clarity and usefulness

Workflow integration:

• Documentation written first (design-first TDD)
• Temporary doc-code mismatch OK during milestones
• All documentation must match code at delivery