Code Documentation Writer

Write documentation for the following code. Match the documentation style specified.

LANGUAGE: [Python / TypeScript / JavaScript / Go / Java / Rust / other]
DOC STYLE: [JSDoc / TSDoc / Google-style docstrings / NumPy-style / reStructuredText / plain comments]
SCOPE: [single function / class / module / entire file]

CODE TO DOCUMENT:
\`\`\`[LANGUAGE]
[PASTE YOUR CODE HERE]
\`\`\`

DOCUMENTATION REQUIREMENTS:
- Describe what this code does (not how — the code shows how)
- Document all parameters with types and descriptions
- Document return value(s) with type and description
- Document exceptions/errors that can be thrown or returned
- Include a usage example for public functions/methods
- Note any important edge cases, gotchas, or performance considerations
- Flag any parameters with non-obvious defaults or behavior

CONTEXT (optional):
- What larger system does this code belong to? [e.g., "auth module for a REST API"]
- Who is the primary audience? [internal engineers / public API consumers / both]

Output the documented version of the code with documentation added inline.
Do not change the code logic — only add documentation.

How to use

Paste your undocumented (or poorly documented) code along with the documentation style your codebase uses. Works best on individual functions or classes rather than huge files. For large files, break them into logical sections and document each one.

Variables

• [LANGUAGE] — the programming language; affects syntax for doc comments
• [DOC STYLE] — JSDoc for JavaScript/TypeScript, Google-style or NumPy for Python, etc. If unsure, use "plain comments"
• [SCOPE] — be explicit about what level you're documenting
• [PASTE YOUR CODE HERE] — the actual code; don't paraphrase it
• Audience context matters: public API docs need examples; internal module docs need architectural context

Tips

• Specify the doc style explicitly. "JSDoc" produces @param, @returns, @throws. "Google-style Python" produces a different format. Mismatched styles in a codebase are worse than no docs.
• Ask for usage examples on anything public-facing — the example often catches parameter confusion the type signature alone doesn't.
• If the code is complex, add a one-line note about why it's structured that way — this is the documentation AI usually skips but engineers need most.
• Run the output through your linter/doc generator (ESDoc, Sphinx, godoc) to verify it parses correctly before committing.