How to Use Claude Code: 50 Field-Tested Tips From Someone Who Uses It Daily

How to Use Claude Code: 50 Field-Tested Tips From Someone Who Uses It Every Day

Claude Code is an AI coding agent you run straight from the terminal. It reads code, edits files, runs tests, and even commits. It's a different animal from copy-pasting snippets into a chat window.

The catch is that it does so much. Used well, it multiplies your productivity — but most people stick to the basics, come away thinking "how is this any different from a chatbot?", and stop there.

Developer Vishwas pulled together 50 tips, synthesizing Anthropic's official documentation, advice from Boris Cherny (who built Claude Code), the community's collective experience, and his own year of daily use. Here are the ones you can put to work right away, sorted by category.

1. Initial Setup: Do It Once, Reap It Daily

Add a cc alias

Typing `claude --dangerously-skip-permissions` every time is painful. Add an alias to your shell config (~/.zshrc or ~/.bashrc) and you can start with just `cc`.

alias cc='claude --dangerously-skip-permissions'

The flag name is scary on purpose. The message: only use it once you fully understand what Claude Code can do to your codebase.

Set up CLAUDE.md early

Run `/init` and Claude drafts a CLAUDE.md based on your project structure — build commands, test scripts, and directory layout, all detected automatically. The output tends to be long and wordy, though. Cut it in half. If you can't explain why a line needs to be there, delete it.

Ask this of every line in CLAUDE.md: "Without this instruction, would Claude get it wrong?" Instructions for things Claude already handles well on its own are just noise. The more unnecessary lines there are, the more they dilute the instructions that actually matter. Compliance starts to slip somewhere past 150–200 instructions.

Install per-language code-intelligence plugins

LSP plugins run diagnostics automatically every time Claude edits a file. Type errors, unused imports, missing return types — Claude sees them itself and fixes them. Tip for tip, it's the single highest-impact plugin.

/plugin install typescript-lsp@claude-plugins-official /plugin install pyright-lsp@claude-plugins-official /plugin install rust-analyzer-lsp@claude-plugins-official /plugin install gopls-lsp@claude-plugins-official

There are also plugins for C#, Java, Kotlin, Swift, PHP, Lua, and C/C++. Open the Discover tab in `/plugin` to see the full list.

Set your output style

Pick your preferred style in `/config`. There are three defaults: Explanatory (detailed, step-by-step), Concise (brief, action-focused), and Technical (precise, jargon-forward). You can also add a custom style by dropping a file into `~/.claude/output-styles/`.

2. Session Management: Keeping Your Context Clean

Run /clear between unrelated tasks

One sharp prompt in a clean session beats a three-hour session with everything jumbled together. The rule: when the task changes, `/clear` first.

It feels like you're throwing away progress, but starting fresh produces better results. As a session drags on, the context piled up at the front gets in the way of your current instructions. It takes five seconds to `/clear` and write a focused opening prompt. Those five seconds save you 30 minutes of degraded output.

If two attempts at the same fix both fail, start over

If you've fallen down the fix → fail → re-fix → fail-again rabbit hole with Claude, your context is now full of failed approaches that are sabotaging the next attempt. `/clear`, then write a better opening prompt that bakes in what you learned from the failures.

Esc to stop, Esc+Esc to rewind

Press Esc to stop Claude instantly without losing context — you can redirect on the spot. Press Esc+Esc (or `/rewind`) and you get a list of every checkpoint Claude has created. You can restore the code, the conversation, or both.

That means you can try an approach you're only 40% sure about. Great if it works; rewind if it doesn't. One caveat: checkpoints only track file edits. Changes made via bash commands (migrations, DB operations) aren't included.

Resume a session

`claude --continue` picks up your most recent conversation. `claude --resume` lets you choose which session to continue from a list.

Name and color your sessions

Use `/rename auth-refactor` to name a session. Use `/color red` or `/color blue` to set the prompt-bar color. When you're running two or three sessions in parallel, spending five seconds on names and colors stops you from typing into the wrong terminal.

Manage compaction (context compression)

You can tell Claude what to preserve when context gets compressed. Write something like `/compact focus on the API changes and the list of modified files`. You can also keep a standing instruction in CLAUDE.md: "When compacting, preserve the full list of modified files and the current test status."

Expand the context window to 1 million tokens

Both Sonnet 4.6 and Opus 4.6 support a 1-million-token context window. You can switch mid-session with `/model opus[1m]` or `/model sonnet[1m]`.

3. Prompting Techniques: Getting Claude to Do Good Work

Don't interpret the bug — paste the raw data

Describing a bug in words is slow. It kicks off a loop of Claude guessing, getting it wrong, and revising. Paste the error log, the CI output, the Slack thread exactly as-is and just say "fix it." Adding your own interpretation tends to strip out the very details Claude needs to pinpoint the cause.

You can also pipe straight from the terminal.

cat error.log | claude "Explain this error and suggest a fix" npm test 2>&1 | claude "Fix the failing tests"

Tell Claude exactly which files to look at

Reference files directly with @, like `@src/auth/middleware.ts`. Claude can search on its own, but narrowing the candidates and hunting down the right file burns tokens and context at every step. Point at it from the start and that cost disappears.

Trigger deeper reasoning with the "ultrathink" keyword

For complex architecture decisions, tricky debugging, and multi-step reasoning, put "ultrathink" in your prompt. Adaptive reasoning kicks in on Opus 4.6, scaling thinking depth to the complexity of the problem. There's no need for it on simple tasks like renaming a variable. You can also set a permanent default effort level with `/effort`.

Give Claude a way to verify its own work

Put the test command, the linter check, and the expected output right in your prompt.

Refactor the auth middleware to use JWT. After the change, run the existing test suite. If any tests fail, fix them before you finish.

Claude runs the tests, sees the failures, and fixes them itself. Boris Cherny, who built Claude Code, says this alone raises quality two to three times. For UI changes, set up the Playwright MCP server and Claude will open a browser, interact with the page, and verify the UI for itself.

Explore code with a vague prompt

"What would you improve in this file?" is a good exploration prompt. Not every prompt has to be specific. When existing code needs fresh eyes, a vague question is exactly what surfaces things you'd never have thought to ask about.

When you can't fully spec a feature, have Claude interview you

Sometimes you know what you want to build, but you're short on the details Claude needs to build it well.

I want to build [brief description]. Interview me in depth about the technical implementation, edge cases, concerns, and trade-offs. Don't ask obvious questions. Keep asking until you've covered everything, then write a complete spec to SPEC.md.

Once the spec is done, open a new session and run it with clean context and the complete spec.

4. Shortcuts and Quick Moves

Voice input (`/voice`) is especially handy. Speaking out loud, you naturally pack in more background, constraints, and desired outcomes than you would by typing.

5. Parallel Work and Putting Agents to Use

Isolated parallel branches with worktrees

Run `claude --worktree feature-auth` and you get a new branch and an isolated working copy. The Claude Code team calls this their biggest productivity leap. You can spin up three to five worktrees and run an independent Claude session in each, in parallel.

The limit is your local machine's resources. Multiple dev servers, builds, and Claude sessions all compete for CPU.

Protect your main context with subagents

Say "use a subagent to figure out how the payment flow handles failed transactions" and a separate Claude instance spins up. It reads and analyzes the files, then reports back only a concise summary to the main session.

Deep investigation can eat up half your context window. With a subagent, that cost is paid outside the main session. The built-in types are Explore (Haiku, fast file search) and Plan (read-only analysis).

Custom subagents

You can store preconfigured agents in `.claude/agents/` — a security reviewer (Opus, read-only tools), a fast-search agent (Haiku), and so on. Manage them with `/agents`.

Agent teams (experimental)

After enabling `CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS`, tell Claude "create a team of three agents and refactor these modules in parallel." A team lead distributes the work, and each member gets its own context window and a shared task list.

Start with three to five members and five or six tasks per member. Avoid tasks that edit the same file. If two members touch the same file, you get overwrites.

Use claude -p for batch jobs

Non-interactive mode lets you loop over a list of files.

bash for file in $(cat files-to-migrate.txt); do claude -p "Migrate $file from a class component to hooks" \ --allowedTools "Edit,Bash(git commit *)" & done wait

It's a good fit for file-format conversion, codebase-wide import updates, and any repetitive migration that's independent file by file.

6. Config Files and Managing Rules

CLAUDE.md is advice; hooks are enforcement

CLAUDE.md is advisory — Claude follows it about 80% of the time. Hooks run 100% of the time. For anything that must happen, no exceptions (formatting, linting, security checks), make it a hook. Keep guidelines Claude should consult in CLAUDE.md.

Feed lessons from mistakes back into CLAUDE.md

When Claude makes a mistake, say "update CLAUDE.md so this mistake doesn't happen again." Claude writes the rule itself, and it's followed automatically in the next session. Over time, CLAUDE.md becomes a living document shaped by real mistakes.

Put conditional rules in .claude/rules/

Drop markdown files into `.claude/rules/` to split instructions by topic. To load a file only when working on certain files, specify the paths in the frontmatter.

yaml --- paths: - "**/*.ts" --- # TypeScript rules Prefer interface over type

TypeScript rules load only when you touch a .ts file; Go rules load only when you touch a .go file.

Keep CLAUDE.md lean with @imports

Reference external docs like `@docs/git-instructions.md`. You can link to README.md, package.json, or separate instruction files, and Claude reads them when it needs them. It's a way to provide extra context without bloating the CLAUDE.md that gets read every session.

Provide on-demand knowledge with Skills

Skills are markdown files that extend Claude's knowledge. Unlike CLAUDE.md, which loads every session, a skill loads only when it's relevant to the current task. Create them in `.claude/skills/`, or install prebuilt skills that ship bundled with plugins. They're ideal for specialized knowledge you need only occasionally — API conventions, deployment procedures, coding patterns.

7. Putting Hooks to Work: Automation and Guardrails

Auto-format on file edits (PostToolUse)

Have a formatter run automatically every time Claude edits a file.

json { "hooks": { "PostToolUse": [ { "matcher": "Edit|Write", "hooks": [ { "type": "command", "command": "npx prettier --write \"$CLAUDE_FILE_PATH\" 2>/dev/null || true" } ] } ] } }

If you have the same file open in your editor, it's best to turn off format-on-save. There are reports that an editor save invalidates the prompt cache and forces Claude to re-read the file.

Block dangerous commands (PreToolUse)

Block destructive commands like `rm -rf`, `drop table`, and `truncate` before they run.

json { "hooks": { "PreToolUse": [ { "matcher": "Bash", "type": "command", "command": "if echo \"$TOOL_INPUT\" | grep -qE 'rm -rf|drop table|truncate'; then echo 'BLOCKED' >&2; exit 2; fi" } ] } }

Auto-reinject context on compaction (Notification)

In a long session, when context gets compressed Claude can lose track of the current task. Just tell Claude: "set up a Notification hook that re-tells me the current task, the modified files, and the constraints after compaction."

A sound when work is done (Stop)

json { "hooks": { "Stop": [ { "matcher": "*", "hooks": [ { "type": "command", "command": "/usr/bin/afplay /System/Library/Sounds/Glass.aiff" } ] } ] } }

Kick off a task, go do something else, and head back when you hear the done sound.

8. Connecting External Tools

Handle GitHub work with the gh CLI

The gh CLI handles PRs, issues, and comments with no separate MCP server. CLI tools are more context-efficient than MCP servers because they don't load a tool schema into the context window. The same goes for standard CLI tools like jq and curl.

You can even teach Claude tools it doesn't know. Say "read sentry-cli --help to figure out how to use it, then find the most recent error in production" and Claude reads the help output, works out the syntax, and runs the command.

A guide to choosing MCP servers

Four MCP servers are worth starting with: Playwright (browser testing, UI verification), PostgreSQL/MySQL (query the schema directly), Slack (read bug reports and thread context), and Figma (design-to-code workflow). Claude Code supports dynamic tool loading, so it loads a server's definitions only when you actually need it.

Manage permissions

Use `/permissions` to add commands you trust to an allowlist. No more approving `npm run lint` every single time. Anything not on the list still needs approval.

Run `/sandbox` and OS-level isolation turns on. Writes are restricted to the project directory, and network requests are allowed only to domains you've approved.

9. Code Review and Collaboration Patterns

One writes, another reviews

The first Claude implements the feature; a second Claude reviews it from fresh context, like a senior engineer. The reviewer doesn't know the compromises made during implementation, so it challenges everything. You can apply the same pattern to TDD: session A writes the tests, session B writes the code that passes them.

Review PRs conversationally

Instead of asking for a batch review, open the PR in a session and have a conversation. "Explain the riskiest change in this PR." "What breaks if this runs concurrently?" "Is the error handling consistent with the rest of the codebase?"

Conversational review catches more problems. Batch reviews tend to dwell on style nits and miss architectural issues.

Use /loop for recurring checks

`/loop 5m check whether the deploy succeeded and report back` runs every five minutes. Use it for deploy monitoring, watching CI pipelines, and polling external services. The task is session-scoped and expires after three days, so a forgotten loop won't run forever.

10. Remote Control and Mobile Access

Run `claude remote-control` and a session starts. Connect from claude.ai/code or the Claude app on iOS/Android. The session runs on your local machine; your phone or browser is just a window into it. You can send messages, approve tool calls, and monitor progress.

If you're using the cc alias (auto-approve permissions), it proceeds without approval remotely too. You can kick off a task, walk away, and check in occasionally from your phone.

11. What a Human Must Always Review

Even when Claude writes good code, these always need a human review.

Auth flows, payment logic, data mutations, destructive DB operations. A wrong auth scope, a misconfigured payment webhook, a migration that silently drops a column — these lose you users, money, and trust. No amount of automated testing catches all of them.

12. Small Things That Help

Add a status line

The status line is a shell script that runs after every one of Claude's turns. It shows your current directory, git branch, and context usage at the bottom of the terminal. Run `/statusline` and it asks what you want to show, then generates the script.

Customize the spinner verbs

While Claude is thinking, you see verbs like "Flibbertigibbeting...". You can change these. Say "change the spinner verbs to Harry Potter spells" and Claude generates a list. Small, but it makes the wait more fun.