79573df7cb
20 specialized agents, 10 skills, 17 slash commands, 6 plugins, 12 hooks with scripts, 8 rule sets, 3 CLAUDE.md templates, 14 MCP server configs, and interactive setup installer.
56 lines
1.9 KiB
Markdown
56 lines
1.9 KiB
Markdown
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.
|