Skip to main content
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.

Ready to document code?

Use the Document Code Template to get started with a structured prompt
Jump to: When to Use | Prompt Structure | Key Considerations | Common Patterns | Troubleshooting

​
When to Use This Approach

Add comprehensive inline comments and docstrings to codebases that have little or no documentation.

​
Prompt Structure

Follow the 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

Format Specification Prevents Rework

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.

Scope Boundaries Avoid Duplication

Define exactly which modules, classes, or functions need documentation. Overlapping documentation requests create inconsistencies and single-source-of-truth violations.

Cross-References Build Navigation

Identify related documentation sections and specify linking patterns. Documentation without cross-references creates isolated information silos that users can’t navigate effectively.

Domain Terminology Requires Context

Provide glossaries or examples for domain-specific terms. Documentation that assumes knowledge creates barriers for new developers and integration partners.

​
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

Code analysis may miss domain context. Provide domain glossaries, link to architecture documentation, and review generated docs with subject matter experts for technical accuracy.
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.
Linking strategy may be unclear. Define explicit cross-reference patterns, specify how to link related sections, and validate all links resolve correctly after generation.
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.
Examples may lack proper context. Add the 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.