# Bolt.new Prompts for Code Documentation Comments: Ideas That Actually Work > source: https://promptsio.com/bolt-new-prompts-code-documentation-comments/ > published: 2026-10-06T17:51:26+00:00 > updated: 2026-10-06T17:51:26+00:00 > topic: Coding & Tech Prompt templates for getting Bolt.new to add accurate JSDoc, TSDoc and docstring-style comments to your project, with a review checklist so the comments stay truthful. Code comments are the first thing teams skip and the first thing they miss six months later. If you build in an AI app builder, you can close that gap quickly. These **Bolt.new prompts for code documentation comments** help you generate consistent doc comments across a project, without turning your files into walls of noise. A warning that applies to every prompt below: AI-written comments describe what the model believes the code does. They can be wrong, outdated or overconfident. Treat every generated comment as a draft and review it against the actual behaviour before you commit it. ## How Bolt.new Fits Documentation Work Bolt.new is an AI tool that builds and edits web projects from natural-language prompts inside the browser. Its main job is generating and changing code, so documentation is a task you give it rather than a dedicated feature. Because it can see your project files, you can ask it to add comments to specific files or functions while leaving the logic untouched. Check the tool's current features and limits, since capabilities change. The key risk is scope creep: a loosely worded prompt may refactor code while "documenting" it. Every prompt here therefore says explicitly: comments only, no behaviour changes. ## A Prompt Formula for Documentation Comments | Element | What to specify | |---|---| | Scope | Which file, folder or function | | Language and style | JavaScript with JSDoc, TypeScript with TSDoc, Python docstrings | | Contents | Description, params, returns, throws, examples | | Tone | Concise, neutral, present tense | | Guardrails | No logic changes; do not invent behaviour | | Output | Show a diff or list of changed files | ## Basic Prompt vs Improved Prompt **Basic prompt:** ``` Add comments to my code. ``` You may get restated-the-obvious comments such as "// increment i", inconsistent style, or unwanted edits. **Improved prompt:** ``` In the file [FILE PATH], add TSDoc comments to every exported function and type. For each function include a one-sentence summary in the present tense, @param tags with the purpose and expected range of each argument, @returns describing the value and when it can be null or undefined, and @throws for errors that are thrown explicitly in the code. Do not change any code logic, names or formatting. Do not add comments to trivial getters. If you cannot tell what something does from the code, add a "TODO: confirm" note instead of guessing. List every function you documented at the end. ``` It sets a language, a scope, a content checklist, a guardrail against invention and a summary you can audit. ## File and Function Level Prompts ### Prompt 1: Exported function docs in TypeScript ``` Open [FILE PATH] and add TSDoc blocks above each exported function. Include a one-line summary, @param entries with type context and units where relevant (for example milliseconds or pixels), @returns, and one short @example showing realistic usage. Keep the tone neutral and concise. Do not modify code, imports or whitespace outside the comment blocks. Afterwards list any function where the behaviour was unclear to you. ``` Asking for units catches a class of bugs that comments are great at preventing. ### Prompt 2: JSDoc for plain JavaScript ``` Add JSDoc comments to all functions in [FILE PATH]. Use @param {type} name - description, @returns {type} description and @throws where explicit. Infer types only from clear evidence in the code; otherwise use {*} and add a TODO. Describe why the function exists rather than repeating what each line does. Keep each description under 25 words and do not alter any logic. ``` The "why not what" instruction is what separates useful comments from noise. ### Prompt 3: Python docstrings ``` For every public function and class in [FILE PATH], add Google-style Python docstrings with Args, Returns, Raises and a short Example where useful. Use present tense and avoid restating the function name. Do not change type hints, logic or formatting. Flag any function that has side effects, such as network calls or file writes, with a "Side effects:" line. ``` Swap "Google-style" for NumPy or reStructuredText if your project follows another convention. ### Prompt 4: React component documentation ``` Document the React components in [FOLDER PATH] with JSDoc blocks. For each component describe its purpose, list each prop with type, whether it is required, default value and effect, and note any context providers or hooks it depends on. Add a short usage example in the comment. Do not touch JSX, styling or state logic. Use a neutral, developer-to-developer tone. ``` Props are where components most often confuse new team members. ## Complex Logic and Edge Cases ### Prompt 5: Explaining tricky logic inline ``` In [FILE PATH], find functions that contain non-obvious logic such as regular expressions, bit operations, date arithmetic, caching or retry loops. Add inline comments that explain the intent and any edge cases, not the syntax. Keep each comment to one or two lines. Do not comment self-explanatory lines. Leave code unchanged and list the places you commented. ``` ### Prompt 6: Documenting assumptions and edge cases ``` For each function in [FILE PATH] that handles user input or external data, add a "Edge cases" section to its doc comment listing how it behaves with empty input, null values, very large values and invalid formats, based only on what the code actually does. If the code does not handle a case, write "Not handled" rather than describing ideal behaviour. Do not modify logic. ``` This one is valuable because it reveals gaps, which is documentation doing a testing job. ### Prompt 7: API route documentation ``` Add doc comments above each API route handler in [FILE PATH] describing the HTTP method, path, expected request body or query parameters, response shape, status codes returned and any authentication requirement visible in the code. Use a consistent template for every route. Do not invent endpoints or fields that do not appear in the code. ``` ## Project-Level Documentation ### Prompt 8: A module header comment ``` At the top of each file in [FOLDER PATH], add a short header comment (3 to 5 lines) stating the module's responsibility, its main exports and which other modules it depends on. Keep it factual, do not include author names or dates, and do not change any code. ``` ### Prompt 9: Deprecated and TODO audit ``` Scan [FOLDER PATH] for TODO, FIXME and HACK comments. Rewrite each into a consistent format: "TODO(reason): what needs to happen and why". Do not remove any of them and do not resolve them. Give me a table of every item with file, line and a one-line summary. ``` ### Prompt 10: Style guide enforcement ``` Review the existing doc comments in [FOLDER PATH] and align them to this style: present tense, no "this function" openers, params documented in the order they appear, and no trailing periods on tags. Edit only comment text. List the comments you changed and quote one before-and-after example. ``` ## Multi-Step Workflow: Document, Verify, Tighten Run these in sequence rather than in one request. **Step 1: Draft** ``` Add [JSDoc/TSDoc] comments to [FILE PATH] following the rules above. Do not change code. Mark uncertain statements with "TODO: confirm". ``` **Step 2: Verify** ``` Re-read the comments you just wrote against the code in [FILE PATH]. List any comment that could be inaccurate, incomplete or misleading, and explain why. Fix only those comments. ``` **Step 3: Tighten** ``` Shorten any comment that restates the code. Remove comments that add no information. Show me the final diff summary of removed and shortened comments. ``` ## Reviewing the Output Always check generated comments by hand: - Does each @param match the real parameter name and order? - Does @returns describe what the code returns in every branch? - Are there claims about performance, security or side effects that the code does not support? - Did the code itself change? Compare the diff, since comment-only changes should not touch logic. - Do tests still pass? ## Tips and Common Mistakes - **Scope small.** One file or folder per prompt gives easier reviews. - **Name your convention.** Say JSDoc, TSDoc or Google-style rather than "standard". - **Ask for TODO markers over guesses.** Honest gaps beat polished errors. - **Do not comment everything.** Over-commenting adds maintenance cost. - **Common mistake:** letting the model rename or tidy code while documenting. - **Common mistake:** copying comments without running through the review checklist. ## FAQ ### Can Bolt.new document an entire project at once? You can try, but smaller scopes produce more reliable results and easier reviews. Work folder by folder. ### Will AI comments always be accurate? No. They can misread intent, miss side effects or describe behaviour the code does not have. Review every comment. ### Which comment style should I use? Match your language and team conventions: JSDoc or TSDoc for JavaScript and TypeScript, docstrings for Python. ### Should I document private functions? Often a short summary is enough. Reserve detailed docs for exported APIs and tricky logic. ## Conclusion The best **Bolt.new prompts for code documentation comments** are specific about language, style and guardrails, and they ask the model to flag uncertainty. Start with one file, use the verify step, and review the diff before accepting. For related ideas, see our guide on [using AI to optimise your CRM workflow](https://promptsio.com/how-to-use-ai-to-optimize-your-crm-workflow/) and [AI prompts for workflow automation](https://promptsio.com/ai-prompts-for-workflow-automation/). --- Published by Promptsio. Canonical version: https://promptsio.com/bolt-new-prompts-code-documentation-comments/