Documentation Guide Enforcement Skill

Ensures all documentation is consistent, current, and complete. Used by the doc-master agent.

Keep a Changelog Format

All CHANGELOG entries MUST follow Keep a Changelog format.

Categories (in this order)

• Added — new features
• Changed — changes to existing functionality
• Deprecated — soon-to-be removed features
• Removed — removed features
• Fixed — bug fixes
• Security — vulnerability fixes

Structure

# Changelog

## [Unreleased]

### Added
- New authentication module (#123)

### Fixed
- Token expiry off-by-one error (#124)

## [1.2.0] - 2026-02-15

### Added
- Batch processing support (#100)

The [Unreleased] section MUST always exist at the top for accumulating changes.

README Required Sections

Every README.md MUST contain these sections in order:

1. Overview — 1-2 sentence project description
2. Installation — How to install/set up
3. Usage / Quick Start — Minimal working example
4. Commands Table — Available commands with descriptions
5. Configuration — Config files, env vars, options
6. Contributing — How to contribute, link to CONTRIBUTING.md

Docstring Format: Google Style

All public functions MUST have Google-style docstrings.

def process_data(
    data: List[Dict],
    *,
    validate: bool = True,
) -> ProcessResult:
    """Process input data with optional validation.

    Args:
        data: Input records as list of dicts with 'id' and 'content' keys.
        validate: Whether to validate input before processing.

    Returns:
        ProcessResult with metrics and processed items.

    Raises:
        ValueError: If data is empty or missing required keys.
    """

Include Args, Returns, and Raises for every public function. Omit sections only if truly not applicable (e.g., no exceptions raised).

HARD GATE: Sync Rules

Documentation MUST stay in sync with code at all times.

FORBIDDEN:

• Updating code without updating corresponding docs
• Hardcoded component counts (e.g., “17 agents”) — use dynamic discovery or verify against filesystem
• Undocumented public APIs — every public function needs a docstring
• Stale cross-references — links to files/sections that no longer exist
• CHANGELOG entries without issue/PR numbers
• Version dates that do not match actual release dates

REQUIRED:

• CHANGELOG entry for every user-visible change
• Version date updated when changes are made
• Component counts verified against filesystem before committing
• Cross-references validated (all linked files exist)
• README updated when commands or configuration change
• Docstrings updated when function signatures change

When to Update Which Docs

ADR Template

For major architectural decisions, create an ADR (Architecture Decision Record).

# ADR-NNN: [Title]

**Date**: YYYY-MM-DD
**Status**: Proposed | Accepted | Deprecated | Superseded by ADR-NNN

## Context
What is the issue or decision we need to make?

## Decision
What did we decide and why?

## Consequences
What are the positive and negative outcomes?

## Alternatives Considered
What other options were evaluated and why were they rejected?

Store ADRs in docs/adr/ directory, numbered sequentially.

Anti-Patterns

BAD: Hardcoded counts

This project has 17 agents and 40 skills.

These numbers drift immediately. Verify against filesystem or use dynamic discovery.

GOOD: Verified counts

# Count before documenting
ls plugins/autonomous-dev/agents/*.md | wc -l
ls plugins/autonomous-dev/skills/*/SKILL.md | wc -l

BAD: Stale cross-references

See [architecture guide](docs/ARCHITECTURE.md) for details.

If docs/ARCHITECTURE.md was renamed to docs/ARCHITECTURE-OVERVIEW.md, this link is broken.

GOOD: Validated references

Check all links exist before committing documentation changes.

BAD: Missing CHANGELOG entry

Shipping a user-visible feature with no CHANGELOG entry. Users cannot discover what changed.

GOOD: CHANGELOG-first workflow

Write the CHANGELOG entry before or during implementation, not as an afterthought.

Cross-References

• project-alignment: PROJECT.md as source of truth
• git-github: Commit message and PR conventions
• code-review: Documentation checklist item (#8)