Good documentation is the difference between a library developers adopt and one they abandon, and these Documentation Generation Prompts turn that process from a chore into a few minutes of work. These templates work well with Claude, GPT-4, Gemini, and DeepSeek, giving you consistent, structured output without the usual back-and-forth. Here is a set of ready-to-use templates that get straight to the point.
Why Generic Prompts Fail Here
The problem with "write docs for this code" is that it produces either a verbose re-statement of the code or a shallow overview that misses edge cases. Generic prompts lack the structural constraints needed for technical writing.
In my experience, the failure mode is predictable: the LLM explains what the function does (obvious) but skips the why behind the design, the error handling, and the performance implications. These Documentation Generation Prompts fix that by baking in the required sections, the audience, and the tone upfront, forcing the model to fill in the gaps rather than pad the output.
Template 1: The "API Contract" Prompt
This template is ideal for public-facing functions and modules where the signature is the contract.
You are a senior technical writer. Generate documentation for the following {language} code.
**Code:**
{PASTE_CODE_HERE}
**Output Requirements:**
1. **Overview**: 2-3 sentences on what the code does and the problem it solves.
2. **Parameters**: A markdown table with columns: Name, Type, Required, Default, Description.
3. **Return Value**: Exact type and a description of what it represents.
4. **Raises/Throws**: List every exception or error state, including the exact condition that triggers it.
5. **Usage Example**: One realistic code snippet showing the function in action.
6. **Edge Cases**: 3 specific scenarios where this code might fail or behave unexpectedly.
**Constraints:**
- Do not include any introductory text or summary.
- Use imperative mood for descriptions (e.g., "Fetches" not "This function fetches").
- Keep the total output under 400 words.
Placeholders: {language} (e.g., TypeScript, Python), {PASTE_CODE_HERE} (the actual source code). The "Edge Cases" section is the secret sauce—it forces the model to actually analyze control flow rather than just describe it.
Template 2: The "Quick Reference" Prompt
This one is for READMEs or onboarding docs where developers need a fast scan, not a deep dive.
You are documenting a utility function for a developer-focused README. Write concise documentation for:
**Code:**
{PASTE_CODE_HERE}
**Format:**
- **One-liner**: A single sentence, under 25 words, describing the function's purpose.
- **When to use it**: 2 bullet points on the ideal use case.
- **When NOT to use it**: 2 bullet points on when a developer should pick a different tool.
- **Key gotchas**: 3 bullet points on non-obvious behavior (side effects, mutability, performance costs).
- **Minimal example**: 5 lines of code or less.
**Style:**
- Write for a junior developer who understands the language but not this codebase.
- Use active voice. No passive constructions.
- Do not mention the code's internal implementation details unless they affect the caller.
Placeholders: {PASTE_CODE_HERE}. This template shines for internal tools where the reader just needs to know "can I use this, and what breaks?" It works well with GPT-4 and Claude because it demands brevity—something smaller models tend to struggle with.
Template 3: The "Legacy Code" Prompt
This is the hard one—documenting a complex function with side effects, global state, or unclear intent. Use this when the code is a mess and you need the LLM to reverse-engineer the purpose.
You are a code archaeologist. Below is a legacy function with no comments. Infer its behavior and document it.
**Code:**
{PASTE_CODE_HERE}
**Context:** This is part of a {SYSTEM_DESCRIPTION} system. It was written {TIME_PERIOD} and has {NUMBER} known bugs.
**Documentation Required:**
1. **Inferred Purpose**: What the function *actually* does, based on side effects and call sites (not just the name).
2. **State Mutation**: List every piece of external state (globals, files, DBs) this function touches.
3. **Dependency Chain**: What must be true before this runs, and what breaks if it doesn't.
4. **Risk Assessment**: Rate the function 1-5 on "refactor risk" and explain why.
5. **Refactoring Suggestion**: One concrete, minimal change that would improve readability without changing behavior.
**Output Format:**
- Use a numbered list matching the sections above.
- If you cannot infer something, write "UNKNOWN" explicitly—do not guess.
- Keep the tone neutral and factual; this is forensic analysis, not marketing.
Placeholders: {PASTE_CODE_HERE}, {SYSTEM_DESCRIPTION} (e.g., "payment processing"), {TIME_PERIOD} (e.g., "2018"), {NUMBER}. This prompt works best with DeepSeek or Claude, which handle ambiguity better than Gemini's tendency to pad answers.
How to Adapt These for Your Own Codebase
The templates work out of the box, but you'll get better results with three tweaks. First, paste the call sites alongside the function definition—LLMs infer intent better when they see how the function is used. Second, add a "constraints" line specific to your project, like "Use British English" or "Reference the existing types in src/types.ts". Third, for large files, chunk the code into logical blocks and run the prompt per block; a 500-line function will produce shallow docs compared to a 50-line one.
Do These Prompts Work With Any LLM?
Yes, but with diminishing returns on smaller models. Claude and GPT-4 handle the "Edge Cases" requirement well because they reason about control flow. Gemini tends to produce good structure but misses subtle bugs. DeepSeek is excellent for the legacy code template but sometimes ignores the word limit. For best results, use Template 1 with Claude or GPT-4, Template 2 with any model, and Template 3 with DeepSeek or Claude. If you're using a smaller local model, strip out the "Raises/Throws" section—it'll hallucinate error conditions.
The one adjustment that improves these prompts the most is adding a single sentence: "If any output section is not applicable, write 'N/A' explicitly." This kills the filler text that LLMs love to generate, and it forces the model to acknowledge gaps in its understanding rather than inventing details. Apply that to any of the above, and you'll get documentation you can commit without heavy edits.