Claude Code Tips: 12 Tricks That Save Hours

1. Start Every Project with /init

The /init command scans your repo structure, build tools, test framework, and dependencies, then generates a CLAUDE.md file. This file becomes Claude's persistent memory for every session. Without it, Claude rediscovers your project structure every time you open a new session. With it, Claude knows your stack, conventions, and preferences from the first message.

The key insight: CLAUDE.md is not documentation for humans. It is a system prompt for Claude. Write it accordingly.

# Project: payments-service

## Commands
- bun run dev        # Start dev server on port 3002
- bun run test       # Run vitest
- bun run typecheck  # tsgo --noEmit
- bun run db:push    # Push Drizzle schema changes

## Architecture
- Next.js 15 App Router, React 19, TypeScript strict
- Database: PostgreSQL with Drizzle ORM
- Auth: Clerk middleware on /dashboard/*
- Payments: Stripe webhooks in /api/webhooks/stripe

## Rules
- Server components by default. Client components only for interactivity.
- All mutations through server actions, never API routes.
- Never import from @/lib/db in client components.
- Run typecheck after every code change.

2. Use /compact Before Context Gets Stale

Claude Code's context window is large (up to 1M tokens with Opus 4.6), but bigger context is not always better. After roughly 80K tokens, responses start degrading. Claude loses track of earlier decisions, repeats itself, or contradicts its own plan from 50 messages ago.

The /compact command compresses the conversation while preserving key decisions and context. Run it proactively around the 80K mark, not reactively when Claude starts hallucinating.

// .claude/settings.json
{
  "hooks": {
    "SessionStart": [
      {
        "matcher": "compact",
        "hooks": [
          {
            "type": "command",
            "command": "echo 'CONTEXT: Use Bun not npm. Current task: auth refactor. Test with bun run test before committing.'"
          }
        ]
      }
    ]
  }
}

The difference between a developer who compacts proactively and one who lets context rot is roughly 20% fewer failed attempts on complex tasks. Check your token usage with /cost (see tip 12) to know when you are approaching the threshold.

3. Write Custom Slash Commands for Repeated Tasks

If you type the same prompt more than twice, make it a slash command. Create a .claude/commands/ directory in your project root. Each markdown file becomes a command.

Review the current diff for:
1. Type errors (run bun run typecheck)
2. Missing test coverage for changed functions
3. Any TODO comments that should be resolved
4. Import ordering violations

Report findings as a checklist. Do not fix anything — just report.

$ARGUMENTS

That file becomes /project:pr-check. Run it with optional arguments: /project:pr-check focus on the auth changes.

For commands shared across all projects, put them in ~/.claude/commands/ instead. These become globally available as /user:command-name.

4. Set Up Hooks for Auto-Formatting After Edits

Hooks are shell commands that fire at specific lifecycle events. The most impactful hook for daily productivity is auto-formatting: a PostToolUse hook on Edit and Write that runs your formatter on every file Claude touches.

// .claude/settings.json
{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "jq -r '.tool_input.file_path' | xargs npx prettier --write 2>/dev/null"
          }
        ]
      }
    ]
  }
}

This eliminates an entire category of code review feedback. Claude writes code in its own style. Your formatter normalizes it. The diff you review is always in your project's style. No more "can you run prettier on that?" messages.

The second most valuable hook is a Stop hook with typecheck. It prevents Claude from declaring a task "done" if the code has type errors. See our full hooks guide for setup details and the stop_hook_active guard that prevents infinite loops.

5. Use Plan Mode for Complex Multi-File Changes

Before Claude starts writing code on a complex task, ask it to plan first. Claude will outline every file it needs to touch, what changes go where, and the order of operations.

Without a plan, Claude often starts writing code, realizes it needs to change a dependency, backtracks, and produces a messy diff. With a plan, the changes are coherent from the start.

Plan this change before implementing:

Refactor the auth module to use Clerk middleware
instead of custom JWT validation.

List every file you'll touch, what changes in each,
and the order of operations. Don't write code yet.

Review the plan for files Claude missed, incorrect assumptions about your architecture, and unnecessary changes. Correcting the plan takes 30 seconds. Correcting code that followed a wrong plan takes 10 minutes.

6. MCP Servers That Actually Help

MCP (Model Context Protocol) servers extend Claude Code with external tool access. Most MCP servers are novelties. Three are genuinely useful in daily development.

// .claude/settings.json
{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_..."
      }
    }
  }
}

The GitHub MCP is the highest-value addition. For teams that do code review in Claude Code, it replaces the workflow of "copy issue description into prompt, paste PR link, copy CI output" with Claude reading everything directly from GitHub.

7. Model Routing: When to Use Opus vs Sonnet vs Haiku

Opus 4.6 is the most capable model but also the slowest and most expensive per token. Sonnet 4.6 is 3-4x faster for straightforward tasks. Haiku is fastest for simple completions. Using the right model for the right task saves both time and money.

8. The Git Checkpoint Trick

Before telling Claude to "refactor the entire auth module" or any task that will take 10+ minutes of autonomous work, commit your current state.

git add -A && git commit -m "checkpoint before auth refactor"

This is not about distrust. It is about risk management. Claude will sometimes take a wrong turn 8 minutes into a 12-minute task. Without a checkpoint, you are manually reverting scattered changes across multiple files. With one, you can git diff HEAD to see exactly what changed and git checkout . to reset if needed.

The advanced version: add a CLAUDE.md instruction telling Claude to commit a checkpoint before any long autonomous run. Claude will do this automatically, and you never have to remember.

## Workflow
- Before any task that will touch 5+ files, commit a checkpoint:
  git add -A && git commit -m "checkpoint: [brief description]"
- Always push to a branch, never directly to main
- Run bun run typecheck after every series of code changes

9. Run Headless for CI/CD Integration

Claude Code supports a -p flag for non-interactive (headless) mode. Pass a prompt as a string and Claude executes it without a terminal UI. Output goes to stdout.

# Generate release notes from recent commits
claude -p "Generate release notes for the commits since the last tag" \
  --allowedTools Bash,Read \
  --output-format json

# Validate a PR in CI
claude -p "Review the diff on this branch for type safety issues" \
  --allowedTools Bash,Read,Grep \
  --output-format json > review-results.json

This unlocks CI/CD integration. Generate release notes, update changelogs, migrate configuration files, or validate PRs automatically. Pipe the output to a file or directly to gh pr comment.

10. Use Subagents for Parallel Investigation

When you need to investigate multiple areas simultaneously, tell Claude to use subagents. Claude spawns parallel workers that each investigate independently and report back.

Use subagents to investigate these three areas in parallel:

1. Check the auth middleware for any requests that
   bypass token validation
2. Check the billing module for race conditions in
   the subscription upgrade flow
3. Check the API routes for any endpoints missing
   rate limiting

Report findings from all three.

Instead of checking three services sequentially (3x the wall-clock time), subagents run concurrently. The total time is roughly the time of the slowest investigation, not the sum of all three.

11. CLAUDE.md Anti-Patterns (What NOT to Put in It)

A bloated CLAUDE.md is worse than no CLAUDE.md. Every token in that file competes with your actual conversation for context space. These are the patterns we have seen waste the most context:

The ideal CLAUDE.md is under 200 lines. It covers: build and test commands, deployment workflow, 3-5 hard architectural rules, known gotchas specific to your project, and nothing else. If your CLAUDE.md is over 500 lines, you are almost certainly duplicating information Claude can read from your config files directly.

12. Cost Tracking with /cost

The /cost command shows your token usage for the current session. This is more useful than it sounds.

Track /cost across sessions and you will notice patterns. A debugging session burning 200K+ tokens without progress is a signal to stop, re-read the error message yourself, and give Claude a more targeted prompt rather than letting it continue exploring.

Frequently Asked Questions

What is the most important Claude Code tip for beginners?

Run /init to generate a CLAUDE.md file. This single action improves every subsequent session because Claude starts with knowledge of your project's stack, build commands, and conventions instead of discovering them from scratch.

When should I use /compact in Claude Code?

Proactively around the 80K token mark. Check your token count with /cost. Do not wait until Claude starts contradicting itself or forgetting earlier decisions. Proactive compaction preserves context quality. Reactive compaction is damage control.

How do I create custom slash commands in Claude Code?

Create a .claude/commands/ directory in your project root. Each markdown file becomes a command. A file named deploy-check.md becomes /project:deploy-check. Use $ARGUMENTS in the file for dynamic input. For global commands, use ~/.claude/commands/.

Should I use Claude Opus or Sonnet for coding?

Opus 4.6 for multi-file refactors and complex debugging. Sonnet 4.6 for single-file edits, tests, and docs. Sonnet is 3-4x faster and sufficient for tasks you can quickly verify. The cost difference between Pro ($20/month, Sonnet) and Max ($100/month, Opus) pays for itself if you hit 2-3 complex tasks per week that Sonnet struggles with.

Can Claude Code run in CI/CD pipelines?

Yes. The -p flag enables headless mode. Combine with --allowedTools for safety and --output-format json for structured output. Common CI/CD uses: release notes, changelog updates, configuration migration, and automated PR review comments.