# Generate docs for undocumented code

Have Claude Code find functions or classes without doc comments and add them in the format and style the file already uses, changing no code.

Paste into: **Claude Code**, started in your project folder

## Prompt template

How the builder on the page fills in this template, so you can do the same:

- `{{key}}` becomes the text entered for that field, exactly as typed. Empty text, or text that is only whitespace (spaces, tabs or line breaks), counts as empty: a required field then becomes `[fill in: <label>]` with its label, and an optional field becomes nothing.
- For a choice field, `{{key}}` becomes the text of the chosen option, or of the default when none is chosen.
- Text between `{{#key}}` and `{{/key}}` stays only when that field is not empty; a choice field always counts as filled. The markers themselves are removed, and a marker that stands alone on its line takes its line break with it.
- Each value is inserted once, as it is: `{{…}}` inside a value stays as typed.

```text
Find {{scope}} without {{format}} comments and add them, matching the style already used in the file.
{{#include}}
Each comment should cover: {{include}}
{{/include}}

Rules:
- Change comments only. Do not change code, signatures, imports or formatting. If code looks wrong, note it in your report instead of fixing it.
- Describe what the code does, read from its body and its callers, not what its name suggests.
- Follow the existing comments in the same file. If the file has none, follow the closest file in the same folder that does, and tell me which one.
- Leave existing comments as they are, even incomplete ones. List any that look out of date.
- When you cannot tell what something is for, do not guess. Skip it and list it as a question.
- Run the project's linter or type checker{{#check}} with: {{check}}{{/check}} and confirm it still passes. Do not commit.

Report:
1. Each item you documented: file and name.
2. Items you skipped, and why.
3. Existing comments that look out of date.
4. Questions about intent that I should answer.
```

## Fields

- `{{scope}}` (required): What to document. A folder, file or kind of symbol. Narrow scopes give comments you can review in one sitting.
- `{{format}}` (required): Comment format. For example JSDoc, Python docstrings, Javadoc or Go doc comments.
- `{{include}}`: What each comment must cover. Optional. Leave empty to follow what existing comments in the file cover.
- `{{check}}`: Lint or docs command. Optional. A linter, type checker or docs build that should still pass.

This site doesn't run Claude or show model output. Results depend on your input and the model you use.

## When to use this template

- A module has grown without doc comments and you want them added in one pass, in the format the rest of the codebase already uses.
- You are preparing code for other teams to call, such as a shared library or a public API, and its functions need parameter and return descriptions.
- Your editor or docs generator reads these comments, and missing ones leave gaps in hover help or generated reference pages.

## When not to use it

- You need explanatory documentation such as a guide, a README or an architecture overview. Doc comments describe single functions; ask for that document directly.
- The code is about to be rewritten. Comments written now will describe behavior that is going away.
- You want the code itself cleaned up at the same time. Keep that separate; mixing comment and code changes makes the diff harder to review.

## Why this structure

- The scope and format fields come straight from the opening request. Naming both tells Claude exactly what counts as missing, so it does not document everything or invent a new comment style.
- Matching the style already used in the file keeps the new comments consistent with the old ones, and the fallback to the closest documented file covers files that have none yet.
- The comments-only rule keeps the diff easy to review: every changed line is a comment, so you can approve it quickly. Code problems come back as notes instead of silent fixes.
- Asking Claude to describe what the code does, read from the body and callers, guards against comments that repeat the function name or describe intended behavior the code does not have.
- The skip-and-ask rule asks Claude to leave unclear intent undocumented and list it for your review in the questions section. A wrong comment misleads more than a missing one.
- Running the linter or type checker gives Claude a check, since malformed doc comments can break docs builds or type checks in some setups.

## Example input (fictional)

What to document:

```
the exported functions in lib/billing/
```

Comment format:

```
TSDoc
```

What each comment must cover:

```
parameters, return value, errors thrown, and one short usage example
```

Lint or docs command:

```
npm run lint
```

## Follow-ups to send Claude

- Now check the new comments against the code once more and list any that describe behavior the code does not have.
- Add a short module-level comment at the top of each file in src/auth/ that says what the file is responsible for.
- Write the comment conventions you followed into CLAUDE.md in two or three lines, so later sessions use them without being told.

## Common mistakes

- Choosing a scope that is too wide, such as the whole repository. The diff becomes too large to read, and unread comments are where mistakes survive.
- Accepting comments without spot-checking them against the code. Read a few, especially for functions with side effects or error cases.
- Leaving the format empty or vague. "Add docs" can produce block comments, docstrings or a README section; name the exact format.

## Related templates

- [Get oriented in a new codebase](https://awesomeclaudeprompts.com/prompts/codebase-overview/): Ask Claude Code to map an unfamiliar repository: its architecture, key directories, how the parts connect, and where to start for your task.
- [Build something new from an existing pattern](https://awesomeclaudeprompts.com/prompts/follow-code-pattern/): Point Claude Code at code that already works the way you want, so the new feature matches its structure, naming, tests and error handling.
- [Draft a document from past examples](https://awesomeclaudeprompts.com/prompts/draft-from-past-examples/): Point Claude Code at a folder of finished documents so it learns their structure and voice, then drafts a new one with gaps marked instead of invented.

## Sources

- [Claude Code docs: Prompt library](https://code.claude.com/docs/en/prompt-library) (Anthropic documentation)
- [Claude Code docs: Common workflows, handle documentation](https://code.claude.com/docs/en/common-workflows#handle-documentation) (Anthropic documentation)

---

Awesome Claude Prompts is an independent project. It is not affiliated with, endorsed by, or sponsored by Anthropic. Claude is a trademark of Anthropic, PBC.