> ## Documentation Index
> Fetch the complete documentation index at: https://docs.blitzy.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Document Code

> Generate comprehensive API documentation, inline comments, and developer guides using AI-Native documentation

Undocumented code creates a bottleneck around the few people who understand it. New hires ramp slowly, API consumers guess at behavior, and knowledge walks out the door with every departure. Blitzy analyzes your code structure and produces documentation in standard formats (JSDoc, Sphinx, OpenAPI) that integrates with your existing tooling, turning tribal knowledge into a shared, maintainable asset.

<Card title="Ready to document code?" icon="rocket" href="/templates/documentation-onboarding/document-code">
  Use the **Document Code Template** to get started with a structured prompt
</Card>

<Note>
  **Jump to:** [When to Use](#when-to-use-this-approach) | [Prompt Structure](#prompt-structure) | [Key Considerations](#key-considerations) | [Common Patterns](#common-patterns) | [Troubleshooting](#troubleshooting)
</Note>

## When to Use This Approach

<Tabs>
  <Tab title="Legacy Code Documentation">
    Add comprehensive inline comments and docstrings to codebases that have little or no documentation.
  </Tab>

  <Tab title="API Reference Generation">
    Produce OpenAPI/Swagger specs from existing API implementations so consumers can integrate confidently.
  </Tab>

  <Tab title="Onboarding Guides">
    Create developer onboarding documentation with architecture overviews, setup instructions, and common workflows.
  </Tab>

  <Tab title="Knowledge Base Building">
    Document complex domain-specific systems so institutional knowledge is preserved and searchable.
  </Tab>
</Tabs>

## Prompt Structure

Follow the [Golden Rules](/prompt-engineering/golden-rules) when writing your documentation prompt. Focus especially on:

* **Documentation Format** - Specify exact format (JSDoc 3.6+, OpenAPI 3.0, Sphinx) and validation tools
* **Scope Definition** - List specific files, classes, or modules requiring documentation
* **Style Guidelines** - Reference existing documentation examples showing preferred style
* **Cross-Reference Strategy** - Define how to link related sections and external resources

## Key Considerations

<CardGroup cols={2}>
  <Card title="Format Specification Prevents Rework" icon="file-code">
    Explicitly state documentation format (JSDoc, Sphinx, OpenAPI 3.0) and style guide to follow (Google, Airbnb). Vague format requests lead to documentation that doesn't integrate with existing tooling.
  </Card>

  <Card title="Scope Boundaries Avoid Duplication" icon="crosshairs">
    Define exactly which modules, classes, or functions need documentation. Overlapping documentation requests create inconsistencies and single-source-of-truth violations.
  </Card>

  <Card title="Cross-References Build Navigation" icon="link">
    Identify related documentation sections and specify linking patterns. Documentation without cross-references creates isolated information silos that users can't navigate effectively.
  </Card>

  <Card title="Domain Terminology Requires Context" icon="book">
    Provide glossaries or examples for domain-specific terms. Documentation that assumes knowledge creates barriers for new developers and integration partners.
  </Card>
</CardGroup>

## Common Patterns

**OpenAPI specification generation** - Document REST API endpoints with request/response schemas, authentication requirements, error codes, and rate limiting. Include code examples in multiple languages and mask sensitive data in examples.

**Inline code comment addition** - Add JSDoc/docstrings for all public methods with parameter descriptions, return values, usage examples, and cross-references to related classes. Follow organization's comment style guide.

**Developer onboarding guide creation** - Document module architecture, setup instructions, common workflows, and troubleshooting. Include architecture diagrams, code examples, and links to related documentation sections.

## Troubleshooting

<AccordionGroup>
  <Accordion title="Generated documentation is technically inaccurate">
    Code analysis may miss domain context. Provide domain glossaries, link to architecture documentation, and review generated docs with subject matter experts for technical accuracy.
  </Accordion>

  <Accordion title="Documentation format doesn't match standards">
    Style guide may not be specified. Reference existing documentation files showing preferred style, specify validation tools (ESLint jsdoc, sphinx-build), and include format examples in prompt.
  </Accordion>

  <Accordion title="Cross-references are broken or missing">
    Linking strategy may be unclear. Define explicit cross-reference patterns, specify how to link related sections, and validate all links resolve correctly after generation.
  </Accordion>

  <Accordion title="Documentation duplicates existing content">
    Scope may overlap with existing docs. Audit current documentation before requesting new docs, define clear boundaries for what should be documented, and specify single-source-of-truth for each topic.
  </Accordion>

  <Accordion title="Code examples don't compile or run">
    Examples may lack proper context. Add the [Enforce Code Style Patterns](/templates/rules/enforce-code-style-patterns) rule to your project on the platform, validate all examples in actual environment, and include complete imports and setup in examples.
  </Accordion>
</AccordionGroup>