25 Claude Code tips and tricks most developers miss

Claude Code has a lot of features that are not immediately obvious. The documentation covers the basics, but many of the most useful capabilities are discovered through experimentation or word of mouth. Here are 25 techniques that consistently make a difference in daily use.

Project setup

1. Write your CLAUDE.md before your first session

This is the single highest-impact thing you can do. A CLAUDE.md file at your project root tells Claude about your architecture, conventions, testing approach, and constraints. Without it, Claude starts every session with zero context about your project and makes generic assumptions.

Spend 20 minutes on this before you write your first prompt. The investment pays back within the first hour of use. If you want a fast start, ContextKit Generate can produce a solid baseline from a project description.

2. Use .claude/rules/ for team-wide conventions

Beyond the root CLAUDE.md, you can create individual rule files in .claude/rules/. Each file addresses a specific concern: testing standards, security constraints, deployment procedures. This modular approach makes rules easier to maintain and review than one massive file.

.claude/
  rules/
    testing.md        # Test conventions and commands
    security.md       # Security requirements
    api-conventions.md # API design rules
    git-workflow.md   # Commit and PR standards

3. Add a "do not" section to your CLAUDE.md

Tell Claude what to avoid. This prevents common mistakes that waste time. Examples: "Do not use default exports," "Do not add comments to code you did not change," "Do not create new utility files for one-time operations." Negative constraints are often more valuable than positive instructions because they prevent specific failure modes you have already encountered.

4. Include your test and build commands

Claude cannot run your tests if it does not know the command. Add the exact commands to your CLAUDE.md:

## Commands
- Test: `npm test`
- Lint: `npm run lint`
- Type check: `npx tsc --noEmit`
- Build: `npm run build`
- Dev server: `npm run dev` (port 3000)

Now Claude can verify its own work before reporting completion.

Daily workflow

5. Start sessions with a specific task, not a vague goal

"Improve the authentication system" gives Claude too much latitude and usually produces changes you did not want. "Add rate limiting to the /api/login endpoint — max 5 attempts per IP per minute, return 429 after that" gives Claude a clear target. Specific prompts produce specific, reviewable results.

6. Use /compact to manage long sessions

Long conversations eat context window space. When your session gets long and Claude starts forgetting earlier context, type /compact. This compresses the conversation history while preserving the key decisions and state. Your session continues with a fresh context budget.

7. Let Claude read before it writes

Before asking Claude to modify code, ask it to read and explain the relevant files first. "Read src/auth/middleware.ts and explain how the token validation works." This forces Claude to build an accurate mental model before making changes, which produces better edits and fewer bugs.

8. Ask Claude to run tests after changes

After Claude makes code changes, tell it to run your test suite. If tests fail, Claude can read the error output and fix the issues iteratively. This catches problems immediately instead of discovering them later. You can make this automatic by adding "After any code change, run the test suite and fix failures" to your CLAUDE.md.

9. Use git commits as checkpoints

After Claude completes a task successfully, ask it to commit the changes. This creates a rollback point before the next task. If the next change goes wrong, you can reset to the last good state without losing progress. Claude handles git operations natively — it can stage, commit, and even create branches.

Advanced features

10. Spawn subagents for independent tasks

Claude Code can launch subagents that work on independent tasks in parallel. If you need to update three unrelated modules, Claude can spawn a subagent for each one. They work simultaneously and return results. This is particularly useful for large refactors where changes in different areas of the codebase are independent.

11. Use hooks for automated quality gates

Hooks run shell commands before or after Claude's tool calls. Set up a pre-commit hook that runs your linter, a post-edit hook that runs type checking, or a notification hook that pings you when a long task finishes. Configure them in .claude/settings.json.

// .claude/settings.json
{
  "hooks": {
    "PreCommit": ["npm run lint -- --fix"],
    "Stop": ["terminal-notifier -message 'Claude Code finished'"]
  }
}

12. Use /init to bootstrap your CLAUDE.md

If you do not have a CLAUDE.md yet, run /init in your project directory. Claude will analyze your codebase and generate a starter configuration file. It is not perfect — you should review and customize it — but it is a much faster starting point than writing from scratch.

13. Reference specific files in your prompts

Instead of "fix the auth bug," say "fix the token expiry check in src/auth/jwt.ts around line 45." The more specific your reference, the less time Claude spends searching and the more accurate the fix. File paths and line numbers dramatically reduce ambiguity.

14. Use Claude for code review

Ask Claude to review code before you commit it. "Review the changes in this session for bugs, security issues, and style violations." Claude reads the diff and provides feedback. This is especially valuable for solo developers who do not have a team reviewer.

Cost optimization

15. Break large tasks into focused sessions

A single massive session that rewrites an entire module costs far more in tokens than three focused sessions that each handle a specific aspect. Each new session starts with a fresh context, which means Claude is not paying to carry irrelevant conversation history from earlier tasks.

16. A good CLAUDE.md reduces token waste

Every time Claude asks a clarifying question, you both spend tokens on the question and the answer. Every time Claude makes a change that does not match your conventions, you spend tokens explaining the correction and Claude spends tokens redoing the work. A thorough CLAUDE.md eliminates most of these retry loops.

Check how well your configuration covers the key areas with ContextKit Analyze. Projects that score below 5/10 typically have 30-40% more token waste than well-configured ones.

17. Use model routing for simple tasks

Not every task needs Opus. Simple file reads, boilerplate generation, and routine edits can use Sonnet or Haiku at a fraction of the cost. If you are on API billing, consider routing simpler tasks to cheaper models. The quality difference for routine work is minimal.

18. Avoid rebuilding context unnecessarily

If you are working on the same area of code across multiple prompts, stay in the same session. Each new session requires Claude to re-read files and rebuild context from scratch. Staying in the same session avoids redundant file reads, which saves tokens compared to starting fresh.

Debugging

19. Give Claude the error output, not your interpretation

Instead of "the API returns an error," paste the actual error message, stack trace, or log output. Claude is better at diagnosing issues from raw error data than from summarized descriptions. The details you think are irrelevant often contain the actual clue.

20. Ask Claude to trace the execution path

For complex bugs, ask Claude to trace the flow: "Read the code path from when a POST request hits /api/orders to where the database insert happens. Identify where the validation might be failing." This systematic approach catches issues that ad-hoc debugging misses.

21. Use Claude to write reproduction cases

When you find a bug, ask Claude to write a test that reproduces it before fixing it. This gives you confidence that the fix actually addresses the problem and prevents regression. "Write a test that demonstrates the bug where duplicate orders are created when two requests arrive within 100ms, then fix the underlying issue."

Team workflows

22. Commit your CLAUDE.md to the repo

Your CLAUDE.md should be in version control. When team members clone the repo, they get the same AI configuration. When conventions change, the CLAUDE.md changes in the same commit. This ensures consistency across the team without requiring manual synchronization.

23. Use Claude for PR descriptions

After completing a feature, ask Claude to draft a PR description based on the changes made in the session. Claude has full context on what changed and why, so the descriptions are detailed and accurate. Less time writing PR descriptions, better documentation of what the change does.

24. Create team-specific rules files

Different team members may have different roles. A frontend developer and a backend developer working in the same monorepo need different conventions emphasized. Use .claude/rules/ files for shared rules and personal CLAUDE.md overrides for role-specific preferences.

25. Review Claude's changes like you review a junior developer's PR

Claude produces correct code most of the time, but it occasionally makes subtle mistakes: incorrect assumptions about business logic, inefficient approaches that technically work, or changes that are correct in isolation but conflict with broader project goals. Review every change before committing. The mental model of "I am reviewing a junior developer's work" sets the right expectations: usually good, occasionally needs correction, always worth checking.

Getting started

You do not need to adopt all 25 tips at once. Start with the highest-impact ones:

1. Write a CLAUDE.md (generate one here)
2. Include your test commands so Claude can verify its own work
3. Be specific in prompts with file paths and line numbers
4. Ask Claude to run tests after every change
5. Use /compact when sessions get long

These five habits cover 80% of the productivity gain. Add the rest as your workflow matures and you discover which advanced features match your specific needs.

To see where your current setup stands, run your CLAUDE.md through ContextKit Analyze. It takes 30 seconds and gives you a concrete score with specific improvements. Most developers find at least two or three gaps that are easy to fix and immediately improve their Claude Code experience.