Prompt Patterns That Actually Work in Claude Code

The Difference Is in the Constraints

Anyone who has used Claude Code long enough has experienced this: you give it a task, it produces something that technically works but is not what you wanted. You tweak it, you redirect it, and eventually you get what you needed. The frustrating part is that the initial output was not surprising — it was a direct reflection of how you asked for the thing.

The gap between useful and useless Claude Code output comes down to constraints. Specific constraints tell Claude Code where the boundaries are. Vague requests leave those boundaries undefined, and Claude Code fills in the gaps with whatever seems plausible.

Pattern 1: Scope the Task, Then Scope What Should Not Change

The most useful thing you can do is tell Claude Code not just what to do, but what to leave alone. This is especially important when you are working in an existing codebase with patterns you want to preserve.

Bad prompt: Write a utility function for date formatting.

Good prompt: Add a formatDate utility to src/utils/date.ts that formats dates as YYYY-MM-DD. Use the same module export pattern as the other utilities in that file. Do not modify any other files in the project.

The constraint — do not modify other files — tells Claude Code where the boundaries are. Without it, Claude Code might decide to also update imports across the codebase, which might be what you want or might create work you did not ask for.

Pattern 2: Name the Files, Not Just the Outcome

When you are asking Claude Code to implement something in a specific location, name the file. Better yet, name the exact line or function if you know it. Claude Code reads your project, but it cannot read your mind about which file you meant to modify if the project has multiple similar options.

Bad prompt: Add error handling to the authentication logic.

Good prompt: Add error handling to the login function in src/auth/session.ts. The function starts at line 42. Handle the case where the session token is expired but the user record still exists.

The specificity prevents Claude Code from modifying the wrong file or adding handling in a place that does not fit your architecture.

Pattern 3: Separate What from How

Tell Claude Code what outcome you want before telling it how to implement it. This sounds counterintuitive — you might think giving implementation details helps. But if you start with constraints about the outcome, Claude Code can propose the best approach and you can redirect before it acts.

Bad prompt: Add a try-catch around the database call on line 15 and return a user-facing error message.

Good prompt: The checkout flow should show a clear error message when the payment system is unavailable, without exposing internal details. Then: Handle payment failures in src/checkout/payment.ts by catching exceptions from the payment provider and surfacing appropriate user messages.

The first version specifies implementation. The second version specifies the outcome constraint first — clear errors, no internal details — then asks for implementation. If Claude Code has a better approach for achieving that outcome, you have given it room to propose it.

Pattern 4: Give the Testing Framework a Name

When asking for tests, specify the framework and the patterns you expect. Claude Code can usually infer this from your project, but when it guesses wrong, you spend time reworking the output.

Bad prompt: Write tests for the user service.

Good prompt: Write tests for the user service using Vitest. Match the pattern used in tests/unit/user.test.ts — same describe blocks, same assertion style. Add tests for the password reset flow.

Matching existing test patterns is one of the highest-value things you can specify. It means the output is more likely to pass your linting and look like the rest of your codebase.

Pattern 5: Set the Boundary Between Code and Tests

When you want Claude Code to write tests, explicitly say whether it should modify source files or only tests. This sounds minor but it prevents a common frustration: Claude Code finding what it thinks is a bug in the source and deciding to fix it instead of writing the test you asked for.

Bad prompt: Write tests for the order total calculation.

Good prompt: Write tests for the order total calculation. Do not modify the source files — only write test code. If you notice issues in the source, note them in your response but do not fix them.

The boundary keeps Claude Code focused on what you asked for rather than expanding the scope to fix what it found.

The Underlying Pattern

All of these patterns share the same structure: they tell Claude Code not just what to do, but what to leave alone, what not to change, and where the boundaries of the task are. The more specific those boundaries are, the more likely the output matches what you actually need.

Vague prompts are not wrong — they are just leaving decisions to Claude Code that you should be making yourself. When the output disappoints you, the reflex should be to look at your constraints first before assuming Claude Code misunderstood.