Prompt: Write Documentation for a Function or Module
A prompt for clear reference documentation — parameters, return values, edge cases and a usage example — generated from the actual code.
You are a technical writer producing reference documentation for other developers who'll use this code.
Objective: Write documentation for the function or module below, written in {{LANGUAGE}}.
Context: Where this documentation will be used: {{DOCUMENTATION TARGET — e.g. README, internal wiki, docstring}}.
Constraints:
- Document only behaviour visible in the code — do not invent parameters, return types or side effects not present
- Include: purpose, parameters (with types), return value, at least one documented edge case or error condition, and one usage example
- Flag any parameter or return path whose behaviour is ambiguous from the code as "needs confirmation"
- Match the output format to the documentation target (Markdown for README/wiki, docstring format for inline)
Output format: Return the documentation formatted for {{DOCUMENTATION TARGET}}, with a short usage example in a fenced code block.
Before finishing, check every documented parameter and return value against the code, and confirm no invented behaviour was added.
Code:
```
{{PASTE CODE HERE}}
```
Example
Input
LANGUAGE: JavaScript
DOCUMENTATION TARGET — e.g. README, internal wiki, docstring: README
PASTE CODE HERE:
function chunkArray(items, size) {
if (size <= 0) throw new Error("size must be positive");
const result = [];
for (let i = 0; i < items.length; i += size) {
result.push(items.slice(i, i + size));
}
return result;
}
Output
### `chunkArray(items, size)`
Splits an array into consecutive sub-arrays ("chunks") of a given maximum size.
**Parameters**
- `items` (`Array`) — the array to split. Behaviour on a non-array input needs confirmation, as the code doesn't validate this.
- `size` (`number`) — the maximum length of each chunk. Must be a positive number. Behaviour for a non-integer `size` (e.g. `1.5`) needs confirmation, as the code only checks that it is greater than zero.
Show more
**Returns** - `Array<Array>` — an array of chunks. If `items` is empty, returns an empty array. The final chunk may be shorter than `size` if `items.length` isn't evenly divisible. **Errors** - Throws an `Error` with the message `"size must be positive"` if `size` is zero or negative. **Example** ```js chunkArray([1, 2, 3, 4, 5], 2); // => [[1, 2], [3, 4], [5]] ```
Why it works
- Restricting documentation to visible behaviour stops the model inventing parameter validation or error handling the code doesn't actually have.
- Requiring a documented edge case forces reasoning about boundary conditions like empty input, not just the happy path.
- Flagging ambiguous behaviour as 'needs confirmation' turns unclear code into a visible task instead of a silently wrong assumption in the docs.
Why the basic version fails
“Document this function” often produces documentation that reads well but quietly invents a validation check, a return type, or an error condition the code doesn’t actually have — because it sounds like what a well-written function should do, not what this one actually does. That mismatch causes real bugs for whoever trusts the docs later.
What this prompt fixes
Restricting the documentation to behaviour visible in the code stops the model inventing plausible-sounding validation or side effects. Requiring a documented edge case, such as an empty input or an invalid argument, forces the model to reason about boundary conditions instead of only describing the happy path. Flagging genuinely ambiguous behaviour as “needs confirmation” turns an unclear spot in the code into a visible task for the author to resolve, rather than a silently wrong guess baked into the docs.
Tips per model
- Claude tends to be conservative about undocumented behaviour, flagging it rather than guessing, which is the safer default for reference docs.
- ChatGPT produces clean, well-formatted Markdown quickly — check it hasn’t smoothed over an edge case the code doesn’t actually handle.
- Paste the real function including any error handling — documentation generated from a simplified version misses exactly the edge cases developers need documented.