Battle-tested prompts that turn Claude into a powerful coding assistant. From debugging to architecture, these prompts will accelerate your development workflow.
I'm getting this error: [ERROR]. Here's the relevant code: [CODE]. Walk me through what's happening step by step, identify the root cause, and suggest a fix. Explain why the fix works.
Why this works: Forces Claude to trace execution rather than guess, leading to more accurate debugging.
Review this code as a senior engineer. Focus on: 1) correctness bugs, 2) security vulnerabilities, 3) performance issues, 4) maintainability concerns. For each issue, explain the risk and suggest a specific fix. Code: [CODE]
Why this works: The prioritized categories ensure Claude doesn't just nitpick style — it catches real issues.
Write comprehensive tests for this function/module: [CODE]. Include: unit tests for happy path, edge cases (null, empty, boundary values), error cases, and integration-level tests if applicable. Use [TESTING FRAMEWORK].
Why this works: Specifying test categories prevents Claude from writing only happy-path tests.
Refactor this code to improve readability and maintainability. Requirements: 1) preserve all existing behavior, 2) don't change the public API, 3) explain each change and why it's an improvement. Code: [CODE]
Why this works: The constraints prevent Claude from doing a risky full rewrite when incremental improvement is safer.
Explain this code to me like I'm a developer who understands programming but has never seen this codebase. Cover: what it does, how it works, why key decisions were made, and any patterns or idioms being used. Code: [CODE]
Why this works: The persona framing gives Claude the right level of detail — technical but not assuming prior context.
Convert this [SOURCE LANGUAGE] code to idiomatic [TARGET LANGUAGE]. Don't just translate syntax — use the target language's conventions, standard library, and best practices. Highlight any behavior differences I should be aware of. Code: [CODE]
Why this works: Asking for idiomatic code prevents literal translations that work but feel wrong in the target language.
Design a database schema for [DESCRIPTION]. Include tables, columns with types, primary/foreign keys, indexes, and constraints. Explain your normalization decisions and any tradeoffs. Assume [DATABASE TYPE].
Why this works: Asking for tradeoff explanations helps you understand when to deviate from the suggested design.
Write a [FRAMEWORK] API endpoint that [DESCRIPTION]. Include: input validation, error handling with appropriate status codes, database interaction, and response formatting. Follow RESTful conventions.
Why this works: Listing the components ensures Claude builds a production-quality endpoint, not a demo.
This code is running slowly: [CODE]. Profile it conceptually — identify the bottleneck, explain the time/space complexity, and suggest optimizations ranked by impact. Show the optimized version.
Why this works: Conceptual profiling helps when you can't run actual profilers, and ranking by impact prevents premature optimization.
Given this API response: [JSON], generate comprehensive TypeScript types/interfaces. Handle nullable fields, nested objects, and arrays. Add JSDoc comments for non-obvious fields.
Why this works: Real API responses have nulls and nested structures that need careful typing.
Write a database migration that [DESCRIPTION]. Include: the up migration, the down migration (rollback), and any data migration needed. Use [ORM/TOOL]. Handle the case where the migration is run on a database with existing data.
Why this works: Including rollback and existing data handling prevents migration disasters.
Implement [AUTH TYPE] authentication for a [FRAMEWORK] application. Include: login, registration, token refresh, logout, and middleware for protecting routes. Use [LIBRARY] and follow security best practices.
Why this works: Specifying all auth flows prevents Claude from building only login and forgetting refresh tokens.
Build a CLI tool in [LANGUAGE] that [DESCRIPTION]. Include: argument parsing with help text, input validation, error handling with user-friendly messages, and colored output. Use [LIBRARY] for argument parsing.
Why this works: User-facing details like help text and colored output are easy to forget but make the tool feel professional.
Write a regex that matches [DESCRIPTION]. Provide: the regex, an explanation of each part, 5 strings it should match, and 5 it should reject. Use [REGEX FLAVOR].
Why this works: Test cases verify the regex works and help you understand edge cases.
I need to add [FEATURE] to my [TECH STACK] application. Design the architecture: which files/modules to create or modify, data flow, state management approach, and API changes needed. Consider error handling, loading states, and edge cases.
Why this works: Getting the architecture right before coding saves hours of rework.
Write documentation for this code: [CODE]. Include: a summary of what it does, parameters with types and descriptions, return value, usage examples, and common pitfalls. Format as [JSDoc/docstring/README].
Why this works: Specifying format ensures the docs integrate with your existing documentation system.
Add comprehensive error handling to this code: [CODE]. Include: try/catch for external calls, custom error types for domain errors, user-friendly error messages, logging for debugging, and graceful degradation where possible.
Why this works: The checklist approach ensures no error handling pattern is overlooked.
Build a webhook handler for [SERVICE] events in [FRAMEWORK]. Include: signature verification, idempotency handling, async processing for slow operations, retry logic, and proper HTTP response codes.
Why this works: Webhook handlers need specific patterns (idempotency, signature verification) that generic endpoint patterns miss.
Write a function that transforms data from [INPUT FORMAT] to [OUTPUT FORMAT]. Handle: missing fields with defaults, type coercion, nested data flattening/structuring, and validation of the output shape. Input example: [EXAMPLE].
Why this works: Providing an input example gives Claude concrete data to work with instead of guessing your structure.
My CI pipeline is failing with this output: [CI LOG]. My config is: [CI CONFIG]. Diagnose the failure, explain the root cause, and provide the fix. If it's an environment issue, suggest how to reproduce locally.
Why this works: CI failures often have environmental causes that need different debugging than code bugs.