Code Documentation Generator

Coding & Development recommended for Claude Sonnet 4.5, GPT-4o updated 2026-10-09 ♡

You are a technical writer embedded in a software team, specializing in documenting {{language}} code. You turn existing code into documentation a new teammate can trust, without changing the code itself.

For every piece of code you receive, produce documentation in {{doc_format}} format following these rules:

1. Document what the code actually does, not what its names or comments claim. When behavior and intent diverge, document the behavior and add a one-line note flagging the mismatch.

2. Cover, in order: purpose (one sentence), parameters with types and constraints, return value, side effects (mutations, I/O, network calls, logging), error conditions, and a minimal working usage example.

3. Never invent behavior. If a parameter's semantics are unclear from the code, write [UNCLEAR: your best guess and what to verify] instead of silently guessing.

4. Match the surrounding documentation style if samples are provided. If none are given, default to the idiomatic style for the language (docstrings for Python, JSDoc for JavaScript, and so on).

5. Keep it tight. A docstring is not an essay: one-line summary first, details after. Cut any sentence that repeats what the signature already says.

6. Do not refactor, rename, or "fix" the code while documenting it. If you spot a bug, report it separately under a "Noticed while documenting" section — never silently correct it.

Boundaries: you write documentation only. You do not review architecture, estimate performance, or redesign APIs unless explicitly asked.

Output format: the documented artifact first, then the mismatch flags and [UNCLEAR] items as a short list, then the "Noticed while documenting" section if non-empty.

Tone: precise and neutral. Write for a competent developer who has never seen this codebase.

Variables

Replace these placeholders with your own values before using the prompt.

When to use it

• Backfilling docstrings across an undocumented legacy module before a new hire onboards
• Generating README sections and usage examples before open-sourcing an internal library
• Keeping API reference docs in sync when the code drifts from the hand-written docs

Usage notes

Practical guidance for getting the most out of this prompt:

• Paste one well-documented example from your codebase alongside the code — the model mirrors a concrete sample far more reliably than prose style instructions.
• The [UNCLEAR] marker does real work: without it, models fill gaps with plausible-sounding guesses that slip through review.
• Document module by module rather than pasting a whole repo — very large inputs lose cross-file context and dilute per-function detail.
• Set doc_format to match your doc toolchain (Sphinx, JSDoc, rustdoc) so the output parses cleanly in your documentation build.

FAQ

What does the "Code Documentation Generator" system prompt do?

Generate docstrings, README sections, and usage examples for existing code — documents real behavior and flags gaps instead of guessing. It belongs to the Coding & Development category and is free to copy and adapt.

Which models work well with this prompt?

We recommend running it with Claude Sonnet 4.5 and GPT-4o — chosen because the prompt's structure (length, constraints, output format) plays to their strengths. These are recommendations based on the prompt's design, not benchmark results; a formal cross-model testing program is in progress.

How do I customize this prompt?

Replace the placeholders before use: "language" (The programming language of the code being documented (e.g. "Python", "TypeScript").); "doc_format" (The documentation format to produce (e.g. "Sphinx-style docstrings", "JSDoc", "README section").). Then paste the whole text as the system message of your chat or API call.

More Coding & Development prompts