I used to waste hours writing boilerplate, debugging cryptic errors, and writing documentation nobody reads. Now I use these 15 prompts and ship 3x faster.
The difference? Structure. Every prompt below uses the RCTFE framework ā Role, Context, Task, Format, Examples. It's the difference between getting generic slop and getting production-ready output from ChatGPT, Claude, or any LLM.
Copy these. Bookmark this page. Thank me later.
š Code Review Prompts
1. The Security Auditor
Role: You are a senior application security engineer who specializes in OWASP Top 10 vulnerabilities and secure coding practices.
Context: I'm about to merge a pull request for [describe feature]. The codebase is [language/framework]. We handle [type of data ā e.g., user PII, payment info].
Task: Review the following code for security vulnerabilities, injection risks, authentication flaws, and data exposure issues. Flag anything that would fail a security audit.
Format: Return a numbered list. For each issue: (1) severity ā Critical/High/Medium/Low, (2) the specific line or pattern, (3) what the risk is, (4) a concrete fix with code.
Example: "1. HIGH ā Line 23: Raw SQL concatenation ā SQL injection risk. Fix: Use parameterized queries:
db.query('SELECT * FROM users WHERE id = $1', [userId])"
Why it works: Giving the AI a security-specific role and asking for severity ratings forces it to think like an actual auditor ā not just a linter.
2. The Performance Reviewer
Role: You are a staff-level backend engineer who obsesses over performance, memory usage, and time complexity.
Context: This code runs in [production environment ā e.g., Node.js API handling 10K requests/min]. The function below is called on every request.
Task: Identify performance bottlenecks, unnecessary allocations, O(nĀ²) patterns, missing caching opportunities, and redundant computations. Suggest optimizations with benchmarks where possible.
Format: For each finding: (1) what the issue is, (2) estimated performance impact, (3) optimized code snippet, (4) trade-offs of the optimization.
Example: "Repeated
.filter().map()chain ā single.reduce()pass. ~40% fewer iterations for arrays > 1000 elements. Trade-off: slightly less readable."
Why it works: The "called on every request" context tells the AI this is a hot path ā it'll prioritize runtime performance over readability suggestions.
3. The Readability Critic
Role: You are a principal engineer who mentors junior developers and cares deeply about clean, maintainable code.
Context: This code works correctly but was written quickly during a sprint. It needs to be maintained by a team of varying experience levels for years.
Task: Refactor for readability without changing behavior. Focus on: naming, function decomposition, removing cleverness in favor of clarity, adding strategic comments (only where intent isn't obvious from code).
Format: Show a before/after comparison for each refactored section. Explain the why behind each change in one sentence.
Example: "Renamed
dtodaysSinceLastLoginā single-letter variables force readers to hold context in their head."
Why it works: The "maintained by a team of varying experience levels" context steers the AI toward simplicity over cleverness.
š Debugging Prompts
4. The Error Whisperer
Role: You are a senior developer who has debugged thousands of production issues and can read stack traces like a book.
Context: I'm getting the following error in my [language/framework] application. It started after [recent change ā e.g., upgrading a dependency, deploying a new feature]. Environment: [Node 20 / Python 3.12 / etc.].
Task: Analyze this error. Tell me: (1) what's actually happening underneath, (2) the most likely root cause, (3) three possible fixes ranked by likelihood, (4) how to prevent this class of error in the future.
Format: Use headers: "Root Cause Analysis", "Fixes (ranked)", "Prevention". Use code snippets for each fix.
Example error: [paste your full stack trace here]
Why it works: Telling the AI when the error started (after a specific change) massively narrows the search space. Most devs forget to include this.
5. The Rubber Duck That Talks Back
Role: You are a patient, Socratic debugging partner. You don't give answers immediately ā you ask the right questions to lead me to the bug.
Context: I have a bug where [describe the symptom]. I expect [expected behavior] but I'm seeing [actual behavior]. I've already tried [what you've checked].
Task: Ask me 3-5 targeted diagnostic questions that will narrow down the root cause. After I answer, ask follow-up questions or suggest specific things to inspect (variable values, network requests, database state).
Format: Numbered questions. Each question should explain why you're asking it and what the answer would tell us.
Example: "1. Does the bug reproduce with a fresh database? (This tells us if it's a data-dependent issue vs. a code logic issue.)"
Why it works: Sometimes you don't need an answer ā you need better questions. This prompt turns the AI into the debugging partner you wish you had.
6. The Regression Detective
Role: You are a QA engineer who specializes in finding regression bugs ā things that used to work but are now broken.
Context: After merging [PR/commit description], the following feature stopped working: [describe the regression]. Here's the diff of what changed: [paste diff or describe changes].
Task: Analyze the diff and identify which specific change most likely caused the regression. Explain the causal chain from the code change to the broken behavior. Suggest the minimal fix that restores the old behavior without reverting the entire change.
Format: (1) Most likely culprit (specific line/change), (2) Causal chain explanation, (3) Minimal fix with code, (4) Test case that would have caught this.
Example: "The
?.optional chaining on line 47 silently returnsundefinedinstead of throwing ā downstream code assumes a non-null value."
Why it works: Giving the AI the diff and the symptom lets it trace causality ā something that's hard to do manually in large PRs.
š Documentation Prompts
7. The API Doc Writer
Role: You are a technical writer who has written documentation for Stripe, Twilio, and Vercel ā known for clear, developer-friendly docs.
Context: I have an API endpoint/function that I need to document. The code is below. The audience is external developers integrating with our API for the first time.
Task: Write complete documentation including: description, parameters (with types and constraints), return value, error cases, authentication requirements, and rate limits (if applicable).
Format: Use a standard API doc format: endpoint, method, headers, request body (with JSON example), response body (with JSON example), error responses, and a curl example.
Example: Follow the style of Stripe's API docs ā concise, scannable, with copy-pasteable examples.
Why it works: Naming specific companies (Stripe, Twilio) whose docs are industry-leading gives the AI a concrete quality bar to hit.
8. The README Generator
Role: You are a senior open-source maintainer who has onboarded hundreds of contributors to your projects.
Context: I have a [type of project ā CLI tool / library / API / app]. It's built with [tech stack]. The target users are [audience]. Here's the project structure and main entry point: [paste relevant code].
Task: Generate a README.md that would make someone go from "what is this?" to "I have it running" in under 5 minutes. Include: one-line description, badges, install instructions, quick start, API reference (if applicable), configuration, contributing guide, and license.
Format: Standard GitHub README markdown. Use collapsible sections (
<details>) for long sections. Include copy-pasteable commands for every step.Example: "Model it after the README style of
shadcn/uiorzodā minimal, scannable, and gets you started fast."
Why it works: The "5 minutes from 'what is this?' to 'I have it running'" constraint forces the AI to prioritize onboarding speed over exhaustive documentation.
9. The Inline Comment Surgeon
Role: You are a senior developer who writes comments that explain why, never what. You believe the best comment is the one you didn't need to write because the code was clear enough.
Context: This codebase has [too few / too many / outdated] comments. The code below works correctly. The team has varying experience with [relevant domain ā e.g., GraphQL resolvers, WebSocket state machines].
Task: Add, remove, or rewrite inline comments. Only comment where: (1) the code does something non-obvious, (2) there's a business rule that isn't evident from variable names, (3) there's a gotcha future developers will hit. Remove comments that just restate what the code does.
Format: Show the full code with your comment changes. Prefix new/changed comments with
// [NEW]or// [UPDATED]so I can spot them in review.Example:
// [NEW] We retry 3x here because the payment provider returns 503 during their daily maintenance window (2-3am UTC)ā this explains a "why" that isn't obvious from code.
Why it works: The "explain why, never what" instruction prevents the AI from adding noise comments like // increment counter above count++.
šļø Architecture & Design Prompts
10. The System Design Interviewer
Role: You are a principal architect at a company processing millions of requests per day. You've designed systems at scale and can spot architectural mistakes before they become expensive.
Context: I'm building [describe system]. Expected scale: [users, requests, data volume]. Team size: [N developers]. Current tech stack: [list]. Budget constraints: [if any].
Task: Review my proposed architecture and identify: (1) single points of failure, (2) scaling bottlenecks I'll hit first, (3) things that are over-engineered for my current scale, (4) what I should build now vs. defer. Draw a simple ASCII diagram of the recommended architecture.
Format: Use sections: "What's Good", "Red Flags", "Recommended Architecture" (with ASCII diagram), "Build Now vs. Build Later" (two-column table).
Example: "Red Flag: Your monolith handles both real-time WebSocket connections AND batch processing. These have opposite scaling profiles ā separate them."
Why it works: Including team size and budget prevents the AI from recommending a Netflix-scale microservices architecture for a 2-person startup.
11. The Database Schema Reviewer
Role: You are a database architect with 15 years of experience designing schemas for high-traffic applications. You think in terms of query patterns, not just data models.
Context: I'm designing the database for [feature/product]. Primary use cases: [list the 3-5 most common queries]. Expected data volume: [rows/growth rate]. Database: [PostgreSQL / MySQL / MongoDB / etc.].
Task: Review my schema and suggest improvements for: normalization/denormalization trade-offs, indexing strategy, query performance for my primary use cases, potential N+1 query traps, and migration strategy from my current schema.
Format: (1) Schema review with specific issues, (2) Recommended schema (SQL CREATE statements), (3) Index recommendations with EXPLAIN analysis reasoning, (4) Migration plan.
Example: "Your
orderstable is missing a composite index on(user_id, created_at)ā your most common query (SELECT * FROM orders WHERE user_id = ? ORDER BY created_at DESC) is doing a full table scan."
Why it works: Listing your actual query patterns lets the AI optimize for how you use the data, not just how you store it.
12. The Refactoring Strategist
Role: You are a tech lead planning a major refactor. You've migrated codebases from monolith to microservices, from JavaScript to TypeScript, and from REST to GraphQL ā all without stopping feature development.
Context: I want to refactor [describe what ā e.g., move from callbacks to async/await, extract a service, migrate to a new ORM]. The codebase is [size ā files/lines]. We can't stop shipping features during the refactor. Team has [N] developers.
Task: Create a step-by-step refactoring plan that: (1) can be done incrementally in PRs that each take < 1 day, (2) never leaves the codebase in a broken state, (3) includes a rollback strategy at each step, (4) has clear "done" criteria.
Format: Numbered phases. Each phase has: scope (what files/modules), changes, PR description, rollback plan, and "done when" criteria. Include a Gantt-style ASCII timeline.
Example: "Phase 1: Add TypeScript config and rename 5 leaf-node utility files to .ts. Zero behavior change. Rollback:
git revert. Done when: CI passes and all imports resolve."
Why it works: The "never leaves the codebase broken" and "< 1 day per PR" constraints force the AI to think incrementally, which is how real refactors succeed.
ā Testing Prompts
13. The Edge Case Finder
Role: You are a QA engineer with an adversarial mindset. Your specialty is finding edge cases that developers miss ā boundary values, race conditions, unicode issues, timezone bugs, and empty state failures.
Context: Here's a function/endpoint that handles [describe behavior]. The inputs are: [list parameters with types]. It's used in [production context].
Task: Generate a comprehensive list of edge cases and test scenarios, categorized by: boundary values, invalid inputs, concurrency issues, state-dependent behavior, and environment-specific issues (timezones, locales, OS differences). For each, explain why it might fail.
Format: Categorized table with columns: Category, Test Case, Input, Expected Behavior, Why It Might Fail.
Example: "Boundary: Empty string for
usernameā the validation regex.+passes but the database has a NOT NULL constraint with no DEFAULT, causing a 500 instead of a 400."
Why it works: The categorization forces the AI to systematically cover different failure modes instead of just listing obvious nulls and empty strings.
14. The Test Writer
Role: You are a developer who writes tests that serve as documentation ā each test name reads like a specification, and the arrange/act/assert structure is immediately clear.
Context: Testing framework: [Jest / pytest / Go testing / etc.]. The code under test is [paste function or describe behavior]. We use [mocking library if any]. Code coverage target: [percentage if relevant].
Task: Write a complete test suite covering: happy path, error cases, edge cases, and integration points. Each test should be independent (no shared mutable state between tests). Use descriptive test names that read like sentences.
Format: Full test file, ready to copy-paste and run. Group related tests with
describeblocks (or equivalent). Include setup/teardown if needed. Add a brief comment above each test group explaining what aspect is being tested.Example test name:
it('returns 404 when the user exists but has been soft-deleted')ā specific about the scenario and the expected outcome.
Why it works: "Test names that read like specifications" produces self-documenting tests. Six months from now, a failing test name tells you exactly what broke.
15. The Mocking Strategist
Role: You are a testing consultant who helps teams write tests that are fast, reliable, and not brittle. You know when to mock and ā more importantly ā when NOT to mock.
Context: I need to test [describe function/module] which depends on [list external dependencies ā APIs, databases, file system, etc.]. Framework: [Jest / pytest / etc.]. We're experiencing [problem ā e.g., flaky tests, slow CI, tests that pass locally but fail in CI].
Task: Recommend a mocking strategy: what to mock, what to use real implementations for, and what to use test doubles (fakes/stubs) for. Explain the trade-off for each decision. Then write the mock setup code.
Format: (1) Decision table: Dependency ā Mock/Fake/Real ā Reason. (2) Mock setup code. (3) Common pitfalls with this mocking approach and how to avoid them.
Example: "Don't mock the database ā use a real test database with transactions that rollback. Mock the payment API ā it's slow, costs money, and has rate limits. Use a fake for the email service ā you want to assert on sent emails without actual delivery."
Why it works: Most testing problems come from mocking too much or too little. This prompt forces a deliberate decision for each dependency.
The Pattern Behind All 15 Prompts
Notice what every prompt has in common:
- A specific role ā not "helpful assistant" but "senior security engineer" or "QA engineer with an adversarial mindset"
- Rich context ā your tech stack, scale, team size, recent changes
- A precise task ā not "review my code" but "identify performance bottlenecks and suggest optimizations with benchmarks"
- A defined format ā tables, numbered lists, before/after comparisons, severity ratings
- Concrete examples ā showing the AI what "good output" looks like
This is the RCTFE framework (Role, Context, Task, Format, Examples), and it works across every AI model ā ChatGPT, Claude, Gemini, Llama, and everything else.
Get 150+ More Structured Prompts
These 15 prompts are a taste. PromptCraft Pro contains over 150 ready-to-use RCTFE prompts for business, marketing, development, and strategy ā each one structured, tested, and designed to produce output you can actually use.
Pay what you want (from $1): Get PromptCraft Pro on Gumroad
No fluff. No theory. Just prompts that work.
Top comments (11)
Some comments may only be visible to logged-in visitors. Sign in to view all comments.