Documentation Writer
Generates accurate, well-structured documentation from source code — including inline docstrings, README sections, API reference pages, and changelog entries — tailored to the detected language and documentation standard.
When to Use
- User asks to "document this function", "write a README", or "add docstrings"
- Public APIs lack documentation and onboarding is difficult
- A new module, package, or service has been created
- CI checks for documentation coverage are failing
- User wants to generate API reference docs for publishing
- Code was written without comments and needs to be understood by new contributors
Process
Determine the documentation target from context:
- Inline docstrings: individual functions, methods, or classes
- Module/package docs: top-level overview of a file or package
- README: project-level introduction, setup, usage, contributing
- API reference: all exported symbols with params, returns, and examples
- Changelog: summarize changes between versions
Detect the language's documentation standard:
- Python → Google style, NumPy style, or reStructuredText (check existing docstrings)
- JavaScript/TypeScript → JSDoc (
@param, @returns, @example, @throws)
- Go → GoDoc (plain sentences starting with the symbol name)
- Java/Kotlin → Javadoc (
@param, @return, @throws)
- Rust →
/// doc comments with # Examples sections
- Ruby → YARD
Read the full source carefully:
- Understand what the function actually does, not just what it's named
- Note all parameters, their types, and valid ranges
- Identify return values and their types
- Catalog exceptions, errors, or edge case behaviors
- Note any side effects (mutations, I/O, external calls)
Write the documentation:
- Start with a one-sentence summary (imperative mood: "Returns the user…", "Validates and stores…")
- Add a longer description if the behavior is non-obvious
- Document every parameter with type and description
- Document the return value and all possible exception types
- Include at least one usage example for public-facing APIs
- Note deprecation warnings, version availability, or platform constraints if applicable
For READMEs, include sections:
- Project title and one-line description
- Badges (build status, coverage, npm/PyPI version if applicable)
- Features list
- Prerequisites and installation
- Quick start / usage examples
- Configuration reference
- API reference (or link to generated docs)
- Contributing guide
- License
Verify accuracy — every documented param must exist in the signature; every documented exception must be reachable in the code.
Output Format
Inline Docstring (Python, Google style)
def calculate_discount(price: float, discount_pct: float) -> float:
"""Apply a percentage discount to a price.
Args:
price: The original price in USD. Must be non-negative.
discount_pct: Discount as a percentage (0–100).
Returns:
The discounted price, floored to two decimal places.
Raises:
ValueError: If ``price`` is negative or ``discount_pct`` is
outside the range [0, 100].
Example:
>>> calculate_discount(100.0, 20.0)
80.0
"""
JSDoc (TypeScript)
/**
* Fetches a paginated list of users matching the given filter.
*
* @param filter - Query parameters to filter users by.
* @param filter.role - Optional role to restrict results to.
* @param options - Pagination options.
* @param options.page - 1-based page number. Defaults to `1`.
* @param options.limit - Results per page (max 100). Defaults to `20`.
* @returns A promise resolving to a paginated result with `data` and `total`.
* @throws {UnauthorizedError} If the caller lacks the `users:read` permission.
*
* @example
* const result = await listUsers({ role: 'admin' }, { page: 2, limit: 10 });
* console.log(result.data); // User[]
*/
Examples
Example Input
func Retry(fn func() error, maxAttempts int, delay time.Duration) error {
for i := 0; i < maxAttempts; i++ {
if err := fn(); err == nil {
return nil
} else if i < maxAttempts-1 {
time.Sleep(delay)
} else {
return err
}
}
return nil
}
Example Output
// Retry calls fn up to maxAttempts times, pausing delay between attempts.
// It returns nil as soon as fn succeeds, or the last error if all attempts fail.
// A delay of 0 retries immediately without pausing.
//
// Example:
//
// err := Retry(fetchData, 3, 500*time.Millisecond)
// if err != nil {
// log.Fatal("all retries exhausted:", err)
// }
func Retry(fn func() error, maxAttempts int, delay time.Duration) error {
Boundaries
- Do NOT fabricate behavior — only document what the code actually does.
- Do NOT add documentation to private/unexported symbols unless explicitly requested.
- Do NOT generate marketing copy — documentation should be precise and technical.
- Do NOT include implementation details that are subject to change in public-facing API docs.
- If a function has unclear or ambiguous behavior, flag it with a
// TODO: clarify behavior comment rather than guessing.
- Keep README sections factual — do not promise features that don't exist in the provided code.
- Do NOT overwrite existing accurate documentation; only add or supplement where coverage is missing.
1---2name: documentation-writer3description: Generates inline docstrings, README sections, and API reference docs from source code and function signatures. Invoke when asked to document code, write a README, add docstrings, create API docs, or explain what a function or module does.4---56# Documentation Writer78Generates accurate, well-structured documentation from source code — including inline docstrings, README sections, API reference pages, and changelog entries — tailored to the detected language and documentation standard.910## When to Use1112- User asks to "document this function", "write a README", or "add docstrings"13- Public APIs lack documentation and onboarding is difficult14- A new module, package, or service has been created15- CI checks for documentation coverage are failing16- User wants to generate API reference docs for publishing17- Code was written without comments and needs to be understood by new contributors1819## Process20211. **Determine the documentation target** from context:22 - **Inline docstrings**: individual functions, methods, or classes23 - **Module/package docs**: top-level overview of a file or package24 - **README**: project-level introduction, setup, usage, contributing25 - **API reference**: all exported symbols with params, returns, and examples26 - **Changelog**: summarize changes between versions27282. **Detect the language's documentation standard**:29 - Python → Google style, NumPy style, or reStructuredText (check existing docstrings)30 - JavaScript/TypeScript → JSDoc (`@param`, `@returns`, `@example`, `@throws`)31 - Go → GoDoc (plain sentences starting with the symbol name)32 - Java/Kotlin → Javadoc (`@param`, `@return`, `@throws`)33 - Rust → `///` doc comments with `# Examples` sections34 - Ruby → YARD35363. **Read the full source carefully**:37 - Understand what the function actually does, not just what it's named38 - Note all parameters, their types, and valid ranges39 - Identify return values and their types40 - Catalog exceptions, errors, or edge case behaviors41 - Note any side effects (mutations, I/O, external calls)42434. **Write the documentation**:44 - Start with a one-sentence summary (imperative mood: "Returns the user…", "Validates and stores…")45 - Add a longer description if the behavior is non-obvious46 - Document every parameter with type and description47 - Document the return value and all possible exception types48 - Include at least one usage example for public-facing APIs49 - Note deprecation warnings, version availability, or platform constraints if applicable50515. **For READMEs**, include sections:52 - Project title and one-line description53 - Badges (build status, coverage, npm/PyPI version if applicable)54 - Features list55 - Prerequisites and installation56 - Quick start / usage examples57 - Configuration reference58 - API reference (or link to generated docs)59 - Contributing guide60 - License61626. **Verify accuracy** — every documented param must exist in the signature; every documented exception must be reachable in the code.6364## Output Format6566### Inline Docstring (Python, Google style)67```python68def calculate_discount(price: float, discount_pct: float) -> float:69 """Apply a percentage discount to a price.7071 Args:72 price: The original price in USD. Must be non-negative.73 discount_pct: Discount as a percentage (0–100).7475 Returns:76 The discounted price, floored to two decimal places.7778 Raises:79 ValueError: If ``price`` is negative or ``discount_pct`` is80 outside the range [0, 100].8182 Example:83 >>> calculate_discount(100.0, 20.0)84 80.085 """86```8788### JSDoc (TypeScript)89```ts90/**91 * Fetches a paginated list of users matching the given filter.92 *93 * @param filter - Query parameters to filter users by.94 * @param filter.role - Optional role to restrict results to.95 * @param options - Pagination options.96 * @param options.page - 1-based page number. Defaults to `1`.97 * @param options.limit - Results per page (max 100). Defaults to `20`.98 * @returns A promise resolving to a paginated result with `data` and `total`.99 * @throws {UnauthorizedError} If the caller lacks the `users:read` permission.100 *101 * @example102 * const result = await listUsers({ role: 'admin' }, { page: 2, limit: 10 });103 * console.log(result.data); // User[]104 */105```106107## Examples108109### Example Input110```go111func Retry(fn func() error, maxAttempts int, delay time.Duration) error {112 for i := 0; i < maxAttempts; i++ {113 if err := fn(); err == nil {114 return nil115 } else if i < maxAttempts-1 {116 time.Sleep(delay)117 } else {118 return err119 }120 }121 return nil122}123```124125### Example Output126```go127// Retry calls fn up to maxAttempts times, pausing delay between attempts.128// It returns nil as soon as fn succeeds, or the last error if all attempts fail.129// A delay of 0 retries immediately without pausing.130//131// Example:132//133// err := Retry(fetchData, 3, 500*time.Millisecond)134// if err != nil {135// log.Fatal("all retries exhausted:", err)136// }137func Retry(fn func() error, maxAttempts int, delay time.Duration) error {138```139140## Boundaries141142- Do NOT fabricate behavior — only document what the code actually does.143- Do NOT add documentation to private/unexported symbols unless explicitly requested.144- Do NOT generate marketing copy — documentation should be precise and technical.145- Do NOT include implementation details that are subject to change in public-facing API docs.146- If a function has unclear or ambiguous behavior, flag it with a `// TODO: clarify behavior` comment rather than guessing.147- Keep README sections factual — do not promise features that don't exist in the provided code.148- Do NOT overwrite existing accurate documentation; only add or supplement where coverage is missing.