AI Prompts for Claude for Coding

Before I write any code, I want to think through the architecture for [DESCRIBE WHAT YOU ARE BUILDING]. Walk me through the design decisions: what the main components should be, how data should flow between them, what the tricky parts are, and where the most likely bugs or scaling problems will come from. Ask me any questions you need before proposing a design.

I have a complex problem: [DESCRIBE]. I am not sure of the best approach. Think through this out loud: explore multiple approaches, reason about the trade-offs, identify the key uncertainty or decision point, and then recommend the approach you think is best and why.

Here is my proposed design for [FEATURE]: [DESCRIBE OR PASTE DESIGN NOTES]. Before I build it, play the role of a senior engineer doing a design review. What are the risks, what am I missing, what would you do differently, and what questions should I answer before starting to code?

I am going to build [DESCRIBE FEATURE]. Before I start, list every edge case, failure mode, and unusual input this code needs to handle. Be comprehensive. For each case, suggest how the code should behave. This will inform my test plan and error handling before I write a line.

I need to implement [FEATURE] and I am deciding between: [APPROACH A] and [APPROACH B]. For each, explain: the implementation complexity, the performance implications, how it handles [SPECIFIC CONCERNS], the long-term maintainability, and which you would choose given [MY SPECIFIC CONTEXT]. Make a clear recommendation.

Write [FUNCTION/MODULE/CLASS] to accomplish: [DESCRIBE]. Language: [LANGUAGE], version [VERSION]. It will be called from: [DESCRIBE CALLING CODE]. It receives: [INPUTS WITH TYPES]. It should return: [OUTPUTS WITH TYPES]. Error handling for: [SPECIFIC CASES]. Style conventions: [DESCRIBE OR PASTE EXAMPLE]. Write complete, production-quality code.

Write only the [SPECIFIC FUNCTION/CLASS]. Do not write the full module or surrounding code. After writing this piece, stop and explain: what it does, what it assumes about its inputs, what could go wrong, and what the next piece to write should be.

Here is the specification for what I need to build: [PASTE SPEC OR DESCRIBE IN DETAIL]. Implement this exactly as specified. Where the spec is ambiguous, note the ambiguity and state your interpretation before implementing. Write complete, runnable code.

Write a [LANGUAGE] implementation of [DESCRIBE]. I want this to be idiomatic [LANGUAGE]: using the patterns and conventions experienced [LANGUAGE] developers use, not patterns borrowed from other languages. After writing, note any places where you made a style choice over a simpler approach and why.

I am going to use test-driven development for [FEATURE]. Write the test suite first, before any implementation code. Tests should cover: [LIST THE BEHAVIORS TO TEST]. Use [TEST FRAMEWORK]. Make the test names read as specifications. Once I approve the tests, we will write the implementation to pass them.

Here is the code: [PASTE]. The error: [PASTE FULL ERROR AND STACK TRACE]. Expected behavior: [DESCRIBE]. Actual behavior: [DESCRIBE]. What I have already tried: [LIST]. Diagnose the root cause step by step, not just what to change but why it is failing.

Walk me through exactly what this code does when called with [SPECIFIC INPUTS]. Trace the execution step by step, showing the value of key variables at each step. Identify where the actual behavior diverges from what I expect: [PASTE CODE].

Explain this code as if teaching it to a developer who is competent but has never seen this codebase or this pattern. Cover: what it does, how it works, why it is structured this way, what the non-obvious parts mean, and what I should know before modifying it: [PASTE CODE].

Do a security review of this code. Look specifically for: injection vulnerabilities (SQL, command, path traversal), authentication and authorization issues, unsafe use of user input, secrets or credentials in code, and any OWASP Top 10 issues. For each finding, explain the risk and the fix: [PASTE CODE].

Review this code for performance issues. Identify: unnecessary database queries or N+1 patterns, algorithms that could be more efficient, memory leaks or excessive allocations, missing caching opportunities, and any blocking calls in async contexts. Quantify the impact where possible: [PASTE CODE].

Refactor this code to be cleaner and more readable without changing behavior. Specifically: rename unclear variables and functions to be self-documenting, extract repeated logic into named helpers, simplify complex conditionals, and remove unnecessary abstraction. Show the diff and explain each significant change: [PASTE CODE].

Write documentation for this code: (1) module-level docstring describing what it does and when to use it, (2) function-level docstrings with parameters, returns, exceptions, and a usage example, (3) inline comments for non-obvious logic only. Do not comment the obvious. Language style: [DESCRIBE IF RELEVANT]: [PASTE CODE].

I am about to submit this code for review. Write a pull request description that: explains what this code does and why, describes the approach and any alternatives considered, flags the parts a reviewer should look at most carefully, and lists any known limitations or follow-up work: [PASTE CODE].

This function is too long and does too many things. Break it into smaller, single-responsibility functions. Each function should have a clear name that describes its purpose. Show the refactored version with the original function replaced by calls to the new smaller ones: [PASTE FUNCTION].

I am replacing [OLD APPROACH] with [NEW APPROACH] in this codebase. Write a migration guide for my team that covers: what is changing and why, the steps to migrate, what will break during migration and how to handle it, how to test that the migration is complete, and any caveats or edge cases: [DESCRIBE OR PASTE RELEVANT CODE].