Cline rules

1---
2description: "Guides Cline to generate comprehensive, well-structured documentation for existing code — READMEs, API docs, and inline comments."
3author: "Cline Team"
4version: "1.0"
5category: "Documentation"
6tags: ["documentation", "readme", "api-docs", "comments"]
7globs: ["*.*"]
8---
9 
10# Create Documentation
11 
12When asked to document code, produce clear, accurate, and useful documentation that helps developers understand the codebase quickly.
13 
14## Documentation Approach
15 
161. **Read Before Writing** — Analyze the code thoroughly before documenting. Understand the architecture, data flow, and key design decisions.
17 
182. **Audience Awareness** — Write for the developer who will maintain or use this code next. Assume they're competent but unfamiliar with this specific codebase.
19 
203. **Accuracy Over Completeness** — It's better to document fewer things correctly than everything superficially. Never guess — if something is unclear, say so.
21 
22## README Generation
23 
24When creating or updating a README, include:
25 
26- **Project Title & Description** — What it does in 1-2 sentences
27- **Quick Start** — Minimal steps to get running (install, configure, run)
28- **Architecture Overview** — High-level description of how the system is organized, with a diagram if it would help
29- **Key Concepts** — Domain terms or abstractions a new developer needs to understand
30- **Configuration** — Environment variables, config files, and their options
31- **Development** — How to set up a dev environment, run tests, and contribute
32 
33Keep it scannable. Use headings, code blocks, and bullet points.
34 
35## API Documentation
36 
37For functions, classes, and modules:
38 
39- **Purpose** — What it does and when to use it
40- **Parameters** — Name, type, description, and whether required or optional
41- **Return Value** — Type and description
42- **Errors** — What can go wrong and how errors are communicated
43- **Example** — A minimal, working usage example
44 
45## Inline Comments
46 
47Add comments that explain **why**, not **what**:
48 
49- ✅ `// Retry up to 3 times because the upstream API is flaky during deploys`
50- ❌ `// Set retries to 3`
51 
52Focus comments on:
53- Non-obvious business logic or domain rules
54- Workarounds with context on why they're needed
55- Performance-critical sections explaining the optimization
56- Complex algorithms with a brief explanation of the approach
57