15 Claude Code Tips for Faster Development

Claude Code is one of the most capable AI coding tools available, but most developers use only a fraction of what it can do. After watching hundreds of developers work with it, we've distilled the patterns that separate fast Claude Code users from slow ones.

Here are 15 tips. Some are quick wins you can apply today; others require a bit of setup but pay off for weeks.

1. Structure your CLAUDE.md as a layered document

The CLAUDE.md file is your primary tool for controlling Claude Code's behavior. Most developers treat it as a flat list of instructions. The better approach is to layer it:

# Project name

## Tech stack
(what Claude needs to know before writing any code)

## Architecture
(key decisions, patterns in use, what to avoid)

## Current task
(optional: what you're actively working on)

## Rules
(hard rules Claude must follow)

Start with context that orients Claude to your project, then layer in constraints. Claude loads the whole file into context at the start of every session, so the ordering affects how it weighs information.

Think of the first section as a README for the AI: what is this project, what does it do, who uses it. The architecture section explains why certain decisions were made, which helps Claude avoid suggesting alternatives that were already considered and rejected. The rules section is where hard constraints live.

See our complete guide to structuring CLAUDE.md files for a full breakdown of every section.

2. Put CLAUDE.md files at every level of a monorepo

A single root-level CLAUDE.md isn't enough for monorepos. Claude Code loads all CLAUDE.md files from your working directory upward at launch, and lazily loads CLAUDE.md files from child directories as it accesses files in those subdirectories. Use this layered approach:

project-root/
  CLAUDE.md                  # Monorepo-wide conventions
  apps/
    web/
      CLAUDE.md              # Next.js-specific rules
    api/
      CLAUDE.md              # API-specific rules
  packages/
    shared/
      CLAUDE.md              # Shared package conventions

The web CLAUDE.md can say "use App Router, Tailwind v4, no CSS modules" without those rules polluting the API context. This is especially important when the apps use different languages or frameworks.

Each package-level file should focus only on what's specific to that package. Avoid duplicating root-level rules down into child files -- Claude reads both, and when instructions conflict, more specific instructions typically take precedence, but contradictions can still cause inconsistent behavior.

3. Use slash commands for repetitive workflows

Claude Code's slash commands let you define reusable workflows. Create a .claude/commands/ directory in your project:

mkdir -p .claude/commands

Then add command files. For example, .claude/commands/review.md:

Review the changes in the current git diff. Check for:
- Security vulnerabilities
- Missing error handling
- TypeScript type safety issues
- Performance concerns
Report findings grouped by severity.

Now /review runs your custom review workflow. Build a library of these for PR prep, migration checks, test generation -- anything you do more than twice.

Good candidates for slash commands: pre-commit checklists, changelog generation, database migration review, documentation updates. Any time you find yourself typing the same multi-sentence prompt repeatedly, turn it into a command.

4. Use skills for conventions that span multiple projects

CLAUDE.md is project-local. When you have coding conventions that apply across every project -- error handling patterns, commit message formats, code review checklists -- repeating them in every repo creates maintenance work.

localskills.sh solves this. Publish your conventions once as a skill, then install them into any project:

localskills install your-team/conventions --target claude

The skill gets symlinked into .claude/skills/, where Claude Code picks it up automatically. When you update the skill, run localskills pull in each project to propagate changes. No more copying and pasting CLAUDE.md content across repos.

5. Give Claude explicit "do not" rules

Claude Code will try to help -- sometimes too aggressively. If there are patterns you explicitly don't want, say so:

## Do NOT
- Do not use `any` type in TypeScript -- use `unknown` or proper types
- Do not add new npm dependencies without asking first
- Do not refactor code that is outside the scope of the current task
- Do not write comments that just describe what the code does
- Do not use `console.log` -- use the logger utility at `src/lib/logger`

The "do not refactor unrelated code" rule is particularly valuable. Without it, Claude will often clean up nearby code while making a targeted change -- creating larger diffs and unintended behavior changes.

The explicit negatives also help Claude understand what tradeoffs your team has already made. If you say "do not use Redux," Claude stops suggesting it as a solution to state management problems.

6. Anchor Claude to specific files and patterns

Instead of describing patterns in prose, show Claude where to find them:

## Reference implementations
- API routes: see `src/app/api/users/route.ts` -- follow this exact pattern
- React components: see `src/components/Button.tsx` -- named exports, no default exports
- Database queries: see `src/db/queries/users.ts` -- use this query builder style

When Claude needs to create a new API route or component, it reads the reference file first. This produces far more consistent code than prose descriptions alone.

Reference files also catch cases where your written description doesn't fully capture the pattern. The actual code is the ground truth -- pointing Claude there removes ambiguity.

7. Use @ to mention files in context

Instead of describing a file and hoping Claude finds it, mention files directly with the @ syntax in your messages:

Fix the type error in @src/lib/auth.ts -- the issue is in the middleware chain

Claude reads the file immediately and works with the actual code rather than searching for it. This is faster and produces more accurate results than "look at the auth file." Press Tab after typing @ to get autocomplete for file paths.

The @ syntax also works for directories. @src/components will load the directory listing, helping Claude understand what components already exist before it creates a new one.

8. Break large tasks into explicit steps

Claude Code performs better with clear sequencing. Instead of:

"Refactor the auth system to use JWTs"

Try:

"Step 1: Read the current auth implementation at src/lib/auth.ts and src/middleware.ts. Step 2: Identify what needs to change to support JWTs. Step 3: Make the changes, starting with the token generation function."

The explicit steps prevent Claude from jumping ahead, making assumptions, or producing a large change that's hard to review.

For complex refactors, consider adding a checkpoint: "After Step 2, show me the list of changes you plan to make before you start Step 3." This gives you a chance to catch misunderstandings before code is written.

9. Keep a "project context" section for onboarding

Add a section to CLAUDE.md that serves as background for any new conversation:

## Project context
This is a B2B SaaS for construction project management.
- Multi-tenant: each request has a `tenantId` from the session
- All database queries must be scoped by `tenantId` -- never query across tenants
- The codebase is mid-migration from Pages Router to App Router -- do not create new Pages Router routes
- We are on a feature freeze until March -- no new dependencies or architectural changes

This kind of context prevents Claude from making changes that are technically correct but wrong for your specific situation -- like adding a new dependency during a freeze or forgetting to scope a query by tenant.

Update this section whenever the project's status changes. A stale context section is worse than no context section, because Claude will act on outdated information with confidence.

10. Use custom instructions for consistent commit messages

Add commit message conventions directly to CLAUDE.md:

## Commit messages
Format: `type(scope): description`
Types: feat, fix, refactor, test, docs, chore
Example: `feat(auth): add JWT refresh token support`
- Use imperative mood ("add" not "added")
- Keep subject under 72 characters
- Reference issue numbers when applicable: `fix(api): handle null response (#234)`

When you ask Claude to commit changes, it will follow this format automatically. No more fixing commit messages manually after the fact.

This also helps when multiple engineers on a team are using Claude Code -- everyone gets consistent commit history without a separate style guide document.

11. Store architecture decisions in CLAUDE.md

Architecture Decision Records (ADRs) are valuable, but they're often buried in docs folders that Claude doesn't see. Bring the key decisions into CLAUDE.md:

## Architecture decisions
- **State management**: We use Zustand, not Redux. The store is at src/store/.
- **API layer**: All external API calls go through src/lib/api-client.ts -- never call fetch() directly in components
- **Error handling**: All errors flow through src/lib/error-handler.ts -- never swallow errors silently
- **Feature flags**: Use the `useFeatureFlag` hook from src/hooks/use-feature-flag.ts

These entries prevent Claude from suggesting "just use Redux" or calling APIs directly from components -- mistakes that require review cycles to catch.

Keep these entries short and direct. The goal is to tell Claude what decision was made and where the relevant code lives, not to explain the full reasoning.

12. Use the skills system for team onboarding

When new engineers join and set up Claude Code, they need the same project context you've been building up. Instead of sending them a doc to copy-paste, publish your CLAUDE.md skills to a private registry:

localskills publish --private

New teammates run one command:

localskills install your-org/project-name --target claude

They have the exact same Claude context you do. No manual setup, no drift. Read more in our guide on publishing your first skill.

This approach also means onboarding improvements are captured for everyone. When a new engineer discovers a missing rule during their first week, they add it to the skill and publish an update. The whole team gets it on the next pull.

13. Version-pin your skills

If your team publishes shared skills, version-pin your installs. This prevents automatic updates from introducing unexpected behavior changes mid-sprint:

localskills install your-team/api-conventions@2.1.0 --target claude

When you're ready to update, review the changelog and update deliberately:

localskills update your-team/api-conventions --target claude

This gives you the same stability guarantees you'd expect from npm packages -- important when Claude conventions are part of your team's development workflow.

Version pinning is especially useful around major releases or sprints with tight deadlines. You can update skills between sprints rather than mid-feature, keeping behavior predictable while work is in progress.

14. Write Claude rules in the same PR as the feature

The most common CLAUDE.md anti-pattern: updating the rules file after a painful code review reveals something Claude got wrong. By then, the rule is written in frustration and often too broad.

Instead, when you make an architecture decision, add the corresponding CLAUDE.md entry in the same PR. If you decide "all API responses must include a requestId field for tracing," add that rule immediately:

## API conventions
- All responses must include a `requestId` field -- use the `generateRequestId()` utility

Future changes to that endpoint will get the rule right from the start.

The same applies to "do not" rules. When a PR review catches Claude doing something wrong, add the prohibition in that review's comments, then include it in CLAUDE.md when the PR merges.

15. Build a personal skill library for cross-project conventions

Beyond team skills, your personal coding preferences are worth capturing. How you like tests structured, your preferred error handling patterns, how you write TypeScript generics -- these are consistent across every project you work on.

Build a personal skill library on localskills.sh (skills can be private) and install it as a baseline in every new project:

localskills install your-username/personal-conventions --target claude

Combined with the project-specific CLAUDE.md, you get both universal preferences and project-specific rules. For CLAUDE.md files, more specific instructions typically take precedence when there's a conflict. For skills, Claude reads both personal and project-level skills and uses judgment to reconcile them.

Personal skills also accumulate over time. Each time you catch Claude making a mistake you've seen before, add a rule to your personal skill. After a few months, you have a well-tuned baseline that sets up any new project correctly from day one.

---

Putting it together

The developers who get the most out of Claude Code treat it like a new team member: they invest in getting it up to speed properly. That means structured CLAUDE.md files, explicit rules, reference implementations, and -- increasingly -- shared skills that keep conventions consistent across projects and teammates.

The best practices for AI coding rules apply equally here: write for the AI like you'd write for a contractor who is smart but has no existing context about your project.

Start with tips 1, 5, and 6 -- they have the highest impact per minute invested. Once you've got a solid CLAUDE.md in place, explore skills to share conventions across your team.

---

Ready to share your Claude Code setup across projects and teammates? Sign up for localskills.sh and publish your first skill in minutes.

npm install -g @localskills/cli
localskills login
localskills publish