50 Claude Code tips

Launch Claude Code from the project root

Claude Code uses the current directory as its starting point. Launching from the root gives it the full picture: the file structure, package.json, configs.

# Correct
cd ~/projects/my-app && claude

# Wrong — Claude only sees part of the project
cd ~/projects/my-app/src/components && claude

Run /init first thing

The command analyses the project and creates CLAUDE.md — an instructions file with build commands, tests and key directories. Run it the first time you use Claude Code in a new project.

CLAUDE.md is a hierarchical system

It works on three levels:

Keep CLAUDE.md short — up to 300 lines

Every line costs tokens on every request. A bloated file raises costs, blurs the instructions and slows down responses.

Rule: if an instruction doesn't affect the quality of the result, delete it.

Structure: What + Domain + Validation

Three sections of an effective CLAUDE.md:

• What — what the project does, the stack, the architecture
• Domain — business logic, terms, patterns
• Validation — build, test and lint commands for self-checking

The Validation section is the most important. It gives Claude a self-correction loop.

Keyboard shortcuts

Screenshots as context

Claude Code accepts images: drag a screenshot into the terminal (drag-and-drop) or give the path to the file. Add text explanations to make the diagnosis more accurate.

/clear is your main command

Switching to a new task? Reset the context. A fresh context always works better than a bloated one.

Rule: one task — one context. Switched — cleared.

/context — a token audit

Shows how the context window is split: system prompt, MCP servers, CLAUDE.md, history. If an MCP server eats 30% of the window, reconsider whether you need it.

Key commands

Auto-compaction works automatically — trust the built-in context optimisation mechanism.

Git is your insurance

Commit before serious changes. If Claude goes the wrong way, a single git checkout . brings everything back. Small, frequent commits are the best practice.

A Critical Rules section

At the top of CLAUDE.md — absolute rules with the words NEVER and ALWAYS:

## Critical Rules
- NEVER modify files in /config/production/
- ALWAYS run tests before committing
- NEVER use `any` type in TypeScript
- ALWAYS include error handling in API routes

Ask Claude to update CLAUDE.md

Instead of editing by hand, give Claude the task. This is compound engineering: every session improves future sessions.

Workflow triggers

Map commands to scripts in CLAUDE.md:

## Workflows
- "build the project" → npm run build
- "run the tests" → npm test -- --coverage
- "deploy" → ./scripts/deploy.sh --staging

Git + security

Commit CLAUDE.md — it's part of the project, not a personal setting. Versioning, teamwork, accumulated knowledge.

--dangerously-skip-permissions — only for disposable containers and CI/CD. Never on your working machine.

Plan Mode First — always

The most important workflow tip:

1. Switch to Plan Mode (Shift+Tab twice)
2. Describe the task and discuss the approach
3. Iterate on the plan until it's clear
4. Switch to Normal Mode and implement

When the context is clear, the implementation often works the first time.

Fresh context > bloated context

A second brain and lazy loading

Before ending a session, ask Claude to write all the important decisions into CLAUDE.md. That way knowledge isn't lost.

Lazy loading: don't load all the files up front. Point to the entry point, and Claude will work out for itself what needs reading.

Verification commands — a self-correction loop

The most important tip, in the author's opinion. Add to CLAUDE.md:

## Verification
- Build: npm run build
- Test: npm test
- Lint: npm run lint
- Type check: npx tsc --noEmit

After ANY code change, run build + test to verify.

Claude will automatically check and fix its own code.

Opus for complex tasks + thinking blocks

Use /model opus for complex refactoring and architectural decisions. Read the thinking blocks — phrases like "I'm not sure..." signal that Claude is uncertain.

Four composable primitives

All of Claude Code's extensibility is built on four blocks:

Skills, Commands and MCPs

Skills — Markdown files in .claude/skills/ with instructions for frequent operations.

Commands are now merged with Skills. Don't create them by hand — ask Claude.

MCPs connect Claude to GitHub, databases, monitoring. Ask Claude to install the MCP you need.

Subagents and the quality of instructions

Subagents — independent agents with their own context window, for parallel tasks.

Don't overload it with instructions: 5 key rules are better than 50 small ones. Claude already knows best practices.

Parallel work

Several Claude Code instances at once is the most powerful technique:

• iTerm: Cmd+D — split, Cmd+[/] — navigation
• Git worktrees: a separate working tree for each instance
• Notifications: sound alerts when tasks finish

# Create separate working trees
git worktree add ../app-feature-a feature-a
git worktree add ../app-feature-b feature-b

/chrome — working with the browser

Claude Code can drive a browser: navigation, clicks, filling in forms, DOM inspection, screenshots. Uses: UI testing, scraping, automation.

Hooks — intercepting actions

Scripts that run before (PreToolUse) or after (PostToolUse) Claude's actions:

• Auto-format: Prettier after every file
• Blocking: forbid rm -rf, DROP TABLE, force-push
• Logging: recording actions for an audit

The plugin ecosystem

A growing ecosystem: thousands of MCP servers on GitHub, curated lists, community skills. Use composable primitives through extensions.

Context is King

The main principle. Five layers of context:

1. CLAUDE.md — static (rules, instructions)
2. Prompt — dynamic (the current task)
3. Files — code (the state of the project)
4. MCP — external (APIs, data)
5. History — historical (previous decisions)

Claude needs exactly what it needs. And nothing extra.