I Wasted 6 Months Using Claude Code Wrong. Here Are the Commands That Changed Everything.

It was past midnight. I was still staring at a Claude Code session that had gone completely wrong. The task was simple: add pagination to an endpoint. But it turned into a four-hour mess. The chat had gotten huge. Every reply came back slower than the one before. Early on, I asked Claude to "remember" three rules for the feature. By hour three, it had forgotten all of them. It even brought back a bug I had already fixed. Twice.

So what did I do? The thing we all do when a tool stops working the way we want. I blamed the tool.

"Claude is confused." "It's losing focus." I kept typing longer prompts. I explained the same things again and again. I hoped that saying it more would fix the problem. It didn't, because that was never the real problem. The tool wasn't broken. I was using it wrong.

I was treating Claude Code like a simple chat box: type a message, hope for the best and move on. But Claude Code isn't just a chat box. It's a command-line coding tool with built-in commands and controls designed to solve many of the problems that come up when you're working on real projects.

I realized this one weekend when I sat down and went through its built-in commands one by one. I didn't just skim the list. I actually read what each command does, when to use it and why it exists.

It changed the way I work with Claude Code more than any prompt trick ever did. Sessions stopped falling apart. Context stopped disappearing halfway through a task. Code reviews started catching bugs I used to miss. Even tasks that once took an entire evening could sometimes be finished before my coffee got cold.

This guide is what I wish someone had given me on day one. It covers 34 Claude Code commands, divided into three simple groups:

• 14 core commands you'll use almost every day
• 11 practical commands for everyday problems, such as picking up previous work or handling multiple tasks
• 9 additional commands for connecting tools, running checks, reviewing changes and catching problems early

Every command gets the same treatment: what it does in plain English, why it matters, the exact syntax and a real-world example of when you would actually use it.

Each section also starts with a quick-reference table, so you can scan the commands first and dive deeper only when you need to.

Important Note

• Claude Code is updated frequently, so command names and behavior can change over time. The commands in this guide were checked against Anthropic's official documentation while writing it.

• Still, when in doubt, the /help command inside your own Claude Code installation is the best source of truth, it's the most up-to-date reference for the version you're actually using.

• The goal isn't to memorize all 34 commands. It's to know which command to reach for when you run into a particular problem.

Quick Answer

Claude Code doesn't really get “dumber” as a session gets longer. What usually happens is that your context window fills up with old or unnecessary information. Eventually, useful context gets harder to work with and you may end up manually doing things that Claude Code already has commands for.

The fix isn't a smarter prompt. It's better workflow habits.

This guide covers 34 Claude Code commands across three groups. The first 14 make up the daily core loop: set up your project, plan before coding, manage context, review changes and fix problems cleanly. The next 11 cover everyday situations like continuing old work, experimenting safely, working on multiple tasks and tracking usage. The final 9 focus on connecting external tools, checking real behavior and handling useful day-to-day tasks.

New to Claude Code or short on time? Start with these five commands:

• /init → Set up project memory
• /plan → Think before you code
• /compact → Manage your context
• /diff → See what actually changed
• /code-review → Catch problems before a human reviewer does

Those five commands cover a surprisingly large part of the value in this guide. Once you're comfortable with them, add the others as you encounter the problems they are designed to solve.

Group 1: The 14 Core Commands (Quick Reference Table)

Save this table. It's the daily-use cheat sheet. Full details for each command come right after this table.

Some of these have other names too. For example, /review also works for /code-review and /undo also works for /rewind. If you're not sure, type /help to see what's available in your version.

The Whole Workflow in One Picture

If you remember nothing else from this guide, remember this:

New project
    -> /init
    -> /memory (clean it up) + /permissions (set rules once)

New task or feature
    -> /plan (think first)
    -> /context (check the space, if needed)
    -> /compact (free up space early)
    -> /clear (only when starting something totally new)

Before you ship
    -> /diff (see what changed)
    -> /code-review (catch bugs)
    -> /security-review (catch security risks)

When something breaks
    -> /rewind (go back cleanly)
    -> /doctor (check the tool itself, now and then)

Everything else in this guide just explains why that picture works and adds the extra commands that make daily work smoother once the basics are second nature.

Why Claude Code Gets Slower the Longer You Use It

Here's the part most people don't explain and it's the reason many of the commands in this guide exist. Claude Code, like other AI tools, works within a context window: a limited amount of information it can consider at a time. Your messages, files, tool results and other context all consume part of that space.

As the context grows, a few things can happen:

• Responses can take longer because more context may need to be processed.
• Older instructions can become harder to use effectively. Claude hasn't intentionally forgotten them, but important details can get buried beneath newer context.
• You can run into the context limit during a long task. At that point, you may need to compact or summarize the conversation to make room for more work.

This isn't something a clever prompt can completely fix. Context is a real technical limit. The good news is that Claude Code includes commands specifically designed to help you manage that context and keep long sessions under control. I simply didn't know they were there.

The 14 Core Commands, Explained One by One

Setting Up a Project (Day One)

1. /init give the project a memory

Run this first, before you ask Claude to touch anything. /init reads your codebase and writes a starter CLAUDE.md file, a memory file that Claude reads at the start of every future session in that project. Instead of saying "we use pnpm, not npm" for the fifteenth time, you say it once and it sticks.

That one habit alone cut out a lot of the repeating that used to fill up my context window.

2. /memory keep that file correct

/init gets you started. /memory is how you keep the file correct as the project changes. It opens CLAUDE.md so you can edit it and it also shows you memory entries Claude has added on its own. A messy memory file costs you space on every single turn. So clean it up now and then. Don't just keep adding to it.

3. /permissions stop approving the same thing every time

If you keep clicking "allow" on the same routine action every session, that's wasted effort. /permissions opens a simple screen for allow, ask and deny rules. Set it up once, then move on.

How I use these three together: on day one of any project, I run /init, then check /memory and delete anything wrong, then set /permissions so I'm not clicking "allow" on npm test for the fortieth time by Friday.

While You're Working

4. /plan think first, code second

This is the biggest habit change on this whole list. /plan [description] puts Claude into a mode where it thinks through a plan before writing or changing any code. For anything more than a tiny fix, this catches bad guesses early, while they're still cheap to fix not after they're stuck in six different files.

Try something like this:

/plan add Redis caching to the product API without changing the existing response shape

Claude explains its plan where the cache goes, how it clears old data, what changes and what stays the same. You can push back on any of it before a single line of code is written.

I used to skip this step because it felt slow. It isn't slow. It's the step that saves you a four-hour mess later.

5. /context see what's actually filling up your space

This is the one I wish I'd found on day one instead of month five. /context shows a simple, color-coded view of what's using up your space big files, tool outputs, memory bloat with tips built right in. Add all to see the full list instead of the short version. No more guessing why things feel slow.

6. /compact shrink the chat before you're forced to

Here's the habit that changed the most for me: shrink the chat early, not after it's already a problem. /compact [instructions] sums up everything so far and frees up space. You can also tell it what matters most, so nothing important gets lost.

/compact keep the API requirements, database schema decisions and the Redis caching plan we agreed on

Wait too long and the summary itself gets made from a chat that's already struggling. Shrink it as soon as you're done exploring and ready to build.

7. /clear a real fresh start

This is different from /compact in a key way. Shrinking keeps a short version of your chat. /clear [name] wipes it completely and starts over but your project memory still loads back in automatically. Use it the moment you're moving to a new task, not halfway through the one you're on. Keeping one giant chat running across five unrelated jobs is exactly the habit that got me into trouble in the first place.

8. /model don't use the biggest tool for every job

Not every task needs your strongest, most expensive model working at full power. /model [model] switches which model is doing the work and it saves your choice for next time. A quick formatting fix doesn't need the same power as a tricky bug.

9. /effort how hard should it think?

This one pairs well with /model. /effort [level] controls how much thinking the model does from lighter levels for simple tasks, up to the highest levels for genuinely hard problems. Think: big changes across many files, tricky bugs, anything where more thinking time clearly helps. Full power on an easy task just wastes time and money. Low power on a hard task is where mistakes creep in.

My simple rule while I'm working: start with /plan. Check /context once things feel heavy. Run /compact before it's a real problem, not after. Run /clear the second I'm moving to something new.

Right Before You Ship

10. /diff look, don't guess

Before you commit, before you open a pull request, before you tell anyone "it's ready" run /diff. It shows every change in your project, including everything Claude has touched. It's the difference between trusting your memory and actually checking.

11. /code-review a second look, before a human looks

This one quietly caught more bugs for me than almost anything else on this list. /code-review checks your current changes or a pull request, a branch or a file path you give it for bugs and messy code. You can set how deep the check goes.

/code-review high

Run this before you push your code. It catches the small, silly mistakes the kind that are a bit embarrassing in a comment from a teammate before anyone else sees them.

12. /security-review a different kind of check

Bugs and security problems are not the same thing and that's why /security-review exists. It checks your changes just for security risks the kind of thing a normal code review can miss, because the code "works fine" on the surface. If your change touches logins, user input or anything talking over the network, don't skip this step.

When I actually run these: /diff every single time, no exceptions, right before I open a pull request. /code-review on anything more than a tiny change. /security-review any time logins, user input or the network are involved which, in backend work, is more often than you'd think.

When Something Goes Wrong

13. /rewind undo it cleanly

Every developer has had the moment where an AI-made change makes things worse, not better. The first instinct is to start undoing files one by one. /rewind instead pulls both the code and the chat back to an earlier point. You get a clean fix, instead of trying to remember what things looked like before.

14. /doctor a checkup for the tool itself

Sometimes the problem isn't your chat it's your setup. An old install, a broken settings file or some unused add-on quietly wasting space. /doctor runs a full check: install health, unused tools compared to what they cost you, oversized memory files and more. It tells you what it found first and asks before it changes anything. I run it every few weeks, the same way you'd get a checkup for anything else you use daily.

Group 2: 11 More Commands for Everyday Developer Work (Quick Reference Table)

The 14 commands above cover the core loop set up, work, ship, fix. But real work isn't always one clean task at a time. You get pulled into a second bug mid-feature. You want to try an idea without losing your current progress. You need to check how much a big session actually cost. This table lists all 11. Full details, with real-life examples, follow.

Picking Up Where You Left Off

15. /resume continue an earlier chat

You worked on a feature yesterday, closed your laptop and now you want to pick up exactly where you left off not start over and re-explain everything. /resume [session] reopens an earlier conversation by name or ID or shows you a list to pick from.

Real-life example: you're mid-way through building a checkout flow. You stop for the day. Tomorrow morning, instead of starting fresh, you type /resume and pick yesterday's session back up.

16. /rename name your session so you can find it later

If you're juggling more than one Claude Code session, "conversation from Tuesday" isn't a name you'll recognize a week from now. /rename [name] labels your current session and Claude can even suggest a name for you if you don't give one.

Real-life example: you're fixing an auth bug in one session and building a new feature in another. /rename auth-bugfix in the first one means you'll spot it instantly in your /resume list later.

Trying Ideas Without Losing Your Work

17. /branch try a different approach safely

Sometimes you want to test a different direction a different caching strategy, a different library without losing the approach you already have working. /branch [name] splits your current conversation into a new path. Your original stays exactly as it was and you can always go back to it with /resume.

Real-life example: your app currently uses Redis for caching and it works. But you're curious whether an in-memory cache would be simpler for your use case. /branch in-memory-cache-test lets you explore that idea in a safe copy, while the working Redis version sits untouched.

18. /fork hand off a task and keep working

/fork [prompt] is similar to /branch, but instead of switching into the new path yourself, it copies your conversation into a background session that runs on its own while you keep working in your current one.

Real-life example: you ask Claude to write a batch of unit tests for a module you just finished, /fork write unit tests for the pricing module and keep working on the next feature yourself while that runs in the background.

Getting More Done in Parallel

19. /background free up your terminal for something else

Some tasks take a while and don't need you watching every step. /background [prompt] detaches your current session so it keeps running on its own and gives you your terminal back to do something else.

Real-life example: you kick off a large, slow test suite fix and don't want to sit there watching the terminal. /background lets it keep working while you switch to reviewing a teammate's pull request.

20. /batch split a big job into smaller, parallel pieces

For a change that touches many files across a codebase, doing it one file at a time by hand is slow and easy to get wrong. /batch <instruction> breaks the job into smaller independent pieces and works on them at the same time, each in its own safe copy of the code.

Real-life example:

/batch convert every file under src/ from JavaScript to TypeScript

Instead of converting forty files one by one over two days, Claude breaks the migration into chunks and works through them together.

Working Across Machines and Folders

21. /cd move your session to a different folder

Sometimes the code you need to work on isn't in your current folder it's in a sibling project, like a shared frontend or design-system repo. /cd <path> moves your whole session there, keeping your conversation intact.

Real-life example: you've been working in a backend repo and now need to update the frontend that calls your new endpoint. /cd ../frontend-app moves you over without starting a new chat.

22. /add-dir read files from more than one folder at once

Different from /cd, this doesn't move you it just gives Claude access to an extra folder while you stay where you are.

Real-life example: your main project lives in one folder, but shares a component library kept in a separate repo on your machine. /add-dir ../shared-components lets Claude read that folder too, without leaving your current project.

Keeping Track of Cost and Side Questions

23. /cost check what a session is actually costing you

If you're keeping an eye on usage, whether for yourself or a team budget, /cost (also called /usage) shows the tokens and cost used in your current session.

Real-life example: before kicking off a big, all-day refactor, you check /cost to see how much your morning's work has used so far, so there are no surprises later.

24. /btw ask a side question without cluttering your task

Sometimes you have a quick, unrelated question in the middle of a task and you don't want it mixed into the main conversation's context. /btw [question] asks it separately, without adding it to your task's history.

Real-life example: you're deep in a database migration and a teammate asks what a certain HTTP status code means. /btw what does a 429 status code mean gets you the answer without derailing your actual task.

Saving Your Work Outside the Chat

25. /export save the conversation as a plain text file

If you want to save today's session for documentation, a handoff or just your own records, /export [filename] writes the whole conversation to a text file.

Real-life example: you just finished debugging a tricky production issue with Claude's help. /export incident-notes.txt saves the whole investigation so you can drop it into your team's incident report later.

Group 3: 9 More Commands for Tools, Delegation and Catching Problems Early

Once the first 25 commands are second nature, this last group covers a different kind of everyday need: talking to the other tools you already use, letting Claude run and check your app itself, splitting off specialized helpers and keeping your settings and integrations in shape without digging through menus.

Connecting the Tools You Already Use

26. /mcp connect Claude to services like Slack, GitHub or Jira

Most teams don't just write code they also track issues, chat with teammates and manage project boards in other tools. /mcp manages these connections, so Claude can read from and act on those services directly, instead of you copying details back and forth by hand.

Real-life example: your team tracks bugs in Jira. Instead of copy-pasting a ticket's description into the chat, you connect Jira through /mcp once and from then on you can just ask Claude to look up the ticket directly.

27. /import bring your setup over from another AI coding tool

If you've been using a different AI coding assistant and switch to Claude Code, you don't have to rebuild everything from scratch. /import brings over instruction files, connected tools and custom commands from tools like OpenAI Codex or Google's Gemini CLI.

Real-life example: you've spent months tuning a setup in another tool and don't want to lose that work just because you're trying Claude Code. /import carries the useful parts over.

Letting Claude Actually Run and Check Your Work

28. /run see your app working, not just the tests passing

Tests passing doesn't always mean the feature actually works the way a real person would experience it. /run launches your project and interacts with it directly, so you can see the real behavior, not just a green checkmark.

Real-life example: you just built a new signup form. The unit tests pass, but you want to actually watch it render and submit correctly before calling the feature done. /run does that check for you.

29. /debug get to the bottom of something that isn't working right

When Claude Code itself is behaving strangely not your app, the tool /debug [description] turns on detailed logging and helps you dig into what's actually happening under the hood.

Real-life example: Claude keeps failing silently on one particular file and you can't tell why. /debug reading errors on the config file turns on logging and helps track down the real cause.

Delegating and Automating Repeated Work

30. /agents build a specialist for one specific job

Not every task should go through your main conversation. Some jobs are cleaner as a separate, focused helper one whose whole job is, say, running your test suite and reporting back. Typing /agents points you toward setting one of these up: either by asking Claude directly to create or manage a subagent or by editing the subagent config files yourself.

Real-life example: instead of asking your main coding session to also babysit the test suite, you ask Claude to create a dedicated subagent whose only role is running tests and summarizing failures, keeping your main conversation focused on the actual feature.

31. /loop check on something repeatedly without you watching it

Some things need checking more than once, but not constantly by hand. /loop [interval] [prompt] repeats a prompt on a schedule while your session stays open.

Real-life example: you just triggered a deployment and want to know the moment it finishes, one way or another. /loop 5m check if the deploy finished checks every five minutes, so you don't have to keep refreshing a dashboard yourself.

Small Daily Conveniences

32. /copy grab exactly the code you need, not the whole answer

When Claude's answer includes more than one code block, copying the whole reply and manually deleting the parts you don't need wastes time. /copy lets you pick just the block you actually want.

Real-life example: Claude gives you three code snippets in one answer a function, a test and a config change. /copy lets you grab just the function, without touching the clipboard mess of the other two.

33. /config change a setting without hunting through menus

Sometimes you just want to flip one setting a theme, a default model without opening a full settings screen. /config lets you set it directly with a single short command.

Real-life example: you want a darker theme and a different default model for a new project. /config theme=dark model=sonnet does both in one line, no menu-digging required.

34. /ide check that your editor is actually connected

If Claude Code is supposed to be working alongside your editor, but something feels off, this tells you the real status instead of guessing. /ide shows and manages your editor integration.

Real-life example: you open your IDE expecting Claude Code to be linked, but nothing seems to sync. /ide shows you the connection status, so you know if it's actually working or needs reconnecting.

My Real Workflow

After using Claude Code for a lot of real work, not just small demos, here's what I've learned: managing your session matters just as much as writing good prompts.

It's easy to treat an AI coding tool like it has no limits like you can throw anything at it, forever. It doesn't work that way. Context is a limited resource, just like memory on your computer or space on your hard drive. It stops working well the moment you let unrelated work pile up in one place.

The change that stuck with me was small, but it changed everything: I stopped thinking of a Claude Code session as "a chat." I started thinking of it as a workspace something you set up for one task, clean up often and check instead of just trust. Once that clicked, none of these commands felt like a list to memorize anymore. They just became the normal thing to do.

Old Habit vs. New Habit

None of these commands are hidden behind some special plan. They're built in, right there the moment you type /. The only thing between wasting months and using this tool well is knowing they exist and building the habit of using them.

FAQ

This guide is based on my own daily use of Claude Code. Every command's details were checked against Anthropic's official documentation, not written from memory. Because Claude Code changes often, treat /help in your own install as the final, correct source.