# Giving Claude Code better instructions **Author:** Ivan Misic **Published:** 2026-01-10 **URL:** https://ivanmisic.net/blog/ai-tools/giving-better-instructions **In plain English** Give Claude Code the problem, relevant context, and the result you expect. Specific instructions reduce guessing, but you still need to review what it builds. - Match the detail to the task: one line may cover a small edit, while larger work needs the files, constraints, and expected behavior - For an unclear project, ask Claude to interview you one question at a time before planning - Use Plan Mode when the change touches several files or the approach needs review before editing - Use `/effort` for the session or `ultrathink` for one demanding prompt; phrases such as "think harder" are ordinary text - For a bug, name what is wrong, when or where it happens, the likely file or area, and the intended fix if you know it Claude Code works better when you give it the problem, relevant context, and the result you expect. A specific instruction reduces guessing, but you still need to review what it builds. (My wife operates on a different principle: give her permission to "improve" anything, and she'll find something to change, tear down, or rebuild. The specificity of instructions is irrelevant. The outcome is renovation.) ## Vague vs. Specific Watch the difference: Vague request: "Make me a website." Claude must choose the content, colors, and layout. Several of those decisions may be wrong for your site. Specific request: "Create a one-page website for a coffee shop called Bean There. Dark brown background, cream text. Three sections: hero with the shop name and tagline 'Coffee worth the detour,' a menu section with six items, and a contact section with address and hours." Claude has fewer open decisions. A clear brief usually costs less time than correcting several invented decisions afterward. Claude may ask for missing details, but I do not rely on it. For an unclear task, I add: "Before you start, ask me any questions you need answered." ## Three Levels of Instructions Not everything needs a detailed brief. Match your instruction level to the task: **Level 1: Quick ask** For simple, obvious things, especially if you're already in a conversation and this is a follow-up. ```text Change the heading color to white ``` **Level 2: Guided task** For tasks with specific requirements. ```text Create a contact page with a form. Fields: name, email, message. Dark background matching the home page. Submit button in green. Add a heading that says "Let's Talk" ``` **Level 3: Big project (let Claude ask questions)** For complex work where you might miss details. ```text I want to add a blog section to my website. Before you build anything, ask me questions about what I need. Things like layout, categories, how many posts to show, that sort of thing. ``` For a larger task, I ask Claude to interview me one question at a time. The questions expose decisions I have not made yet. ## Useful Slash Commands Claude Code has a few built-in commands that start with `/`. You don't need to memorize them all, but these four are worth knowing: - **`/help`** shows available commands and tips - **`/context`** shows what is currently filling the context window - **`/compact`** summarizes the conversation so Claude has more room to think (useful in long sessions) - **`/clear`** starts a fresh session while project instructions remain available - **`/exit`** closes Claude Code I use `/clear` when I move to an unrelated task or no longer need the earlier conversation. Project instructions and auto memory remain available, while Claude reads project files as the new task requires them. ## Review the Plan Before Editing Look below the input field where you type. You'll see a mode indicator. Press **Shift + Tab** to cycle through modes, or click it. One of them is Plan Mode. You can also put `/plan` in front of a single prompt when you want to plan just that one thing. In Plan Mode, Claude can inspect files and run read-only exploration, but it cannot edit source files. Review the plan, give feedback, then approve implementation when the approach is clear. I use it when the change has unclear scope, meaningful risk, or several decisions I want to review before implementation. When to use it: - Adding a new page or section to an existing project - Reorganizing files or folders - Changes with several connected files or decisions When to skip it: - Quick edits ("change this color") - Single-file tasks ("create a contact page") ## Reasoning Effort Use `/effort` when you want to change the session's reasoning level. For one difficult prompt, add `ultrathink`: ```text I need to reorganize my website navigation. Ultrathink about which pages should be in the main menu vs. the footer. Currently I have: Home, About, Services, Portfolio, Blog, Contact, FAQ, Pricing ``` Phrases such as "think hard" are ordinary prompt text, not special modes. ## Common Instruction Mistakes - **Too abstract.** "Make the design better." Better how? Cleaner? Bolder? More colorful? - **Too technical (for you).** "Refactor the CSS to use BEM methodology." If you don't know what that means, don't ask for it. Describe the outcome you want instead. - **Moving the goalposts.** "Build a portfolio page." Then "Actually make it a grid." Then "Wait, cards instead." Then "No, go back to the grid." Pick a direction and commit, at least for one iteration. You can always change it later with a clear instruction. - **No context.** "Fix the header." Which header? What's wrong with it? "The header on the home page overlaps the content when I scroll down on my phone" is a fix Claude can actually make. ## How I Give Instructions I never type "fix my CSS." That's useless. I type something like "the navigation bar overlaps the hero section on mobile, fix the breakpoint in nav.css." That instruction has: - **What's wrong** (nav overlaps hero) - **When it happens** (mobile under 640px) - **Where to look** (nav.css) - **What to fix** (the breakpoint) The pattern is: **what's wrong** + **when or where it happens** + **which file or area** + **what the fix should be** (if you know). Give Claude enough relevant context to locate the problem and judge the result. Extra unrelated detail can pull the task in the wrong direction. > Next: when separate parts of a task are safe to delegate to subagents.