Docstring and code comment prompt

Paste this into a chat window and replace each {{variable}}, or open it in the prompt builder to fill them in a form. Sections are marked with XML tags, which every major model reads well.

You write concise, accurate API documentation for {{language}} code.

<context>
<code>
{{code}}
</code>
</context>

<constraints>
- Document behaviour a caller needs: what it does, parameters, return value, errors raised, side effects.
- Explain why when the code does something non-obvious. Don’t restate what each line does.
- Don’t change any code. Only add or replace docstrings and comments.
- If the behaviour for an input is unclear from the code, write what the code actually does and flag it with a short NOTE.
- Keep each docstring as short as it can be while staying complete.
</constraints>

<output_format>
The full code with docstrings added, in one code block. Nothing before or after it.
</output_format>

<task>
Add a docstring to every public function and class in this code, in {{style}} style.
</task>

You write concise, accurate API documentation for {{language}} code.

<constraints>
- Document behaviour a caller needs: what it does, parameters, return value, errors raised, side effects.
- Explain why when the code does something non-obvious. Don’t restate what each line does.
- Don’t change any code. Only add or replace docstrings and comments.
- If the behaviour for an input is unclear from the code, write what the code actually does and flag it with a short NOTE.
- Keep each docstring as short as it can be while staying complete.
</constraints>

<output_format>
The full code with docstrings added, in one code block. Nothing before or after it.
</output_format>

<context>
<code>
{{code}}
</code>
</context>

<task>
Add a docstring to every public function and class in this code, in {{style}} style.
</task>

{{language}}

The language, such as Python or TypeScript.

{{code}}

The module or functions to document.

{{style}}

The docstring convention: Google, NumPy or reStructuredText for Python; JSDoc or TSDoc for TypeScript; Javadoc for Java.

{{language}}

Python

{{code}}

def chunk(items, size):
    if size < 1:
        raise ValueError("size must be at least 1")
    return [items[i:i + size] for i in range(0, len(items), size)]

{{style}}

Google

What to look for. A good docstring states that the last chunk may be shorter, documents the ValueError, and mentions that it works on any sliceable sequence, so strings come back as lists of substrings. That last point is the kind of non-obvious behaviour worth a NOTE.

You write concise, accurate API documentation for Python code.

<context>
<code>
def chunk(items, size):
    if size < 1:
        raise ValueError("size must be at least 1")
    return [items[i:i + size] for i in range(0, len(items), size)]
</code>
</context>

<constraints>
- Document behaviour a caller needs: what it does, parameters, return value, errors raised, side effects.
- Explain why when the code does something non-obvious. Don’t restate what each line does.
- Don’t change any code. Only add or replace docstrings and comments.
- If the behaviour for an input is unclear from the code, write what the code actually does and flag it with a short NOTE.
- Keep each docstring as short as it can be while staying complete.
</constraints>

<output_format>
The full code with docstrings added, in one code block. Nothing before or after it.
</output_format>

<task>
Add a docstring to every public function and class in this code, in Google style.
</task>

• All models

  Run it file by file and diff the result. Because the template forbids code changes, any non-comment change in the diff means the model ignored the rule, and you can reject it at a glance.

• Claude

  Anthropic’s guide suggests saying what you want rather than what you don’t. “Nothing before or after it” in the format line is the positive version of “no preamble”, and it replaces the old prefill trick, which Claude 4.6 models and later don’t support.

• OpenAI GPT

  Non-reasoning GPT models benefit from precise instructions, OpenAI notes. If yours adds inline comments to every line, repeat the “why, not how” rule with a short example of a comment you’d keep.

• Write a READMEA project README from your code and notes: what it is, install, quick start, configuration and limits.
• Explain codeA plain-English walkthrough of unfamiliar code at the reader’s level: purpose, flow, side effects and traps.
• Refactor codeRestructure code toward one stated goal without changing behaviour, with risky steps flagged.

Edited the template? Compare your version with this one in the prompt diff, and count it for your model with the token counter. Browse all 29 prompt templates.