01Why the same tool gives different results
Two people use Claude Code on the same project. One gets a clean, working change. The other gets a mess and blames the tool. The difference is almost never the model. It is how they ask, whether they let it think first, and how well they steer once it is running.
Today covers all three: clear asks, plan before you build, and the commands and shortcuts that keep you in control. Everything works the same in the terminal and in the VS Code panel unless a note says otherwise.
02Prompts that work the first time
Day 2 said Claude only knows what you tell it. A good ask answers four questions: what to change, where, what good looks like, and how to check it.
It has to guess which bug, which file and what "fixed" means.
@src/auth.ts. Reproduce it with a failing test first, then fix it and run npm test."Four habits make most asks better:
01Point at things
Use @file and @folder/ instead of describing them. In VS Code, select code and press Alt+K (Option+K on Mac).
02Say how to verify
"Run the tests", "run the build", "open the page and check". If it can check its own work, you review far less.
03Show an example
"Follow the style of @src/routes/users.ts" beats a paragraph of rules.
04Give the symptom, not your guess
Paste the error and the command that causes it. Your theory about the cause may be wrong and send it down the wrong path.
Long prompts. In the terminal, Shift+Enter adds a new line in most modern terminals (Windows Terminal included). \ then Enter works everywhere, and Ctrl+G opens your prompt in a text editor. In VS Code, the prompt box is multi-line already, and you can drag a screenshot straight into it.
Not sure what to ask? Ask it to interview you: "I want to add search to this app. Ask me questions until you have what you need, then write a plan." That turns a fuzzy idea into a spec.
03Plan first, then build
The most reliable habit in this whole series is a four-step loop: explore, plan, build, verify. Skipping straight to build is how a small request turns into a 400-line surprise.
Plan mode makes the first two steps safe. Claude can read your code and think, but it cannot edit anything until you approve its plan.
# start in plan mode PS C:\dev> claude --permission-mode plan # or, inside a running session > /plan add rate limiting to the login route # or press Shift+Tab until the status bar shows "plan mode on"
In VS Code, use the mode indicator at the bottom of the prompt box and pick Plan. Claude shows the plan for you to read before anything changes. Read it properly: wrong files, a missing edge case or a step you did not ask for are far cheaper to fix now than in a diff. Tell it what to change ("also handle the case where the user is already locked out") and approve only when it matches what you want.
Not every task needs this. A typo or a one-line rename can go straight to build. Use plan mode when the change touches several files, when you are in unfamiliar code, or when you cannot say in one sentence what the diff should look like.
Rule of thumb: if you could describe the diff in one sentence, just ask for it. If not, plan first.
04Commands worth knowing
Type / at the start of a message to see every command (in the VS Code panel too). These are the ones you will use all the time:
/clear new conversation, empty context (use between tasks) /compact summarize the chat to free up space, keep going /context see how full the context window is /rewind go back to an earlier point (conversation, code, or both) /plan enter plan mode, optionally with a task /diff review everything that changed in your working tree /model switch model /init create a starter CLAUDE file for the project (Day 2) /memory edit your CLAUDE files /resume pick up an earlier conversation /permissions see and change what Claude may do without asking /btw ask a side question without adding to the chat /usage see your usage and plan limits /help everything else
Two worth a closer look. /rewind is your safety net: every prompt creates a checkpoint, so you can roll the code back, roll the conversation back, or both. (It undoes Claude's file edits, not shell side effects like a database change, so keep using git.) /btw lets you ask "what does that flag do?" mid-task without cluttering the context.
05Shortcuts that keep you in control
Esc stop Claude mid-turn, keep the work so far Esc Esc empty prompt: open rewind. Prompt has text: clear it Shift+Tab cycle permission modes (Manual, edits, plan...) Ctrl+C interrupt, or clear the prompt (twice to exit) Ctrl+R search your earlier prompts Ctrl+G edit the prompt in your text editor Ctrl+O show detailed tool activity ! at the start run a shell command yourself; output joins the chat @ anywhere attach a file or folder ? on empty input show the shortcut help
The one that matters most is Esc. If Claude heads the wrong way, press it straight away and say what you want instead. Everything it did so far stays, and your next message steers it. The ! prefix is handy too: ! git status runs the command directly and puts the result in the conversation, so Claude sees it without a round trip.
In VS Code, the same ideas live in the panel: the mode indicator replaces Shift+Tab, the rewind button on any message replaces /rewind, Alt+K and @ attach context, and the stop button replaces Esc. Shortcuts vary a little by terminal and platform, so type ? in your own terminal to see what yours supports.
06Common mistakes
Never clearing between tasks
Letting it keep going down a bad path
Approving a plan you skimmed
/clear when the task changes; /compact when it is the same task but longPress
Esc and redirect earlyRead the plan; ask for changes before approving
07Try this today
Shift+Tab to plan mode (or use the VS Code mode picker) and ask for a small change./diff./rewind once, so you know it is there.Next up: context in long sessions. What fills it up, how to tell, and how to keep Claude sharp for hours.