VIBE CODING / AI-ASSISTED DEVELOPMENT
Search or filter 23 reusable, copy-ready prompt templates for common coding tasks — debugging, refactoring, test generation, code review, documentation, and planning.
23 templates
Walks the model through reproducing a bug systematically before proposing a fix.
You are debugging {{language/framework}}.
Bug: {{describe the observed behavior}}
Expected: {{describe the expected behavior}}
Steps to reproduce: {{steps}}
Relevant code:
{{paste code}}
First, identify the most likely root cause and explain your reasoning. Then propose a minimal fix. Do not change unrelated code. Gets a plain-English explanation of an error plus the likely fix location.
Explain this stack trace in plain English, then point to the most likely file/line where the root cause lives.
Stack trace:
{{paste stack trace}}
Relevant code context:
{{paste code, if known}}
Do not suggest a fix yet — first confirm the root cause. Structures a hypothesis-driven investigation for bugs that don't reproduce consistently.
This bug is intermittent: {{describe symptom}}.
It happens roughly {{frequency}} under {{conditions}}.
List 3-5 plausible root causes ranked by likelihood (race condition, caching, external dependency timing, etc.), and for each one suggest a specific way to confirm or rule it out. Breaks an overgrown function into smaller, well-named pieces without changing behavior.
Refactor this function to be easier to read and test, without changing its external behavior.
{{paste function}}
Extract logical sub-steps into separate, well-named functions. Keep the public signature the same. List what you extracted and why. Identifies repeated logic across multiple files and proposes a shared abstraction.
These files contain similar/duplicated logic:
{{paste file 1}}
{{paste file 2}}
Identify the duplicated logic, propose a shared function/module to extract it into, and show the resulting versions of both files using that shared code. Updates older language patterns to current idioms without altering behavior.
Update this {{language}} code to use current idiomatic syntax (e.g. {{examples: async/await instead of callbacks, const/let instead of var}}), while preserving exact behavior.
{{paste code}}
Explain each change you made and why it's safer or clearer. Plans a safe rename of a poorly-named variable, function, or type.
I want to rename {{current name}} to {{new name}} because {{reason}}.
Here's where it's used:
{{paste usages or file list}}
List every place this needs to change, flag any risk of breaking a public API or external contract, and show the renamed code. Generates focused unit tests covering the main success path of a function.
Write unit tests for this function using {{test framework}}.
{{paste function}}
Cover the main happy-path behavior first, then add one test for a boundary/edge case. Use clear, descriptive test names. Focuses specifically on boundary conditions and failure modes, not the happy path.
For this function, list the edge cases that are most likely to break it (empty input, null, max length, concurrent calls, etc.), then write a test for each using {{test framework}}.
{{paste function}} Covers a multi-step user flow end to end rather than a single function.
Write an integration test for this user flow using {{test framework}}: {{describe the flow, e.g. "user signs up, verifies email, logs in"}}.
Relevant endpoints/components:
{{paste relevant code or API routes}}
The test should cover the full happy path and one realistic failure (e.g. invalid input at one step). Sets up realistic mocks for a third-party API or service so tests run reliably.
This code calls an external service:
{{paste code that makes the external call}}
Write tests using {{test framework}} that mock this dependency so the tests are deterministic and don't require network access. Cover both a successful response and a failure/timeout response from the mock. Focuses a review specifically on security-relevant concerns rather than style.
Review this diff specifically for security issues (injection, auth bypass, secrets in code, unsafe deserialization, etc.) — ignore style and naming.
{{paste diff}}
For each issue found, explain the risk and suggest a fix. If nothing concerning is found, say so explicitly. Produces a concise PR description from a diff to speed up human review.
Summarize this diff for a pull request description: what changed, why (based on context given), and what a reviewer should pay closest attention to.
Context: {{why this change is being made}}
{{paste diff}}
Keep it under 200 words. Flags likely performance bottlenecks before they reach production.
Review this code for performance issues (N+1 queries, unnecessary re-renders, unbounded loops, missing indexes, etc.).
{{paste code}}
For each issue, estimate its likely impact and suggest a fix. Don't flag micro-optimizations that wouldn't matter in practice. Sanity-checks a proposed API shape before implementation, not after.
Review this proposed API design before I implement it:
{{paste endpoint list / request-response shapes}}
Check for: consistent naming, sensible HTTP methods/status codes, missing pagination or filtering, and any breaking-change risk if this evolves later. Suggest concrete changes. Documents a feature for other contributors in the project's existing README style.
Write a README section documenting this feature: {{feature name and what it does}}.
Relevant code/config:
{{paste code or config}}
Match the tone and structure of this existing README excerpt:
{{paste an existing section for style reference}} Turns endpoint code into structured reference docs with examples.
Generate API reference documentation for this endpoint: method, path, parameters, request/response shape, and possible error codes.
{{paste endpoint code}}
Include one example request and one example response. Adds comments explaining the "why," not restating the "what."
Add comments to this code explaining the non-obvious "why" behind each significant decision — do not add comments that just restate what the code already says.
{{paste code}} Produces step-by-step setup instructions a new contributor can follow.
Write a step-by-step local setup guide for a new contributor to this project.
Stack: {{tech stack}}
Key commands: {{install, run, test commands}}
Known gotchas: {{anything that commonly trips people up}}
Assume the reader has general dev experience but no context on this specific project. Forces explicit scoping decisions before implementation starts.
I want to build: {{one-sentence feature description}}.
Help me scope it before I start: what's the smallest version that delivers real value, what should explicitly be deferred, and what open questions do I need to answer first? Lays out trade-offs between two or more technical approaches before committing.
I'm deciding between these approaches for {{problem}}:
Option A: {{describe}}
Option B: {{describe}}
Compare them on {{criteria: complexity, performance, maintainability, cost}}. Recommend one for my context: {{describe your constraints/priorities}}. Sequences a risky migration into safe, reversible steps.
I need to migrate {{what: e.g. "from library X to Y", "database schema change"}}.
Current state: {{describe}}
Constraints: {{e.g. zero downtime, can't break existing API consumers}}
Propose a step-by-step migration plan that keeps the system working at every intermediate step, with a rollback option at each stage. Structures a blameless postmortem from raw incident notes.
Draft a blameless postmortem from these incident notes:
{{paste timeline/notes}}
Structure it as: summary, timeline, root cause, impact, and 2-4 concrete follow-up action items with owners left as placeholders. No templates match your search. Try a different keyword or clear the category filter.
Type a keyword to match a template's title, description, or content, or use the category pills — Debugging, Refactoring, Test generation, Code review, Documentation, Planning — to narrow the list.
Each card shows the template's purpose and a preview of the prompt text, with placeholders like {{language/framework}} marking what you fill in for your own context.
Click "Copy template" to copy the full prompt to your clipboard, then paste it into ChatGPT, Claude, Cursor, or whichever AI coding assistant you use, and fill in the placeholders.
Continue learning: Prompt engineering for AI MVPs: what founders should test · How to write a strong first prompt for Lovable AI
No. This is a static library — everything runs client-side in your browser. Search and filtering are plain string matching; nothing is sent anywhere.
Any general-purpose AI assistant — ChatGPT, Claude, Cursor, GitHub Copilot Chat, and similar. The templates use plain-text placeholders, not tool-specific syntax.
Yes. Copying puts the raw template text on your clipboard, including the {{placeholder}} markers — replace them with your own details before sending it to your AI tool.
They cover the coding tasks developers most commonly hand to an AI assistant — reproducing bugs, refactoring, generating tests, reviewing code, writing docs, and planning work — based on common prompt-engineering patterns rather than one-off tricks.
The library may grow over time. Each template is self-contained, so new ones can be added without changing how existing ones work.
| Feature | MVPHub | A personal notes doc of saved prompts | PromptHero-style prompt marketplaces |
|---|---|---|---|
| No account or sign-up required | Included | Included | Not included |
| Curated for coding workflows specifically | Included | Not included | Limited |
| Instant search and category filtering | Included | Not included | Limited |
| One-click copy, no clutter or ads | Included | Included | Not included |
A personal notes doc works but doesn't scale or get discovered by others, and general prompt marketplaces mix in non-coding content and often require an account. MVPHub's library is scoped to coding tasks, searchable, and free to use without sign-up.
Add this tool to your site with the canonical iframe below. It remains hosted and maintained by MVPHub.