How to Prompt Claude Code (The 3-Part Prompt I Use)

Here is the whole thing up front: a prompt that works has three parts - the goal, the context, and the constraints. The goal is what done actually looks like, in behavior, not vibes. The context is the information Claude cannot see on its own - which files matter, what the project is, what you already tried. The constraints are the guardrails - what to leave alone, which patterns to follow, what not to install. Give it all three and Claude gets it right on the first pass. Leave one out and it fills the gap with a guess, and the guess is where your afternoon goes. Everything below is how I write each part on real work.

Most weak prompts name a task instead of an outcome. 'Fix the login' is a task. 'Make login reject an unverified email with an inline error and keep the user on the page' is an outcome. The difference is that an outcome tells Claude how to know it succeeded, so it can check its own work instead of handing you something that technically ran. Describe the finished behavior you want to see - what happens, on which screen, in response to what. If you would struggle to tell whether the result is right by looking at it, your goal is too vague and Claude will feel the same ambiguity you do.

Claude Code can read your project, but it does not know which parts matter unless you point at them. This is the part people skip, and it is the biggest single upgrade to your prompts. Name the file or the feature. Say what the project is in one line. Mention what you already tried and what happened. If there is a pattern the codebase already uses, say 'follow the way we do it in X'. You are not writing a novel - you are handing Claude the three or four facts that would take it ten tool calls to discover on its own. That is where the speed comes from.

Constraints are the cheapest way to prevent the outcomes you would have rejected anyway. If you do not want a new dependency, say so. If a file is off-limits, name it. If you want the smallest change that works rather than a refactor, ask for exactly that. Claude is agreeable by default - it will happily rewrite three files to solve a one-line problem if you did not tell it not to. Stating the guardrails before it starts is far cheaper than catching them in review, because by review the work is already done and you are unwinding it. Two or three constraints handle almost every case.

Put the three parts together and you get a template I reuse on almost every task. I call it the CCC three-part prompt, and it reads like a short brief rather than a wish. It is not longer than a bad prompt - it is just aimed. You will find you write it in under a minute once it is a habit, and it saves you the three rounds of correction that a one-liner costs you.

The most common mistake is treating the first prompt as a throwaway - firing off one vague line to 'see what it does', then correcting from there. It feels faster because you sent something quickly, but you have just handed Claude permission to guess, and now every follow-up is you cleaning up a direction you never chose. The first prompt is the cheapest place to be specific. Spend the extra thirty seconds there and you skip the three rounds of 'no, not like that' that a lazy opener guarantees. Aim the first shot; do not spray and adjust.

Prompting well is the skill that makes every other Claude Code feature worth having - plan mode, subagents, custom skills, all of it lands harder when the prompt underneath is aimed. Get the three parts habitual and your hit rate climbs without touching your setup or your model. Inside the Claude Code Club we keep a shared library of the exact prompts our members use on real client builds - the openers that get it right the first time on the tasks that usually go sideways. Come grab them and bring the request you always end up correcting three times.