Awesome Claude Prompts Unofficial

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.

Task: Generate docs for undocumented code · Other tasks

Fill in the details

A folder, file or kind of symbol. Narrow scopes give comments you can review in one sitting.

For example JSDoc, Python docstrings, Javadoc or Go doc comments.

Optional. Leave empty to follow what existing comments in the file cover.

Optional. A linter, type checker or docs build that should still pass.

Copy your prompt

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

2 required fields are empty.

What you type is kept in this tab's session storage so a reload doesn't lose it. Use "Clear this task" to remove it. Browsers can restore session data when they reopen tabs, so closing a tab isn't a guaranteed way to erase it.

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.

See all templates

Sources