2026-10-06 Practical Claude Code Commands for Developers

Type / in Claude Code and you get dozens of commands. Instead of memorizing them, I picked what heavy users keep recommending. I read the official best-practices guide, a write-up of how Claude Code's creator Boris Cherny works, and developer tip collections, then checked every command against the official docs.

Based on the official Claude Code docs as checked on 2026-10-06. Claude Code ships updates often, so names and behavior can change, and some features depend on your version, plan, or settings. Typing / or running /help shows what's available in your setup.

0. What people agree on

Different sources keep landing on the same advice. The commands are just tools for these habits.

1. Context is the most important resource. The official docs say most best practices come from one constraint: the context window fills fast, and performance degrades as it fills. That's why "use /clear often" is the most common tip.
2. Plan before coding. Both Boris Cherny's workflow and the official docs describe refining a plan in plan mode first, which often lets the implementation land in one go.
3. Give Claude a way to check its own work. Boris Cherny calls this the most important tip. Tests, builds, or browser checks that return pass/fail let Claude iterate on its own.
4. Keep CLAUDE.md short and update it when Claude slips. Boris Cherny's team records Claude's mistakes in CLAUDE.md so they don't repeat. A file that's too long buries its own rules.
5. Don't over-configure up front. Several sources advise starting close to the defaults and adding plugins or skills only when a pain point repeats.

If you're new, start with these five

1. Starting and resuming

/init — create a project guide

Reads the project and writes CLAUDE.md, loaded at the start of every session. Treat it as a draft. The official docs suggest asking of each line, "Would removing this cause Claude to make mistakes?" If not, cut it.

Knowledge you only need sometimes belongs in a skill (section 7). /context confirms CLAUDE.md loaded.

Older articles often suggest a # prefix to add memory notes. It isn't in the current shortcut reference. Use /memory to edit CLAUDE.md, or ask Claude to add the rule.

claude -c, claude -r, /resume, /rename — pick up where you left off

claude -c                    # continue the most recent conversation in this directoryclaude -r "oauth-migration"  # resume a session by name or ID

The docs suggest naming sessions and treating them like branches, each workstream with its own context. Use /rename in a session and /resume to pick one.

2. Managing context

/clear — the most recommended command

Starts a new conversation with empty context; the old one is still available via /resume. Two failure patterns from the official docs:

• The kitchen-sink session: unrelated questions in the middle of a task fill the context with noise. → /clear between tasks.
• Correcting over and over: if two corrections haven't fixed it, the context is full of failed attempts. → /clear and write a better first prompt using what you learned.

The docs put it plainly: a clean session with a better prompt almost always beats a long session full of corrections.

/compact [instructions] — same task, more room

Summarizes the conversation to free space. You can steer it:

/compact focus on the API changes and remaining TODOs

Same task → /compact, new task → /clear. You can also tell CLAUDE.md what must survive compaction, e.g. "When compacting, always keep the list of modified files and test commands."

/context and the status line

/context shows usage as a colored grid with suggestions. For a constant view, /statusline puts model, git branch, context usage, and more at the bottom of the screen; describe what you want and it configures it. Both the official docs and the claude-code-tips repo recommend this early.

/btw — a side question that stays out of history

/btw which Java version does this project use?

"Use subagents to investigate"

Not a command, but a habit the docs stress. Exploring a codebase reads many files, all of which take context. Subagents explore in a separate context and return a summary.

Use subagents to investigate how our auth system handles token refresh,and whether we have OAuth utilities I should reuse.

3. Undo and safety nets

Esc — stop mid-turn

If it's heading the wrong way, press Esc right away. Work so far is kept, so you can redirect. Ctrl+C clears input or exits, so use Esc to stop.

Esc Esc / /rewind — rewind and partial summaries

With an empty input, double Esc opens the rewind menu (same as /rewind). Every prompt creates a checkpoint, and you can:

• Restore conversation only, code only, or both
• Summarize from here / up to here: compact only part of the conversation, finer-grained than /compact

Checkpoints let you try a risky approach and rewind if it fails. But they only track edits made through Claude's file editing tools; files changed by Bash commands aren't captured, so this doesn't replace git.

Shift+Tab, /plan, Ctrl+G — plan first

Shift+Tab cycles permission modes:

• default (Manual): asks before edits and commands
• acceptEdits: auto-approves file edits
• plan: explores and plans without changing code
• auto: a separate classifier blocks only risky-looking actions (where available)

The docs recommend explore → plan → implement → commit. Boris Cherny iterates on the plan in plan mode until he likes it, then switches to auto-accept for the implementation.

When the plan appears, Ctrl+G opens it in your editor to edit directly, faster than describing changes.

/plan add account lockout after failed logins

Planning has overhead. Per the docs, if you can describe the diff in one sentence, skip the plan.

4. Checking and reviewing changes

/diff — see what changed

Shows working-tree changes, including Claude's edits. A quick look before committing.

/code-review (alias /review) — find bugs

Reviews the current diff, or a PR number, branch, or path, for correctness bugs, in a fresh subagent less biased by the conversation that wrote the code.

/code-review            # current changes/review 1234            # PR #1234/code-review high --fix # review deeper and apply the findings

The docs add a caution: a reviewer asked to find gaps will usually report some even when the work is sound. Chasing every finding leads to over-engineering, so act on what affects correctness or the requirements and treat the rest as optional.

/security-review, /simplify

• /security-review: checks the diff against origin's default branch for injection, auth issues, and data exposure. Needs an origin remote.
• /simplify: checks reuse, simplification, efficiency, and abstraction level, and applies fixes. It doesn't hunt bugs. Bugs → /code-review, cleanup → /simplify.

Writer / Reviewer sessions

A pattern from the docs: session A implements, a fresh session B reviews, and you paste B's feedback back into A. A fresh context isn't biased toward code it just wrote. A variant: one session writes tests, another writes code to pass them.

5. Input shortcuts

You can type while Claude works. Messages are queued instead of interrupting: they reach Claude as soon as the current tool calls finish, within the same turn, while slash commands and ! commands run after the turn ends. Ctrl+Enter sends queued messages immediately. "Queue up your next instruction" shows up often in user tips.

6. Permissions, hooks, settings

/permissions — reduce approval fatigue

The docs note that by the tenth approval you're clicking through rather than reviewing. Allowlist safe, frequent commands. Boris Cherny pre-allows common bash commands like build and test through /permissions.

Before writing rules by hand, /fewer-permission-prompts scans past sessions for frequently approved read-only commands and adds them to project settings.

On --dangerously-skip-permissions: several user write-ups recommend skipping all approvals, but Boris Cherny uses it only for long-running tasks in a sandbox. As the name says, it's risky; consider allowlists, /sandbox, or auto mode first.

Hooks — for things that must happen every time

CLAUDE.md instructions are advisory and can be skipped. Hooks run a script at a fixed point, every time. Boris Cherny's team runs a formatter after edits to avoid CI failures. You don't have to write the config yourself:

Write a hook that runs eslint after every file edit

Browse configured hooks with /hooks.

Other settings

7. Automation and your own commands

claude -p — ask once and exit

claude -p "explain what this function does"cat error.log | claude -p "list likely causes of this error"claude -p "list all API endpoints" --output-format json

Prints the result and exits. It takes piped input, so it fits shell scripts, pre-commit hooks, and CI.

Custom skills — turn repeated requests into commands

Boris Cherny says he uses his own /commit-push-pr command dozens of times a day. Turning repeated requests into commands pays off most.

A file at .claude/skills/<name>/SKILL.md becomes /<name>. Writing !`command` in the body runs the command when the skill is invoked and inserts its output into the prompt, so Claude doesn't need a separate step to gather it.

---description: Draft a commit message from staged changesdisable-model-invocation: true---Draft a commit message for the changes below.!`git diff --staged`Extra request: $ARGUMENTS

• /commit-draft in Korean passes the trailing text as $ARGUMENTS.
• disable-model-invocation: true means it runs only when you call it, recommended for workflows with side effects like commits or deploys.
• .claude/skills/ is committed and shared with your team; ~/.claude/skills/ is personal and works in every project.
• The older .claude/commands/<name>.md format still works.

For big features, start with an interview

From the docs: describe the feature briefly and have Claude interview you.

I want to build [brief description]. Interview me in detail using the AskUserQuestion tool.Ask about implementation, UI/UX, edge cases, and tradeoffs. Skip obvious questions.When we're done, write a complete spec to SPEC.md.

Then implement it in a new session: a clean context plus a written spec.

8. Going further: power-user and recent commands

Many of these are recent, so they may not appear depending on version, plan, or settings. /release-notes shows what changed.

Working in parallel

This is where heavy users differ most. Boris Cherny runs 5 Claudes in his terminal and 5–10 on the web, each in its own git checkout, splitting work rather than waiting on one session.

Splitting the conversation: /branch, /subtask, /fork

All three copy the conversation; they differ in where the copy runs and where its result goes.

Hand it off until done: /goal, /loop

/goal all tests in test/auth pass and lint is clean; no other test file is modified; or stop after 20 turns

Claude keeps taking turns until the condition holds. After each turn a separate small model judges the condition, rather than the working model declaring itself done. It enforces section 0's "give Claude a way to check" at the session level.

Good conditions have one measurable end state, a stated check (npm test exits 0), constraints, and a bound. The evaluator doesn't run commands; it judges only what appears in the conversation. /goal alone shows status; /goal clear stops it.

/loop repeats on a time interval instead:

/loop 5m check if the deploy finished

Large work in parallel: /batch, ultracode, /deep-research

• /batch <instruction>: splits the work into 5 to 30 independent units, shows a plan, and after approval runs one subagent per unit in its own worktree.

  text

  /batch migrate src/ from JavaScript to TypeScript

• The ultracode keyword: include it in a prompt and Claude writes and runs a workflow script that orchestrates many subagents. Watch it in /workflows and press s to save a good run as /<name>. /effort ultracode does this for every substantive task in the session; it uses a lot of tokens, so switch it off with /effort ultracode off.

  text

  ultracode: audit every API endpoint under src/routes/ for missing auth checks

• /deep-research <question>: searches the web from several angles, cross-checks sources, and returns a cited report.

Beyond "tests pass": /run, /verify

Boris Cherny has Claude open a browser and check the UI for every change. Built-in commands work in the same direction:

• /run: launches and drives your app to see a change working.
• /verify: builds and runs the app and observes the result instead of trusting tests alone.
• /run-skill-generator: writes a project skill that teaches /run and /verify how to build and launch your app.

Deeper review: /code-review ultra, /autofix-pr

• /code-review ultra (alias /ultrareview): a deep multi-agent review in a cloud sandbox. Pro and Max include 3 free runs, then usage credits.
• /code-review --comment: posts findings as PR comments.
• /autofix-pr: a cloud session watches the current branch's PR and pushes fixes when CI fails or reviewers comment. Needs the gh CLI.

Checking your own habits

Small things that add up

Before following other people's tips

• Don't install every trending feature. A recurring warning in user write-ups: understand why a feature exists and adopt it when it fits a task you repeat.
• Watch for outdated posts. Some older tips, like the # memory shortcut, no longer work the same way. Check commands against the docs.
• Loosen permissions only where it's safe. Skipping approvals belongs in isolated environments like sandboxes or containers.

Summary

• Principles: keep context clean, plan first, give Claude a way to check itself.
• Start: keep the /init-generated CLAUDE.md short and update it when Claude slips.
• Context: same task → /compact, new task → /clear. Two failed corrections → /clear and retry.
• Safety: stop with Esc, rewind with Esc Esc, refine plans in plan mode with Ctrl+G.
• Review: /diff to look, /code-review for bugs, /simplify for cleanup, reviews in a fresh context.
• Less repetition: approvals via /permissions, must-run steps via hooks, repeated requests via skills.
• Going further: worktrees with /subtask and /fork for parallel work, /goal to hand off, /verify to confirm real behavior.

Knowing many commands matters less than the three habits people keep naming: clean context, planning, and verification.

References

Official docs

• Best practices — Claude Code Docs
• Commands — Claude Code Docs
• Interactive mode — Claude Code Docs
• CLI reference — Claude Code Docs
• Skills — Claude Code Docs
• Goal — Claude Code Docs
• Dynamic workflows — Claude Code Docs

User experience and tips

• Claude Code creator's workflow — InfoQ (2026-01-10)
• How I use Claude Code (+ my best tips) — Builder.io
• ykdojo/claude-code-tips — GitHub
• 9 Claude Code tips from 800 hours of use — Lilys AI video summary (Korean)