Core Commands — The 20% You'll Use 80% of the Time
Claude Code has dozens of features. This module teaches the ones that show up in almost every real session: slash commands, file targeting, writing tight briefs, managing context, and recovering when something goes wrong.
🗺 How Claude Code takes instructions
Every interaction with Claude Code is one of two things — know the difference and you'll never be confused about what to type:
Start with /. These are control instructions — they change how Claude Code behaves, not what it builds. Think of them as settings and tools.
Everything else. These are work instructions — what to build, edit, explain, or fix. Write them like you're talking to a skilled colleague.
⚡ Slash Commands Reference
These are the commands that matter day-to-day. You don't need to memorize all of them — but the ones marked essential will come up in almost every session.
| Command | What it does |
|---|---|
| /help essential | Shows all available commands. Run this whenever you're unsure what's possible. |
| /status essential | Shows your current model, context usage (tokens used vs. limit), and session cost. Run this before a long task. |
| /clear essential | Wipes the entire conversation history. Use this when starting a completely new, unrelated task. |
| /compact essential | Compresses history into a summary and continues. Use this mid-session when context is getting long but you're not done. |
| /model essential | Switch between Opus (most capable), Sonnet (balanced), and Haiku (fastest/cheapest). Example: /model claude-haiku-4-5 |
| /init essential | Scans your project and generates a CLAUDE.md automatically. Best starting point for any existing project. |
| /review power | Reviews uncommitted git changes in your project. Gives a quality assessment and flags issues. |
| /config power | Opens the settings file. Use to configure permissions, hooks, and default behaviors. |
| /cost | Shows total API spend for the current session. Useful for keeping track of usage. |
| /exit | Cleanly exits Claude Code. Your files are saved — nothing is lost. |
/clear vs /compact — when to use which
- Long session, not done yet
- Switching to a related task
- Context > 50% full (check /status)
- Want to keep recent file edits in memory
- Starting a completely new task
- Previous session went sideways
- Switching to a different project area
- Fresh start, no history needed
/status at the start of a big task to see your context baseline. Run it again mid-session — if you've used more than 40% of the context window, run /compact before continuing.
🎯 Targeting Files — Telling Claude Exactly What to Edit
One of the most common mistakes beginners make: asking Claude to do something without telling it which file. Claude can read your project, but a specific target always produces better results.
Three ways to target a file
The simplest way. Just mention the filename directly in your sentence.
Type @filename to explicitly attach a file to your prompt. Works best for precise edits.
Ask Claude to read the file first, confirm it understands it, then make the edit. Great for large files.
Examples — weak vs. strong file targeting
❌ Weak — Claude has to guess what to edit "Add a footer to the page" ✓ Strong — file is named explicitly "Add a footer to index.html with copyright text and 3 links" ✓ Stronger — @ mention for precision "Edit @index.html — add a sticky footer below the main content. Keep the existing color scheme. No new CSS files." ✓ Best for large files — read then edit "Read styles.css and tell me what color variables are defined. Then add a --color-footer: #1a1a26 variable at the top."
Giving Claude multi-file context
When a task spans multiple files, name all of them upfront. Claude reads all referenced files before writing anything.
"I need you to work across 3 files: @index.html, @styles.css, and @app.js.
Add a dark mode toggle button to the nav in index.html, wire up the
CSS variables in styles.css for both themes, and handle the toggle
click in app.js. Keep all three files consistent."
Checking what Claude can see
# Ask Claude to map your project structure "List every file in this project and give me a one-line description of each." # Ask what it currently has in context "What files have you read so far in this session?"
✍️ Writing Great Briefs
The quality of Claude's output is directly proportional to the quality of your brief. A great brief has four components — use all four and you'll rarely need to ask for revisions.
The constraint is the most important part
Most people write what they want but forget to say what they don't want. Constraints prevent Claude from making perfectly reasonable choices you'd have to undo.
# Tech constraints "No frameworks — vanilla HTML/CSS/JS only" "Don't install new npm packages" "Keep the existing class naming convention" # Scope constraints "Only edit the nav — don't touch anything else" "Don't rewrite the file from scratch — just add the section" # Style constraints "Match the existing card design exactly" "No inline styles — use the CSS variables already in the file"
When to use multiple short prompts vs one big prompt
- First time touching a file
- Iterating on design or copy
- Not sure exactly what you want yet
- Multi-file tasks
- You know exactly what you want
- Avoiding back-and-forth
🔄 Session Management
Every Claude Code session has a context window — a limit on how much conversation history it can hold at once. Managing it well keeps your sessions fast and cheap.
Reading /status output
● Session status Model: claude-sonnet-4-6 Mode: interactive Project: ~/projects/my-app Context: 48,200 / 200,000 tokens ← 24% used — fine Cost: $0.018 this session # If context hits 60%+, run /compact before a big task # If it hits 80%+, /compact immediately
Switching models mid-session
You can switch models at any point without losing context. Use a faster/cheaper model for simple tasks, switch to Opus for complex ones.
# For quick edits, formatting, or simple questions /model claude-haiku-4-5 # For complex logic, architecture decisions, hard bugs /model claude-opus-4-7 # Back to the daily-driver balanced model /model claude-sonnet-4-6
↩️ Undo and Recovery
Claude Code writes real files to your disk. If it does something you didn't want, here are your options — from fastest to most thorough.
Option 1 — Ask Claude to revert
The fastest option. Claude remembers exactly what it changed in the current session.
"Undo the last change you made to index.html" "Revert styles.css to what it was before this session" "The nav you added broke the layout — remove it and go back to how index.html looked before you touched it"
Option 2 — Git (if your project uses it)
If you have git initialized, every pre-Claude state is recoverable. This is the professional safety net.
# See what Claude changed git diff # Undo all uncommitted changes (back to last commit) git restore . # Undo changes to one specific file git restore index.html
Option 3 — Ask Claude to explain before writing
Prevention is better than recovery. For risky or large changes, ask Claude to explain its plan first.
"Before you make any changes, explain exactly what you're going
to do to each file. Wait for me to say 'go ahead' before writing."
git init && git add . && git commit -m "before claude" before a big session. You can always roll back to that snapshot.
⌨️ Keyboard Shortcuts
These work inside any active Claude Code session. Learn the first three — they'll save you every single day.
🎯 Challenge — All four skills in one session
Open your terminal in the project you created in Module 01 and complete all four steps.
-
1
Run /status and note the context size and cost. Then run /model and switch to
claude-haiku-4-5. Confirm the switch with /status again. - 2 Write a 4-part brief using the Target + Context + Constraints + Outcome structure. Ask Claude to add a feature to an existing file in your project. Notice whether it stays within the constraints.
- 3 Ask Claude to make a change you don't like, then undo it using a prompt (not git). Confirm the file is back to what it was before.
- 4 Run /compact to compress the session, then send one more prompt. Verify Claude still knows your project context from CLAUDE.md.
🏗 Mini Project — Build a 3-File Web App
You're going to build a real personal portfolio page: an HTML file, a CSS file, and a JavaScript file — all created by Claude using the targeting and briefing skills from this module. Pick your OS, check each step off as you go.
Open Terminal (Cmd + Space → type Terminal → Enter). Then run these commands one line at a time, pressing Enter after each:
mkdir ~/my-web-app
# Move into it (you must be inside it when you launch Claude)
cd ~/my-web-app
# Launch Claude Code
claude
When Claude starts you'll see the ❯ prompt. That means it's ready and waiting inside your my-web-app folder — every file it creates will go here.
First, run the status command to see which model you're on and how much context is in use. Type this at the ❯ prompt and press Enter:
You'll see something like Context: 1,200 / 200,000 tokens — the first number is how much you've used, the second is the limit. Right now it'll be near zero since you just started.
Now send your first brief. This creates the HTML structure for a portfolio page. Copy the entire prompt below and paste it at the ❯ cursor:
Sections: hero with my name and a short tagline, 3 project
cards with title and description, and a contact section.
Vanilla HTML only. No inline styles — link to styles.css
for all styling. No frameworks or libraries.
Claude will write index.html into your folder. When it finishes you'll see a summary like ✓ Created index.html.
The @index.html in this prompt tells Claude to read that file before writing the CSS, so the styles match the exact HTML structure it just created. The constraints prevent Claude from making choices you'd have to undo.
Dark background color #0a0a0f, orange accent color #e07a5f.
Use CSS custom properties (variables) for every color so they're
easy to change later. Add light mode support using
@media (prefers-color-scheme: light). No frameworks.
After it finishes, you'll have two files: index.html and styles.css. Claude wired them together because you mentioned @index.html in the brief — it read the file and matched the CSS to the exact class names in it.
--color-bg: #0a0a0f. If you want to change the background later, you change one line instead of hunting through the whole file.JavaScript needs to know about both the HTML (which elements exist) and the CSS (which variables and classes are defined) to work correctly. By mentioning all three files, Claude reads them all and writes JS that fits exactly.
Add two behaviors:
1. Smooth scroll when clicking a "Contact me" button in the hero
2. A simple typing animation for the hero tagline text
Vanilla JavaScript only — no jQuery, no libraries.
When it's done you'll have three files. At this point you have a complete, working web page — even though you haven't written a single line of code yourself.
By now your session has 3–4 exchanges in it. Run /compact to compress the history into a summary. Claude keeps the important context (your files, your project) and drops the conversation chatter:
Claude will confirm it compressed the history and tell you how many tokens it saved. Now send one more prompt — this proves it still knows all three files:
would make this page feel more polished. Then make it.
Watch what Claude does — it scans all three files, proposes something specific (maybe a hover effect, a transition, better spacing), and edits the right file. This is the multi-file awareness you've been building toward.
Type this at the ❯ prompt — or open a new Terminal tab and run it from inside the my-web-app folder:
Your browser opens the page. You should see your hero section with the typing animation, the project cards, the contact section, and a working smooth-scroll button — all in dark mode by default, switching to light mode if your OS is set to light.
styles.css. Make sure all three files (index.html, styles.css, app.js) are in the same folder. Ask Claude: "Check that index.html links to styles.css and app.js correctly."