Thinking in Instructions

Most people talk to Claude Code like they'd talk to a coworker at their desk. "Hey, can you fix that login bug?" Works fine with humans because humans share years of context. They sat in the same meetings. They know which login bug you mean.

Claude Code has none of that shared history. It starts every conversation knowing nothing about your specific problem. A vague prompt forces it to guess. Guessing burns tokens, wastes time, produces wrong answers.

Stop chatting. Start instructing.

The Instruction Mindset

Claude Code is more like a brilliant contractor who showed up five minutes ago. Deep technical knowledge, works fast, but has never seen your codebase. Doesn't know your conventions, your bug tracker, your deployment pipeline.

You wouldn't walk up to that person and say "fix the login bug." You'd explain the symptoms, point to the relevant files, describe what a successful fix looks like.

Every prompt should answer three questions:

1. What is the situation? (context and symptoms)
2. What should Claude Code do? (specific actions)
3. How will we know it worked? (verification criteria)

In practice:

The instructional column does three things every time. Narrows scope. Points to locations. Describes success.

What Makes Instructions Good

More precise instructions, fewer corrections. A few patterns that consistently help:

Verification Criteria

Tell Claude Code how to prove it did the job right. Honestly, this is the single highest-leverage change you can make to any prompt.

Write a validateEmail function. Test cases: user@example.com
returns true, "invalid" returns false. Run tests after implementing.

Without that last sentence, Claude Code writes the function and stops. With it, Claude Code writes the function, writes tests, runs them, fixes failures. One sentence turned a single-step task into a self-verifying workflow.

Reference Existing Patterns

Your codebase already has conventions. Point to them instead of explaining them.

Look at how BlogCard is structured in components/blog/blog-card.tsx.
Create a new ProjectCard component following the same pattern, same
prop style, same className conventions.

This saves you from explaining naming conventions, styling approach, component structure. Claude Code reads the example and figures it out. Way more reliable than a paragraph of prose trying to describe the same thing.

Rich Context

Claude Code can work with more than typed text:

• @ references to pull specific files into your prompt
• Pasted images of UI mockups or error screenshots
• Piped data: cat error.log | claude "what is causing these failures?"
• URLs to documentation or issue trackers

The more relevant context you front-load, the less Claude Code has to go hunting for on its own.

The Interview Pattern

Sometimes you know what you want but can't specify it well. Hand that problem to Claude Code itself:

I want to build a notification system for my app. Interview me
in detail using AskUserQuestion tool. Ask about technical
implementation, edge cases, and tradeoffs before writing any code.

This flips the dynamic. Instead of you trying to anticipate every detail upfront, Claude Code asks the right questions. After the interview, it has exactly what it needs. I use this constantly for features where the requirements are still half-formed in my head.

When Vague Is Fine

Not every prompt needs to be a detailed instruction set.

"What would you improve in this file?" is a perfectly good prompt. You're asking for analysis, not execution. The output is ideas, not code changes.

"Explain how the auth flow works in this project" is another fine one. Read and summarize, not build.

Exploring? Be vague. Executing? Be specific. That's really all there is to it.

When you ask Claude Code to change code, deploy something, or build a feature, switch into instruction mode. Situation, actions, verification.

Try It

Take a recent prompt and rewrite it using the instruction mindset:

## Situation
[What is happening now, what is wrong, or what needs to exist]
 
## Action
[Specific steps to take, files to look at, patterns to follow]
 
## Verification
[How to confirm the task is done correctly]

Pick something real from your current project. A bug you've been meaning to fix, a small feature to add. Write the prompt with all three sections, then compare the result to what you'd have gotten from "hey fix this thing."

The difference is usually night and day. Claude Code didn't get smarter. You just gave it what it needed to succeed on the first try.