Claude Code is the most capable agentic coding tool available in 2026. But like any tool, the results you get are only as good as the instructions you give it. This guide collects 40+ battle-tested prompts across every major use case — debugging, architecture, refactoring, testing, documentation, and full feature implementation.
Every prompt here has been validated to produce significantly better output than a generic ask.
Why Prompts Matter More With Claude Code
Claude Code operates agentically — it doesn't just answer questions, it takes actions: reading files, running commands, editing code, installing packages. A poorly written prompt at the start of a session can cause it to:
- Refactor the wrong files
- Install dependencies you didn't want
- Make architectural assumptions that break other parts of your codebase
- Produce code that works but doesn't match your existing patterns
The prompts below follow a consistent pattern: context → constraint → clear ask.
1. Debugging & Error Fixing
These are the prompts that save the most time day-to-day.
Fix a specific error
I'm getting this error in production:
[PASTE ERROR + STACK TRACE]
The error occurs in `src/api/payments.ts` when processing webhook events from Stripe.
Do NOT modify the database schema or any other files. Only fix the root cause of this error.
Show me what changed and why.
Diagnose a performance issue
The function `processUserBatch()` in `src/workers/sync.ts` is taking 8-12 seconds for batches
of 500 users. It should take under 2 seconds.
Analyze the function and identify all performance bottlenecks.
List the top 3 fixes ordered by expected impact, then implement them.
Don't change the function signature — it's called in 6 other places.
Find the source of a memory leak
Our Node.js server memory usage grows from 200MB to 1.2GB over 6 hours then crashes.
Analyze `src/server/` and `src/workers/` directories for:
1. Event listeners that are never removed
2. Closures that hold references to large objects
3. Intervals or timers that aren't cleared
4. Any caching logic that grows unboundedly
Output a prioritized list of suspects with the file and line number for each.
2. Code Refactoring
Refactor without breaking existing tests
Refactor `src/lib/userService.ts` to:
1. Split it into focused modules: `userAuth.ts`, `userProfile.ts`, `userPermissions.ts`
2. Replace the class-based approach with pure functions
3. Add proper TypeScript types where they're currently missing
Hard constraints:
- All existing tests in `__tests__/userService.test.ts` must continue passing
- Do not change any exported function signatures
- Keep the same file for re-exporting everything so imports in other files don't break
Modernize legacy code
`src/utils/dataProcessor.js` was written in 2019 with callbacks and no types.
Modernize it by:
1. Converting to TypeScript
2. Replacing all callbacks with async/await
3. Adding proper error handling with typed errors
4. Adding JSDoc comments to all exported functions
Do NOT add any new dependencies. Use only what's already in package.json.
Extract a reusable hook
In `src/components/Dashboard.tsx`, there is state + effect logic for fetching and caching
paginated data (lines 45-120).
Extract this into a reusable React hook called `usePaginatedFetch` in `src/hooks/`.
The hook must:
- Accept a generic type parameter for the data shape
- Accept the fetch function as a parameter, not call the API directly
- Expose: `data`, `isLoading`, `error`, `page`, `hasNextPage`, `fetchNextPage`
- Handle cleanup on unmount
After creating the hook, update Dashboard.tsx to use it. Don't change the UI output.
3. Writing Tests
Claude Code is exceptional at test generation when given enough context.
Generate comprehensive unit tests
Write complete unit tests for `src/lib/pricing.ts` using Vitest.
The tests must cover:
- All exported functions
- Edge cases: zero values, negative numbers, missing optional fields
- Boundary values: free tier limits, maximum plan limits
- Error cases: invalid input types, missing required fields
Use the existing test patterns from `__tests__/auth.test.ts` as style reference.
Mock any external calls using `vi.mock()`.
Target 100% branch coverage.
Write integration tests
Write integration tests for the `/api/checkout` endpoint in `src/app/api/checkout/route.ts`.
Use the existing Supertest setup from `__tests__/integration/setup.ts`.
Cover these scenarios:
1. Valid request with authenticated user → 200 + session URL
2. Valid request with unauthenticated user → 401
3. Invalid priceId → 400 with validation error
4. Stripe API timeout → 503 with retry-after header
5. Duplicate session request (idempotency) → 200 with existing session
Mock Stripe using `__mocks__/stripe.ts` (already exists).
Add missing edge case tests
Look at `__tests__/cartService.test.ts`.
Identify all the edge cases that are NOT currently tested and add them.
Focus on:
- Concurrent modification scenarios
- Empty state transitions
- Maximum quantity limits
- Discount code combinations
- Currency rounding edge cases
Don't modify existing tests. Only add new `it()` blocks.
4. Architecture & System Design
Design a new feature
I need to add a real-time notification system to our Next.js app.
Current stack: Next.js 15, Supabase (Postgres + Auth), Vercel deployment.
Constraints:
- Must work within Vercel's serverless limits (no persistent connections from API routes)
- Budget: under $50/month at 10,000 DAU
- Must support: in-app toasts, email digests, push notifications (future)
Design the architecture. For each component, specify:
1. What it does
2. Which service/library handles it
3. Why you chose it over alternatives
4. Any tradeoffs I should know about
Do NOT write any code yet. I want to review the design first.
Review and critique existing architecture
Read `src/` and `docs/architecture.md`.
Give me an honest architectural review:
1. What are the 3 biggest architectural risks or bottlenecks?
2. What would break first if we scaled to 10x current traffic?
3. Which parts of the codebase will become the hardest to maintain in 12 months?
Be direct. Don't tell me what's good — I want to know what needs attention.
5. Full Feature Implementation
Build a complete feature from spec
Implement a "saved searches" feature for the directory page.
Spec:
- Users can save any active filter combination with a custom name
- Saved searches appear in a dropdown under the search bar (max 10 per user)
- Saved searches persist in localStorage (no auth required for MVP)
- A saved search can be deleted individually or all cleared at once
- Clicking a saved search applies all its filters immediately
- The dropdown shows when the user has at least 1 saved search
Files to modify: `src/app/[locale]/directory/page.tsx`, `src/components/directory/FilterBar.tsx`
New files to create: `src/hooks/useSavedSearches.ts`, `src/components/directory/SavedSearches.tsx`
Match the existing UI patterns (glass cards, teal accents, Tailwind classes).
Add proper TypeScript types. No new dependencies.
Implement an API endpoint
Create a new API endpoint: `POST /api/compare`
It should:
1. Accept: `{ toolSlugs: string[] }` — 2 to 4 slugs
2. Validate: slugs exist in the tool database, array length 2-4
3. Return: full tool data for each slug, structured for comparison (rating, pricing, highlights)
4. Cache: results in Redis with 1-hour TTL (use the existing `src/lib/redis.ts`)
5. Rate limit: 20 requests/minute per IP (use the existing middleware)
Error responses must follow our existing error format from `src/lib/apiError.ts`.
Add the route to `src/app/api/compare/route.ts`.
Write the handler tests in `__tests__/api/compare.test.ts`.
6. Documentation
Generate inline documentation
Add JSDoc comments to every exported function and type in `src/lib/content.ts`.
Each comment must include:
- @description — what the function does in plain English (1-2 sentences)
- @param — all parameters with their types and what they represent
- @returns — what the function returns
- @throws — any errors it can throw
- @example — a real usage example
Match the documentation style in `src/lib/seo.ts` which is already documented.
Write a README for a module
Write a comprehensive README.md for the `src/lib/` directory.
It should explain:
1. What each file does and when to use it (1 paragraph per file)
2. The dependencies between files (which imports which)
3. How to add a new utility (step-by-step)
4. Common patterns with code examples
Audience: a new developer joining the team with 2+ years of React/TypeScript experience.
7. Security & Code Review
Security audit a specific file
Perform a security audit of `src/app/api/` (all route handlers).
Check for:
1. Missing authentication/authorization checks
2. SQL injection risks (raw query concatenation)
3. Missing input validation or type coercion issues
4. Exposed sensitive data in API responses
5. Missing rate limiting on expensive operations
6. CORS misconfiguration
7. Unsafe use of `eval()` or `new Function()`
For each issue found:
- Severity: Critical / High / Medium / Low
- File + line number
- Explanation of the risk
- Fix recommendation
Don't fix anything yet. I want the report first.
8. Database & Migrations
Write a safe database migration
Write a Postgres migration to add a `subscription_tier` column to the `users` table.
Requirements:
- Type: ENUM ('free', 'pro', 'enterprise')
- Default: 'free'
- NOT NULL
- The migration must be safe to run on a live production database with zero downtime
- Include both `up` and `down` migrations
- Add an index if it will be frequently filtered/joined
File: `migrations/0024_add_subscription_tier.sql`
Follow the format of the existing migrations in `migrations/`.
9. Claude Code Meta-Prompts
These prompts help you get better results from Claude Code itself.
Start a session correctly
Before making any changes, read these files:
- `README.md`
- `src/lib/content.ts` (our data model)
- `src/app/[locale]/directory/page.tsx` (the main page you'll be editing)
Then summarize:
1. What the app does
2. The tech stack (framework, styling, state management)
3. Any patterns or conventions I should know about
4. Questions you have before we start
Wait for my confirmation before touching any file.
Enforce a task scope
Your task is ONLY to add dark mode toggle support to the Navbar component.
Do NOT:
- Modify any page files
- Change any color values in globals.css
- Add new dependencies
- Change the Tailwind config
When you're done, list every file you changed and why.
If you think something else needs to change, tell me — don't do it automatically.
Ask for a plan before execution
I want you to [TASK DESCRIPTION].
Before writing any code:
1. List every file you'll need to read first
2. List every file you'll modify or create
3. Describe your approach in plain English (3-5 sentences)
4. Flag any assumptions you're making that I should confirm
Only start executing once I say "go".
Pro Tips for Better Claude Code Sessions
1. Always define what NOT to do. Claude Code will sometimes "help" by fixing adjacent things it notices. Adding Do NOT modify X prevents scope creep.
2. Reference existing patterns. "Match the style in src/lib/seo.ts" produces much more consistent output than asking for generic code.
3. Ask for the plan before the code. For complex tasks, always add "Don't write code yet, just tell me your approach." Review the plan, then execute.
4. Use checkpoint prompts. After every significant change: "Before continuing, list the files you've changed and verify the tests still pass."
5. Give it real error messages. Claude Code is dramatically better when you paste the actual error + stack trace vs. describing the error in words.
6. Constrain dependencies. Always add "No new dependencies" unless you specifically want new ones. Claude Code will install packages liberally if you don't stop it.
Verdict
The gap between a developer who uses these prompts and one who doesn't is not a small one. Claude Code with sharp, constrained prompts can complete in 20 minutes what would otherwise take hours. The key insight is treating it like a very capable contractor who needs a precise brief — not a mind-reader.
Bookmark this page. The prompts above will continue to be updated as Claude Code itself evolves.