---
title: "doc gen"
description: "Generate documentation from the codebase for the specified scope."
type: skill
canonical_url: https://claudary.paisolsolutions.com/skills/doc-gen
source: "Claudary"
difficulty: intermediate
author: "Claude Code Knowledge Pack"
date: 2026-07-10T11:19:57.519Z
license: CC-BY-4.0
attribution: "doc gen — Claudary (https://claudary.paisolsolutions.com/skills/doc-gen)"
---

# doc gen
Generate documentation from the codebase for the specified scope.

## Overview

Generate documentation from the codebase for the specified scope.

## Steps

### 1. Determine Scope
- If a specific file or module is provided, document that.
- If no scope is given, identify the most important public-facing modules.
- Focus on: exported functions, public classes, API endpoints, configuration options.

### 2. Read the Code
- Read source files to understand function signatures, types, and behavior.
- Look at existing tests for usage examples.
- Check for existing doc comments or README sections to update rather than replace.

### 3. Generate API Documentation
For each public function/method:
```
### functionName(param1: Type, param2: Type): ReturnType

Brief description of what it does.

**Parameters:**
- `param1` - Description and constraints.
- `param2` - Description and defaults.

**Returns:** Description of return value.

**Throws:** Error conditions.

**Example:**
```code
const result = functionName("value", { option: true });
```
```

### 4. Generate README Sections
- **Installation**: How to install and configure.
- **Quick Start**: Minimal example to get started.
- **Configuration**: Available options with defaults.
- **API Reference**: Link to or inline the API docs.

### 5. Add Inline Documentation
For complex logic (non-obvious algorithms, business rules, workarounds):
- Add a brief comment explaining **why**, not what.
- Document preconditions and postconditions for critical functions.
- Note any gotchas or non-obvious behavior.

## Rules

- Document behavior, not implementation. Describe what a function does, not how.
- Use concrete examples, not abstract descriptions.
- Keep docs close to code: inline comments for complex logic, JSDoc/docstrings for public APIs.
- Do not document obvious code (getters, setters, simple wrappers).
- If a function is too complex to document clearly, that is a signal to refactor it.
- Update existing documentation rather than creating duplicate files.

---

Source: [Claudary](https://claudary.paisolsolutions.com/skills/doc-gen) · https://claudary.paisolsolutions.com