Prompts
That Pull
Their Weight.

Most people stop learning about prompting after their first month with Claude. They figure out what works, repeat it, and move on. That's fine for a while. But eventually you notice you're typing the same setup over and over, getting slightly different answers each time, and wondering why some prompts feel like magic while others feel like wrestling.

There's a reason. Prompts have layers. Most people use one layer. This piece covers all three: one-shot prompts, prompt engineering, and context engineering. By the end, you'll understand which one to reach for and when, and you'll have copy-paste templates for each.

• One-shot prompts. You type something into Claude and get an answer. Most of your day-to-day Claude usage.
• Prompt engineering. You write the prompt more deliberately so Claude does better work the first time. Structure, examples, constraints.
• Context engineering. You set up Claude before the prompt so it already knows what it needs to know. Memory files, glossaries, skills.

Each layer makes the next one more powerful. You don't need to master one before trying the next.

A one-shot prompt is exactly what it sounds like. You give Claude everything it needs in one message, hit enter, and use the answer.

Most of your work in Claude is one-shot. "Rewrite this email." "Summarize this thread." "What's the action I need to take from this doc."

What makes a one-shot prompt good

• Specific. "Rewrite this to be shorter" beats "make this better."
• Self-contained. Paste the doc, paste the email, paste the context you want Claude to work from. Don't make Claude guess.
• Honest about what you want. If you want bullet points, ask for bullet points. If you want it to keep your voice, say so.

Template and example

One-shot quick reference

Sometimes the one-shot prompt doesn't quite land. Claude gives you something close but not right, or it picks up the wrong tone, or it adds bullet points when you wanted prose.

That's when you reach for prompt engineering. It sounds intimidating. It's not. These are the seven moves that matter most.

01Be specific about what you don't want

Telling Claude what to skip is often more useful than telling it what to do.

The "don't" list is the part most people skip.

02Show, don't tell

If you want a certain style, paste an example of it. One example is usually enough.

Claude is a pattern-matcher. One concrete example beats five sentences of description.

03Set a role when it actually matters

"You are a careful copy editor" or "You are a junior PM reviewing this for clarity." A role narrows the kind of answer you get.

Don't over-use this. If the task is obvious, skip the role. Roles work best when the same task could be done in many ways and you want a specific one.

04Ask for the thinking, not just the answer

When the question is hard, add: "Walk through your reasoning before giving the final answer."

This catches errors. Claude often realizes mid-thinking that the first answer it was about to give wasn't quite right.

05Use structure inside the prompt

When a prompt has many parts, separate them clearly. Headings or simple labels work.

Claude treats these as different sections and pays attention to each.

06Put the long stuff first, the question last

If you're pasting a long document, put it at the top of the prompt and your question at the bottom. The question is the last thing Claude reads, which is what you want.

07Constrain the output shape

"Under 200 words." "Three bullets, max." "One paragraph, no headings."

Output constraints are reliable. Claude follows them.

Prompt engineering quick reference

Here's where it gets interesting.

Notice that everything in Layer 2: examples, role-setting, your voice, your constraints, is stuff you keep typing in over and over. Every single prompt has the same setup.

Context engineering is when you stop retyping that setup and put it somewhere Claude reads automatically.

The plain-English version, from Simon Willison: prompts are instructions, context is everything Claude needs to know before it can act on those instructions.

The five moves of context engineering

• Memory files (CLAUDE.md). A markdown file in your project that Claude reads at the start of every session. Put your preferences here, your team's names, the rules you always want it to follow.
• Glossaries. A separate file that decodes your internal jargon (client codenames, project nicknames, acronyms). Claude reads it when relevant.
• Skills. Self-contained instructions for a specific task. The EOD Report skill is one example. You install it once, then Claude knows how to write your EODs forever.
• MCPs. Connections to your real tools (Slack, Notion, Linear, your file system). Claude can read your actual data instead of you pasting it every time.
• Retrieval. When you have a lot of reference docs, Claude pulls in just the relevant pieces instead of you pasting everything.

Template and example

Create a CLAUDE.md at the root of your workspace with sections like:

## Preferences
- Write in a professional but conversational tone.
- Keep responses under 300 words unless I ask for more detail.

## Active Projects
- [List your current projects here]

## Voice rules
- [Specifics about how you write]

## Don'ts
- No em dashes.
- No "leverage" or "unlock."

Now every prompt you write inside that workspace inherits those rules. You don't repeat yourself.

Why this saves tokens and improves output

You stop wasting tokens on setup. Every prompt where you re-explain your team, your tone, or your constraints is a prompt where most of the message is repetition. Move that to a memory file and your prompt becomes the question, not the setup plus the question.

Quality goes up because the context is consistent. When you retype context every time, you forget pieces. Claude gets slightly different setup each session and gives you slightly different output. When the context lives in a file, it loads the same way every time, so the output is more consistent.

There's a real failure mode to watch for, though. Researchers call it context rot (Hamel Husain has the cleanest writeup): bloating Claude's context window with too much background actually makes performance worse, not better. Find the smallest set of high-signal context. More is not better.

Context engineering quick reference

• One-shot prompt. When the task is small, one-off, and the context is already in the message. Most of your work.
• Prompt engineering. When one-shots aren't landing reliably, or the task is important enough that the first answer needs to be the right one.
• Context engineering. When you find yourself repeating the same setup five times a week, or when you're working on a project that needs Claude to remember things across sessions.

You'll mostly live in Layer 1. Layer 2 makes Layer 1 more reliable. Layer 3 makes both faster.

Addy Osmani has the cleanest framing of the bridge between Layer 2 and Layer 3: prompt engineering ends once you craft a good prompt; context engineering begins with designing whole systems around memory, knowledge, tools, and data.

Stop retyping your setup. The next time you're about to paste the same context into Claude for the third time, that's the signal to move it into a memory file or a skill. That one move will make every future prompt cheaper and better.