The Claude Code Commands Most People Never Find

I have watched a lot of smart people use Claude Code the same way: they open a terminal, type a request in plain English, wait for the answer, and close the window. That works. It is also like buying a car and only ever using first gear.

Claude Code ships with a surprisingly deep set of built-in commands, keyboard shortcuts, and configuration tricks — and almost none of them announce themselves. There is no toolbar. There is no ribbon of icons reminding you they exist. If you never type / and pause to look at the menu that pops up, you can use the tool for months without discovering that half of your frustrations already have a one-line fix.

This post is the tour I wish someone had given me in week one. It is not a reference manual — the official docs cover every flag if you want them. This is a curated list of the commands that actually change how the tool feels day to day, written for people who are not full-time developers. For each one I will tell you three things: what it does in plain English, when someone who does not write code for a living would reach for it, and a mini-workflow you can copy.

I have grouped everything into four buckets:

• Daily drivers — the commands you will use every single session once you know them.
• Context savers — the ones that stop Claude from getting slow, forgetful, and expensive.
• Power moves — the features that turn one-off requests into repeatable workflows.
• Safety valves — the guardrails, and the one flag you should almost never touch.

There is a printable cheat-sheet table at the end. Let's go.

---

Part 1: Daily drivers

These are the commands I use in almost every session. None of them are exotic. All of them are easy to miss.

/init — let Claude write its own briefing document

What it does. Typing /init tells Claude to explore your project folder and write a file called CLAUDE.md — a short briefing document about what the project is, how it is organized, and any conventions it notices. From then on, Claude reads that file automatically at the start of every session in that folder.

Why non-developers should care. You might think this is only for codebases. It is not. A "project" can be a folder of markdown notes, a set of spreadsheets, a content calendar, a folder of contracts. /init is how you stop re-explaining your setup at the start of every conversation. Instead of typing "this folder contains my newsletter drafts, the naming convention is date-topic, the tone guide is in style.md" every single time, you say it once and it lives in the briefing file forever.

Mini-workflow.

1. Open Claude Code in the folder where you actually work — not your home directory, the specific project folder.
2. Type /init and let it look around.
3. Read the generated CLAUDE.md. Delete anything wrong, and add the two or three things Claude could not have guessed: your goals, your preferences, the stuff you keep repeating.
4. Start a fresh session and notice that Claude already "knows" the project.

The five minutes you spend editing that file pay back every session afterward. It is the single highest-leverage command on this list, and I would guess fewer than half of casual users have ever run it.

/model — pick the right brain for the job

What it does. /model lets you switch which Claude model powers your session — mid-conversation, no restart needed. Bigger models are smarter and slower and cost more; smaller models are faster and cheaper and perfectly fine for routine work.

Why non-developers should care. Most people run the default model for everything, which means they are either overpaying for simple tasks or under-powering hard ones. Renaming fifty files does not need the flagship model. Untangling a messy financial analysis does. Knowing that the switch exists — and that it takes two seconds — changes how you budget your usage.

Mini-workflow.

1. Start your session on a fast, cheap model for the grunt work: file cleanup, summaries, formatting.
2. When you hit the genuinely hard part — the ambiguous decision, the tricky analysis — type /model and switch up to the strongest option.
3. Do the hard thing, then switch back down.

Think of it like gears again. You do not drive to the shops in fifth gear, and you do not merge onto a motorway in first.

/config — the settings menu nobody opens

What it does. /config opens Claude Code's settings inside the terminal: theme, notification behavior, editor preferences, model defaults, and more. Arrow keys to move, enter to change, escape to leave.

Why non-developers should care. Because small irritations compound. If the color scheme is hard to read, if you keep missing when a long task finishes, if the default model is not the one you want — those are all thirty-second fixes hiding in /config. People tolerate friction for months that a settings screen would have removed on day one.

Mini-workflow.

1. Type /config right now, in your next session.
2. Turn on completion notifications so you can go do something else while Claude works on a long task and get pinged when it finishes.
3. Set your preferred default model so you stop paying flagship prices for routine sessions.

That is it. Two minutes, once, and the tool fits you better forever.

/help — the menu you forgot existed

What it does. /help lists the available commands and shortcuts for your version of Claude Code, right there in the terminal.

Why non-developers should care. Claude Code updates often, and new commands appear without fanfare. /help is the cheapest way to discover them. It is also the honest answer to "how do I find things like the ones in this post after this post is out of date."

Mini-workflow. Once a month, type /help and skim the list for anything you do not recognize. Ask Claude itself — in plain English, in the same session — "what does that new command do and when would I use it?" The tool is very good at explaining itself. Almost nobody asks.

@-mentioning files — stop describing, start pointing

What it does. Type @ in your message and Claude Code pops up a file picker. Keep typing to filter, hit tab or enter, and the file path drops into your message. Claude then reads that exact file as part of your request.

Why non-developers should care. This is the difference between "can you look at my budget spreadsheet, it's in the finance folder, I think it's called budget-2026 or maybe budget_final" and @finance/budget-2026.csv. No ambiguity, no wasted turns while Claude hunts for the right file, no risk it reads the wrong version. It is the fastest precision tool in the whole product and it is completely invisible until someone shows you.

Mini-workflow.

1. Instead of describing a file, type @ and start typing its name.
2. Mention two files in one message to make comparisons trivial: "Compare @drafts/v1.md with @drafts/v2.md and tell me which intro is stronger and why."
3. Combine with a verb and a constraint: "Summarize @notes/meeting-july.md into five bullet points for an email to my manager."

Once @-mentions are in your muscle memory, sessions get noticeably shorter, because you skip the entire "find the file" negotiation.

Pasting images — yes, it takes screenshots

What it does. You can paste an image straight into the Claude Code prompt (on most systems, copy a screenshot and paste with the usual shortcut — note that in some terminals it is ctrl+V rather than cmd+V on a Mac). Claude sees the image and can reason about it.

Why non-developers should care. Because so much of real work is visual. An error dialog you do not understand. A chart from a PDF. A screenshot of a web page layout you want to imitate. A whiteboard photo from a meeting. Describing these in words is slow and lossy; pasting them is instant and exact.

Mini-workflow.

1. Take a screenshot of the thing — error message, chart, design, form.
2. Paste it into the prompt and ask a specific question: "What is this error actually telling me, and what is the safest fix?" or "Turn the table in this screenshot into a CSV file."
3. For layout work: paste a screenshot of a page you like, then say "make my page's header section feel like this — spacing and hierarchy, not the exact colors."

The screenshot-of-an-error workflow alone is worth the price of admission. It removes the step where you try to retype an error message correctly, which humans are famously bad at.

---

Part 2: Context savers

Here is the mental model that unlocks this whole section: Claude's memory of your conversation — its "context window" — is a finite whiteboard. Everything you say, every file it reads, every command output scrolls onto that whiteboard. When it fills up, two bad things happen: responses get slower and more expensive, and the important early stuff gets crowded out by noise. The commands in this section are whiteboard management. They matter more than any other skill in this post.

/clear vs /compact — the two erasers, and when to use which

What they do. /clear wipes the whiteboard completely — new conversation, blank slate, though Claude still reads your CLAUDE.md briefing. /compact is subtler: it asks Claude to summarize the conversation so far, throw away the raw transcript, and continue with just the summary. You keep the gist and lose the bulk.

Why non-developers should care. Because the number one silent failure mode in long sessions is a bloated context. You have felt it even if you did not name it: the session that started sharp and got vague, the moment Claude "forgot" something you said an hour ago, the responses that take longer and longer. That is a full whiteboard. Most people's response is to keep pushing. The right response is one of these two commands.

When to use which. This is the part people get wrong, so here is my rule:

• Use /clear when you are switching tasks. Finished the report, moving on to the email backlog? Clear. The old conversation is not context, it is contamination — leftover instructions from task one will subtly warp task two.
• Use /compact when you are mid-task and the session is getting heavy. You still need the decisions and findings so far, but you do not need the two hundred lines of file contents Claude read forty minutes ago.

Mini-workflow.

1. Finish a task? /clear before starting the next one. Make it a habit, like closing tabs.
2. Deep in a long task and things feel sluggish? Type /compact with a hint about what matters: /compact focus on the pricing decisions and the list of files we changed. That instruction shapes the summary, so the things you care about survive the compression.
3. If a session has gone truly sideways — Claude confused, wrong turns compounding — do not compact the confusion. /clear, then restate the task cleanly in one message. Starting over with a good prompt beats continuing with a bad transcript every single time.

If you take one habit from this article, take this one. I wrote a whole post on cutting token usage in half, and honestly, disciplined use of these two commands is most of the trick.

/memory and the # shortcut — teach Claude things permanently

What it does. /memory opens the memory files Claude reads at the start of every session — including your project's CLAUDE.md and your personal global one — so you can edit them directly. The # shortcut is the quick version: start a message with # followed by a fact or preference, and Claude Code offers to save it to memory for you, no file editing required.

Why non-developers should care. Because repeating yourself is the most common waste in AI-assisted work. "Always write in UK English." "Never touch the archive folder." "My boss's name is spelled Katarzyna, not Katarina." If you have said something to Claude three times, it belongs in memory, not in your typing fingers.

Mini-workflow.

1. The moment you catch yourself re-stating a preference, prefix it with #: # always give me file sizes in MB, not bytes. Accept the save prompt.
2. Once a month, type /memory, open the files, and prune. Memories accumulate like drawer clutter; ruthless deletion keeps the useful ones sharp.
3. Keep project-specific facts in the project memory and personal style preferences in your global memory (more on that split in the CLAUDE.md section below).

The # shortcut is the most underrated two keystrokes in the product. It turns "training Claude" from a chore into a reflex.

/resume and --continue — never lose a conversation again

What they do. Claude Code saves your conversations. Launch it with claude --continue and it reopens your most recent session in that folder, exactly where you left off. Type /resume (or launch with claude --resume) and you get a picker listing recent sessions so you can jump back into any of them.

Why non-developers should care. Because life interrupts. Your laptop restarts. A meeting starts. You close the terminal by reflex. Most people assume the conversation is gone and rebuild the context from scratch — re-explaining the task, re-pasting the files, re-litigating decisions already made. Every bit of that is unnecessary. The session is still there.

Mini-workflow.

1. Interrupted mid-task? Just close the terminal. Do not write yourself notes about where you were.
2. Next time, launch with claude --continue. You are back in the same conversation with everything intact.
3. Working on multiple things? Use /resume and pick from the list. The sessions are labeled by their opening exchanges, so give each new task a clear first message ("Task: reconcile Q2 invoices against the ledger") and your future self can find it instantly.
4. Powerful combo: /resume an old session from last week, then immediately /compact it, and you have a fresh-feeling session with all of last week's conclusions preserved.

CLAUDE.md tricks — project memory vs. global memory

What it does. CLAUDE.md is the briefing file that /init creates, and Claude reads it automatically every session. The trick most people miss is that there are two levels. A CLAUDE.md in your project folder applies to that project. A CLAUDE.md in your home directory's .claude folder (~/.claude/CLAUDE.md) applies to every project, everywhere. They stack: Claude reads both.

Why non-developers should care. Because it lets you separate "who I am" from "what this project is." Your writing voice, your formatting preferences, your standing rules ("always ask before deleting anything") belong in the global file — write them once, and every project inherits them. The project file holds only what is specific: this folder's structure, this client's terminology, this deliverable's requirements.

Mini-workflow.

1. Create ~/.claude/CLAUDE.md and put in five lines: your preferred tone, your language/locale, your "never do this" rules, and how you like answers formatted.
2. In each project's CLAUDE.md, keep only project facts. If you find yourself copying the same line into a third project file, that line is global — move it up.
3. Keep both files short. These files are read every single session, which means they spend your context budget every single session. A tight ten-line briefing beats a rambling hundred-line one. Bullet points, imperatives, no prose.
4. When Claude does something annoying twice, do not just correct it in chat — add one line to the appropriate CLAUDE.md so it never happens again. This is the flywheel: every correction becomes permanent.

---

Part 3: Power moves

Everything above makes sessions smoother. This section is different: these features change what kind of tool Claude Code is. This is where one-off requests become repeatable workflows — which, if you have read anything else on this site, you know is the whole game.

Plan mode (shift+tab) — make Claude think before it acts

What it does. Press shift+tab and Claude Code cycles through permission modes. One of them is plan mode: Claude can read files and think, but it cannot change anything. It researches your request, presents a step-by-step plan, and waits for your approval before touching a single file.

Why non-developers should care. This might be the most important feature in this post for anyone nervous about letting an AI loose on their files — which should be everyone, at least a little. Plan mode converts "I hope it does the right thing" into "I read what it intends to do and said yes." For anything involving many files, anything destructive, or anything you would struggle to undo, plan mode is the difference between delegation and gambling.

Mini-workflow.

1. Before a big or scary request — "reorganize my documents folder by year and topic" — press shift+tab until you see plan mode indicated.
2. Make the request. Claude will explore, then present a numbered plan: what it will move, what it will rename, what it will not touch.
3. Read the plan like you would read a contractor's quote. Push back in plain English: "don't touch anything in Archive, and show me the mapping before renaming."
4. When the plan is right, approve it, and Claude switches to execution.

The deeper benefit is quality, not just safety. Forcing a planning step produces better outcomes on complex tasks, for Claude exactly as for humans. I use plan mode for anything I estimate will take more than a few minutes of Claude's work.

! — the shell passthrough

What it does. Start a line with ! and everything after it runs directly as a terminal command — Claude does not interpret it, the computer just executes it, and the output lands in your conversation where both you and Claude can see it.

Why non-developers should care. Even if you only know five terminal commands, this is useful, because it stitches your commands and Claude's understanding together. Run !ls to list the current folder's files without spending a Claude turn on it. Run a script you already trust with !./monthly-report.sh and then ask Claude, in the very next message, to interpret the output. The command result is right there in context — no copying, no pasting, no "let me describe what the output said."

Mini-workflow.

1. Quick orientation: !ls or !pwd to see where you are and what is here, instantly and for free.
2. Run-then-interpret: !git log --oneline -10, then ask "summarize what changed this week in plain English for my status update."
3. Verify Claude's work yourself: after Claude edits files, run your own check command with ! and let both of you look at the result together.

Small feature, big habit. It keeps you in the driver's seat while keeping Claude fully informed.

Custom slash commands — your prompts, saved as buttons

What it does. Any markdown file you drop into a .claude/commands folder inside your project becomes a custom slash command. A file called weekly-report.md containing a well-crafted prompt becomes /weekly-report, available in that project forever. Put the file in ~/.claude/commands instead and the command works in every project. Commands can even take arguments — write $ARGUMENTS in the file, and whatever you type after the command name gets substituted in.

Why non-developers should care. This is the repeatable-workflows feature, full stop. Everyone has three or four prompts they have slowly perfected — the meeting-notes formatter, the email-tone rewriter, the data sanity-checker. Right now yours probably live in a notes app, and you paste them in like a medieval scribe. Custom commands turn each one into a two-word invocation.

Mini-workflow.

1. Find your best recurring prompt — the one you have honed over months.
2. Ask Claude to do the setup for you, in the session itself: "Create a custom slash command called tidy-notes in this project's .claude/commands folder. It should take my raw meeting notes as input and produce: decisions, action items with owners, and open questions, in that order." Yes, Claude Code can create its own commands. This is the least appreciated bootstrap in the whole tool.
3. Next time: /tidy-notes followed by a paste of your raw notes. Done.
4. When a command's output disappoints, do not just fix it in chat — edit the command file (or ask Claude to), so the fix is permanent. Your commands should improve the way software improves: versioned, cumulative, shared. And since .claude/commands is just a folder of text files, you can share it with your whole team by putting it in the project repository. One person's perfected prompt becomes everyone's button.

If you build only one thing after reading this post, build a custom command. It is the moment Claude Code stops being a chat window and starts being your tool.

Hooks, in one paragraph

Hooks are small automations that fire automatically at specific moments — before Claude runs a command, after it edits a file, when it finishes responding — without you asking each time. In plain English: "every time Claude edits a document, automatically run my formatting script" or "before Claude runs any command that deletes things, require an extra confirmation" or "when a long task finishes, send a notification to my phone." They are configured in Claude Code's settings file, and the honest advice for non-developers is: do not hand-write them; describe the automation you want to Claude in plain English and let it set the hook up for you, then test it on something unimportant. The thing to know is simply that this layer exists — when you catch yourself thinking "I wish this happened automatically every time," that thought has a home, and its name is hooks.

Headless mode, in one paragraph

Everything so far assumes you are sitting there typing, but Claude Code can also run non-interactively: you launch it with a prompt as part of the command itself (the -p flag), it does the work, prints the result, and exits — no conversation, no chat window. Why would you care? Because it means Claude can become a step inside other automation. A scheduled job that summarizes yesterday's customer feedback file every morning at 8am. A script that, whenever you drop a PDF into a folder, extracts the tables into a spreadsheet. You do not need to build these yourself — you describe them to interactive Claude Code and ask it to write the script that calls its headless twin. The concept to file away: Claude Code is not just a chat tool, it is an ingredient. When a workflow becomes truly routine, it can graduate from "something I ask for" to "something that just happens."

---

Part 4: Safety valves

Power tools need guards. Claude Code's default posture is actually quite careful — it asks permission before running commands or editing files — and this section is about understanding that system rather than fighting it.

The permission system is a feature, not friction

When Claude Code asks "may I run this command?" or "may I edit this file?", casual users experience it as nagging and look for ways to make it stop. Experienced users see it for what it is: a review checkpoint. Those prompts are Claude showing its work before the work happens, which is exactly when you want to see it.

The mature way to reduce the nagging is not to disable it but to shape it. You can allow specific, safe operations permanently — "always allow reading files," "always allow this particular script" — while keeping prompts for anything destructive. Claude Code remembers your "always allow" choices per project in its settings. Over a week or two, the prompts naturally converge to appearing only when something genuinely deserves your attention. That is the system working, not the system getting out of your way.

Mini-workflow.

1. When prompted for something you consider obviously safe and expect to recur, choose the "always allow" option rather than plain "yes."
2. Keep manual approval for anything that deletes, sends, publishes, or spends.
3. For big risky tasks, combine with plan mode (shift+tab) so you approve the strategy first and the individual steps second.

--dangerously-skip-permissions — the flag with a warning label built into its name

What it does. Launching Claude Code with --dangerously-skip-permissions turns off all permission prompts. Claude runs whatever commands and makes whatever edits it decides to, with no checkpoints, until the session ends.

Why you should almost never use it. Read the flag name again. The developers did not call it --fast-mode or --expert-mode; they named it to make you wince, and that is not marketing. Here is the plain-English risk: Claude is very capable and mostly right, but "mostly right, fully autonomous, and irreversible" is a bad combination. A misunderstood instruction that would normally die at a permission prompt — deleting the wrong folder, overwriting a file you needed, running a command with a typo'd path — instead just happens. There is also a subtler danger: if Claude reads content from the outside world (a web page, a downloaded file) that contains malicious instructions, the permission prompt is the checkpoint where you would catch it acting on them. Skip permissions, and you have removed the tripwire.

People who use this flag legitimately do so in disposable environments — sandboxed machines or containers where the worst case is "throw it away and start over." If the words "disposable environment" do not describe your laptop — and they do not — then this flag is not for you. If permission prompts are annoying you, the fix is the previous section: allow-list the safe stuff, keep prompts for the sharp stuff, and use plan mode. You get ninety percent of the smoothness with none of the "I deleted what?" mornings.

That is the strongest opinion in this post, so let me say it flat: do not run --dangerously-skip-permissions on a machine that has files you care about. No workflow speedup is worth it.

---

The cheat sheet

Print this, stick it next to your monitor, and in two weeks you will not need it anymore.

Command / shortcut	What it does	Reach for it when…
/init	Writes a CLAUDE.md briefing about your project	First session in any new folder
/model	Switches the model mid-session	Grunt work vs. hard-thinking work
/config	Opens the settings menu	Notifications, theme, defaults annoy you
/help	Lists available commands	Monthly, to catch new features
@file	Points Claude at an exact file	Any time you'd otherwise describe a file
Paste image	Lets Claude see a screenshot	Errors, charts, layouts, whiteboards
/clear	Wipes the conversation completely	Switching to a new task
/compact	Summarizes and slims the conversation	Mid-task, session getting heavy
# prefix	Saves a fact to memory instantly	You've repeated a preference twice
/memory	Opens memory files for editing	Monthly pruning; bigger edits
claude --continue	Reopens your last session	Interrupted, laptop restarted
/resume	Picker for any recent session	Juggling multiple ongoing tasks
~/.claude/CLAUDE.md	Global briefing for all projects	Personal style rules, standing orders
shift+tab (plan mode)	Claude plans, you approve, then it acts	Big, destructive, or hard-to-undo tasks
!command	Runs a shell command directly	Quick checks; run-then-interpret
.claude/commands/*.md	Your saved prompts as slash commands	Any prompt you've used three times
Hooks	Automations that fire on events	"I wish this happened every time"
claude -p "…"	Headless one-shot run, no chat	Scheduled and scripted workflows
"Always allow" choices	Permanently permits safe operations	Prompts recurring on obviously-safe steps
--dangerously-skip-permissions	Disables all safety prompts	Almost never. Disposable machines only

---

Where this leaves you

Twenty-ish commands is a lot to absorb in one read, so do not try. Here is the adoption order I would suggest instead, one habit a week:

1. Week one: /init in your main project, plus /clear between tasks. This alone fixes most "Claude got dumber" complaints.
2. Week two: @-mentions and image pasting. Precision in, precision out.
3. Week three: the # memory shortcut and a five-line global CLAUDE.md. Stop repeating yourself.
4. Week four: your first custom slash command. This is the graduation moment — the day your workflow becomes an artifact you can improve and share instead of a habit you keep in your head.

The pattern behind every item on this list is the same one behind everything I write here: the gap between casual AI users and effective ones is not talent or technical background. It is that effective users turn every discovery into something repeatable — a memory entry, a briefing file, a saved command — while casual users rediscover the same tricks forever. The commands are just the mechanism. The habit is the point.

Resources & links

• /blog/claude-code-explained-for-normal-people — Start here if the terminal still feels foreign: what Claude Code actually is, minus the jargon.
• /blog/cut-claude-token-usage-in-half — The context-hygiene deep dive: why /clear and /compact save real money.
• /blog/claude-workflow-template — My reusable template for turning any recurring task into a documented Claude workflow.
• /blog/six-claude-prompts-ahead-of-99-percent — Six prompts worth converting into custom slash commands today.
• /blog/most-popular-ai-coding-skills — A ranked tour of the skills people actually install and why.
• /skills/superpowers — A skill pack that layers structured workflows on top of the commands in this post.
• /skills/skilld — Helps Claude discover and load the right skill at the right moment.
• /skills/gsd-core — A getting-things-done core loop for Claude: plan, execute, verify, repeat.
• /skills/karpathy-guidelines — Coding-with-AI guidelines distilled into a skill Claude follows automatically.
• /skills/context-engineering — Practical patterns for keeping the context window lean, as a skill.
• /skills/ship-skills-with-package — How to bundle and share your custom commands and skills with your team.

If this was useful, I send one practical, hype-free issue like it every week — join me at https://alexandrrich.substack.com.