| name | Writing Documentation for LLMs |
| description | Create effective documentation that LLMs can discover and use. Use when documenting code, APIs, features, or creating reference materials. Covers structure, conciseness, examples, and anti-patterns for optimal LLM comprehension. |
Writing Documentation for LLMs
When to Use
- Creating documentation, guides, or reference materials
- Writing API docs, feature specs, or knowledge bases
- Structuring information for LLM discovery
- Evaluating documentation quality and comprehensiveness
Core Principles
Assume Competence
LLMs already know fundamentals. Only add information they don't have. Every section should justify its token cost.
Verbose (~150 tokens):
PDF (Portable Document Format) files are a common file format that contains text, images, and other content. To extract text from a PDF, you'll need to use a library. There are many libraries available for PDF processing...
Concise (~50 tokens):
Use pdfplumber for text extraction:
```python
import pdfplumber
with pdfplumber.open("file.pdf") as pdf:
text = pdf.pages[0].extract_text()
### Match Specificity to Task Fragility
**Narrow instructions** (low freedom) when:
- Operations are error-prone or destructive
- Consistency is critical
- Exact sequence required
**General guidance** (high freedom) when:
- Multiple approaches are valid
- Context determines best path
- Heuristics guide the approach
## Structure Best Practices
### Progressive Disclosure
Organize like a table of contents. Main file provides overview; detailed materials referenced only when needed.
- Main file: high-level guide with references (<500 lines)
- Reference files: one per domain/topic
- Avoid nested references (file A โ B โ C)
### Table of Contents
For files >100 lines, include TOC so LLMs see full scope even with partial reads.
### Consistent Terminology
Choose one term and use it throughout:
- Always "API endpoint" (not "URL", "route", "path")
- Always "field" (not "box", "element")
- Always "extract" (not "pull", "get")
## Content Patterns
### Descriptions: What + When
Enable discovery with concrete capability + context:
**Good**: "Extract text and tables from PDF files, fill forms, merge documents. Use when working with PDF files or when user mentions PDFs, forms, or document extraction."
**Bad**: "Helps with documents"
### Examples Over Explanations
Show concrete input/output examples before abstract descriptions.
### Workflows with Clear Steps
Break complex operations into sequential steps. Use checklists for complex workflows.
### Feedback Loops
Use validator patterns for quality-critical tasks:
1. Make edits
2. **Validate** โ Run validation
3. If validation fails โ Review, fix, retry
4. **Only proceed when validation passes**
## Anti-patterns to Avoid
- **Too many options**: Present single recommended approach, alternatives only if necessary
- **Deeply nested references**: Keep one level deep from main file
- **Vague terminology**: Use specific, discoverable language
- **Windows-style paths**: Always use forward slashes (e.g., `scripts/helper.py`)
- **Time-sensitive information**: Use "Old patterns" sections with details collapsed
