The Claude Code Features Actually Worth Learning
Claude Code has accumulated a lot of surface area. Shortcuts, slash commands, CLI flags, hooks, skills, scheduled jobs, worktrees, remote control, multiple models. It is easy to read a feature list and come away no more productive than when you started.
This piece is organized differently. Instead of walking through every flag and key, it groups the features that actually move the needle around the problems they solve. If a feature does not show up here, it is usually because the gain is marginal compared to getting the fundamentals right.
Problem 1: Your context window keeps filling up
The single biggest productivity gap between new and experienced users is context hygiene. If your session gets slow and vague around hour two, context is almost always the reason.
Three tools handle this:
/contextshows a usage graph. Glance at it occasionally. If you are past 80 percent, you are about to hit a wall./compactreplaces the conversation with a compressed summary and keeps going. You can pass an instruction ("keep only the decisions about auth") to focus the summary on what still matters./btwlets you ask a drive-by question without it landing in the main history. The answer uses the current context for relevance but does not pollute it. Good for "wait, which flag does that again."
/clear is the nuclear option. Prefer /compact unless you are switching to a genuinely unrelated task, because compaction keeps decisions and file state; clearing loses both.
Problem 2: You are waiting when you could be working
The default loop (wait for Claude, read output, type next prompt) has a lot of dead time. Two features flip that.
Background tasks. When you kick off something slow, like a full test run or a large refactor, press Ctrl+B. The task keeps running and the prompt returns to you. Ctrl+T shows the list of what is cooking.
Loops. /loop 10m npm test re-runs tests every ten minutes in a fresh context. This is strictly local and stops when your laptop sleeps, so do not rely on it for anything that needs to survive the night. For that, use /schedule, which runs in the cloud on whatever cadence you specify.
The trap to avoid: it is tempting to /loop everything. Loops that produce noisy output will fill your conversation with reports you do not read. Keep them tightly filtered.
Problem 3: "Show me git status" is a three-step process
Any time you want Claude to just read something, prefixing a line with ! runs the shell command directly, no reasoning step, no tool selection, no preamble.
!git status
!rg -n "TODO" src/
!cat package.json | jq .version
The output still enters the conversation, so avoid commands that gush. The rule I use: ! for "I just want to see the answer," natural prompts for anything that needs a decision.
@ does the same kind of shortcut for file references. @src/auth/login.ts is a tab-completing path that beats the vague "look around in auth" prompt, both in accuracy and token use.
Problem 4: You keep re-explaining the project
Two features cover this, and most people pick the wrong one.
CLAUDE.md is the persistent project instructions file. Run /init once in a new repo and it will scan your code and scaffold a starter. The good parts to add by hand: build and test commands, the stack, anything non-obvious about the code. HTML comments inside CLAUDE.md are stripped when Claude auto-injects the file, so you can park team notes in <!-- ... --> without cluttering Claude's view.
Skills are reusable, named instruction bundles, stored under .claude/skills/NAME/SKILL.md. They are the right home for workflows you run often: "draft a PR description," "write a blog post," "investigate a Sentry error." A skill has frontmatter for allowed tools, model choice, and whether the user can call it directly. Skills win over CLAUDE.md entries any time the instructions are long, specialized, or only matter in a specific context. CLAUDE.md wins when the rule should apply to every turn.
Problem 5: Claude is about to do something you do not want
The permission system has four modes, cycled with Shift+Tab:
| Mode | When to use it |
|---|---|
default |
Normal work. Reads are free, writes and commands prompt you. |
acceptEdits |
You are confident about scope. Edits apply without prompts; commands still prompt. |
auto |
A safety classifier handles routine stuff. Dangerous operations still block. |
plan |
Claude proposes; you approve before anything runs. |
For harder guarantees, --allowedTools and --disallowedTools at startup give you a whitelist and blacklist. "Bash(rm -rf *)" on the disallow list is cheap insurance.
For the hardest guarantees, use hooks. A PreToolUse hook can reject a tool call by exit code before it runs. A PostToolUse hook can run a formatter or linter every time a file is written. Hooks are plain shell, configured in settings.json (or interactively with /hooks), and they execute unconditionally, so they are the right tool for rules that must not be bypassed.
Problem 6: You want to try something risky
/rewind (or double-tap ESC) reverts the last batch of file edits Claude made. This turns "try, see, revert if wrong" into a cheap operation. You can iterate aggressively before committing, with the rewind as a safety net.
For branch-level isolation, start Claude inside a git worktree with -w feature-x. The worktree lives on its own directory, so your main branch stays clean while you experiment. Multiple worktrees can run in parallel in different terminals. Tag each one with /color and /rename so you do not confuse sessions.
Problem 7: Large monorepos are painful to open
If your repo has hundreds of packages and Claude stalls on startup scanning them, configure sparse worktrees:
{
"worktree": {
"sparsePaths": ["packages/my-service", "shared/utils"]
}
}
Only the listed directories get checked out. Under the hood this is git sparse-checkout in cone mode, so specify directory paths, not globs.
Problem 8: You want one-shot automation, not a chat
For CI, scripts, and cron jobs, the pattern is claude --bare -p "prompt".
--bareskips hooks, plugin sync, skill scans, and CLAUDE.md auto-detection. Startup is dramatically faster.-p "prompt"runs non-interactively. Combine with--output-format jsonto parse the response in a script.--max-turns Ncaps how many turns the agent can take. Always set this in automation. Runaway agents are cheap to create and expensive to run.
A typical pipeline step:
claude --bare \
-p "Review this diff for security issues" \
--max-turns 8 \
--permission-mode auto \
--model sonnet < diff.patch
Problem 9: You need to pick up yesterday's session
claude -c resumes the most recent session. claude -r "auth refactor" resumes by name if you named it with /rename. For PR review work, claude --from-pr 142 restores the session tied to that PR so you can pick up reviewer comments the next day without rebuilding context.
Problem 10: Something is wrong and you are not sure what
/doctor runs a set of environment and configuration checks: MCP server status, keybinding warnings, plugin issues. It is the right first move when anything feels off, before you start guessing.
Ctrl+F pressed twice within three seconds force-stops every background agent. Worth remembering when something is spinning in a direction you did not intend.
What to ignore
A few features get hyped disproportionately. My honest take:
- Voice input works but is slower than typing for most code-adjacent prompts.
- Remote control from claude.ai is useful for one specific workflow (checking on a session from your phone) and otherwise a curiosity.
--efforttuning matters for architectural decisions and is noise for day-to-day edits. Leave it on the default.- Model switching mid-session is tempting but usually premature optimization. Pick Sonnet by default, drop to Haiku only when you are clearly running through trivial prompts.
The short version
If you do nothing else from this list: run /context periodically, use /compact before the wall, and move long tasks to the background with Ctrl+B. Those three habits make more difference than any ten keyboard shortcuts.