Lesson 3: Prompting Like a Pro
Module 0 introduced the Magic Lamp Rule: be specific about what you want, like making a wish with a genie. That still holds. But how you talk to Claude Code matters just as much as what you ask for.
Fast-track: Already use
@files, image pasting, the interview technique, and pattern-based prompting? Skip to Lesson 4.
More context = better output
The biggest difference between a mediocre prompt and a great one is context. Claude Code doesn't know what you're looking at, what you've tried, or what you're thinking — unless you tell it.
Reference files with @
Instead of describing a file, point Claude Code to it by typing @ followed by the file path. Claude Code will autocomplete as you type:
Fix the bug in @src/pages/Home.tsx — the page shows a blank screen on first load
The @ syntax tells Claude Code to read that file before responding. You can reference multiple files:
Make the settings page follow the same layout as @src/pages/Dashboard.tsx
Don't worry if you don't know the exact file paths — just start typing @ and Claude Code will show you suggestions from your project.
Paste images and screenshots
Claude Code can see images. If you're working on UI and something looks wrong, take a screenshot and paste it directly into the conversation. You can also drag and drop image files into the terminal, or give Claude Code a file path to an image.
How to paste images: Try Cmd+V first on Mac, or Ctrl+V on Windows. If that doesn't work, try Ctrl+V on Mac instead — some terminals handle clipboard shortcuts differently. You can also drag an image file directly from Finder or File Explorer into the Claude Code terminal window.
You can also paste:
- Design mockups
- Error screenshots
- Diagrams or wireframes
Visual context is often more useful than a written description.
Visual workflows for UI
Screenshots aren't just for reporting bugs. They're one of the most powerful ways to communicate UI changes:
[paste screenshot of current UI] See this section? I want you to: move the price to the top-right corner, make the title larger, and add a subtle shadow when I hover over it.
[paste screenshot of a website you like] Recreate this layout in my app. Match the spacing and structure as closely as possible.
[paste screenshot of broken layout] Something went wrong after the last change. The sidebar is overlapping the main content. Fix the layout.
The pattern: show Claude Code what you see, tell Claude Code what you want. This eliminates the guesswork of describing layouts in words.
Using reference websites as design inspiration
One of the most powerful UI prompting techniques: paste screenshots from websites you admire and tell Claude Code to use them as reference. You can even split the reference — one site for layout, another for visual style:
[paste screenshot of site A] [paste screenshot of site B] Use the first image as inspiration for the layout and structure. Use the second image for the look and feel — colors, typography, spacing. Build a landing page for my app using these as reference.
This works because Claude Code understands visual hierarchy, spacing, and design patterns from images. You don't need to describe "a hero section with centered text and a gradient background" — just show it a screenshot of one that looks great.
Pipe data in (advanced)
The | (pipe) symbol lets you chain terminal commands together. You can use it to feed a file's contents directly to Claude Code without opening a session:
cat error.log | claude "What's causing this error?"
cat error.log prints the file, and | claude "..." sends that text to Claude Code with your question. This is useful when you have a specific file you want Claude Code to analyze without starting a full conversation.
You don't need to use this right away — it's a shortcut for when you're more comfortable with the terminal.
Scope your tasks
Vague prompts get vague results. Tell Claude Code exactly:
- Which file to work in
- What scenario to handle
- What constraints to follow
| Vague | Specific |
|---|---|
| "Fix the bug" | "The submit button on the signup page doesn't respond when clicked — investigate and fix" |
| "Add validation" | "Add email validation to the signup form — show an error message below the input if the email format is invalid" |
| "Make it faster" | "The members list page takes 3 seconds to load. Only show 20 members at a time instead of loading all of them at once" |
You don't need to know the solution. Just define the problem clearly and let Claude Code figure out the implementation.
Point to existing patterns
One of the most powerful prompting techniques: tell Claude Code to follow an existing pattern.
Look at how @src/api/posts.ts handles CRUD operations. Create a new file @src/api/comments.ts that follows the exact same pattern but for comments.
The header component in @src/components/Header.tsx uses a specific animation pattern. Apply the same animation to the footer in @src/components/Footer.tsx.
This works because Claude Code can read the existing code and replicate its structure. No need to explain the pattern — just point to it.
The interview technique
For complex features, don't try to write the perfect prompt. Ask Claude Code to interview you:
I want to add user authentication to my app. Before you build anything, interview me about my requirements. Ask me questions one at a time until you have enough information to propose a plan.
Claude Code will ask targeted questions: What auth provider? Email/password or OAuth? What happens after login? Role-based access?
This is often better than trying to think of everything upfront. Claude Code knows what technical decisions need to be made — let it ask.
Ask codebase questions
Claude Code is great for onboarding yourself into unfamiliar code. Use it to understand before you change:
Explain how authentication works in this codebase. Walk me through the flow from login to authenticated API call.
What database tables does this app use? Show me the schema and how they relate to each other.
Where does the payment processing happen? I need to understand the flow before I modify it.
Claude Code reads your actual code and gives answers based on what's there — not generic documentation.
When vague prompts are useful
Not every prompt needs to be specific. Sometimes vague is better:
- Exploration: "What does this codebase do?" — when you're orienting yourself
- Brainstorming: "What are some ways I could improve the performance of this page?" — when you want options
- Review: "Look at this file and tell me if you see any problems" — when you want Claude Code's judgment
The rule is: be specific when you know what you want, be vague when you want Claude Code to think broadly.
Reasoning modes: when to think harder
Claude Code has different thinking modes you can switch between. Think of it like asking someone to answer quickly vs. sit down and really think it through.
| Mode | How to activate | Best for |
|---|---|---|
| Normal | Default — just type your prompt | Everyday tasks, file edits, quick questions |
| Extended thinking | Type think harder or think about this step by step in your prompt | Complex debugging, architecture decisions, multi-file refactors |
Extended thinking makes Claude Code pause and reason through the problem before responding. It's slower but catches edge cases and produces better plans for complex work.
When to use extended thinking:
- Debugging a tricky bug that spans multiple files
- Planning a feature that touches several parts of the codebase
- Reviewing code for subtle security issues
- Making architectural decisions with trade-offs
When normal mode is fine:
- Adding a component, writing a function
- Fixing an obvious bug
- Asking questions about the codebase
- Most everyday tasks
You don't need to use extended thinking often. But when you're stuck or the task is genuinely complex, it can be the difference between a mediocre answer and the right one.
Checkpoint
- I know how to reference files with
@ - I know I can paste images directly into Claude Code with Cmd+V / Ctrl+V
- I understand why specific prompts get better results
- I know how to point Claude Code to existing patterns
- I've tried (or plan to try) the interview technique for a complex feature
- I know when to use extended thinking vs. normal mode