50 Claude Code Tips I Wish I Knew From Day One

Most Claude Code tip lists are written from a weekend of playing with the tool. This one is written from months of running it daily against a production Laravel codebase that auto-deploys to a live site on every push to main, which concentrates the mind wonderfully. Every tip below is a habit I actually keep, and the ones that matter most are backed by files that exist in my repo right now: a tuned CLAUDE.md, a pre-commit hook, a permissions allowlist, and an MCP config.

One scoping note so this list stays useful: this is the foundation layer, the habits that survive tool updates. For newer feature-specific tricks I keep separate, updated lists in 32 power-user hacks and 16 productivity hacks. Nothing below is duplicated there.

CLAUDE.md: the file that pays rent (tips 1-10)

1. Run /init before writing your own CLAUDE.md. It detects your framework, test runner, and conventions. Review, then customize. That order matters.
2. Document the lies your project tells. The single highest-value line in my CLAUDE.md is a quirk: in my repo, composer test runs PHPStan, not PHPUnit. Every tool and human trips on that exactly once. Write down whatever the equivalent trap is in your project.
3. Write rules as commands, not essays. "Use php artisan test --filter=X, never composer test" beats three paragraphs about testing philosophy.
4. Put verification commands in the file. Mine lists the exact sequence: Pint, targeted PHPUnit, PHPStan level 8. Claude runs them without being asked because they are written down.
5. Record where things live, not what they do. "Models are domain-organized under app/Models/Website/, check there before creating folders" prevents an entire category of misplaced files.
6. Add a "skip ceremony" list. My CLAUDE.md explicitly names trivial task types (typo fixes, translation keys) that need no planning ritual. Saves tokens and time on every small task.
7. Name your gotcha files. Mine warns: the deploy pipeline removes public/hot, never commit it. An agent reading that will not "helpfully" commit the file that breaks production assets.
8. Update CLAUDE.md the moment a gotcha bites. Not at the end of the session. The rule I follow: if I correct Claude twice for the same thing, that correction becomes a line in the file.
9. Keep it lean by auditing monthly. Every line loads into every conversation. Rules that stopped being relevant are a permanent token tax.
10. Split global vs project instructions. My ~/.claude/CLAUDE.md holds cross-project rules (conventional commits, never commit secrets); the repo file holds project law. Do not duplicate between them.

Context hygiene (tips 11-17)

1. /clear between unrelated tasks. Stale context from a debugging session actively degrades the next feature task.
2. /context when responses get weird. Nine times out of ten something large (a big file read, a verbose tool result) is crowding out your instructions.
3. /compact mid-task, /clear between tasks. Compact keeps the thread; clear resets it. Choosing the wrong one either loses your state or drags your garbage along.
4. Point at files, do not paste them. Claude can read your repo. Pasting 300 lines into the prompt duplicates them into context forever.
5. Ask for a plan before code on anything touching three or more files. Plan mode exists for this; reviewing a plan costs seconds, unwinding wrong edits costs an afternoon.
6. Interrupt early. The moment output heads the wrong way, stop it. Waiting out a wrong 2,000-token answer to be polite is a habit worth breaking.
7. Start long work with a written scope. One sentence: what is in, what is out. Agents drift far less when the boundary exists in text.

Permissions and safety (tips 18-25)

1. Let your allowlist grow organically. My settings.local.json permits php artisan, vendor/bin/pint, grep, git add/commit, and dozens more, each added when a real prompt got annoying. Do not pre-approve broad patterns you have never needed.
2. Treat git push as a special permission. My repo deploys main to production automatically, so a push is a deploy. Branch protection plus a branch-first rule in CLAUDE.md is my seatbelt.
3. Never let an agent near .env. Secrets stay in environment files and secret stores; my global instructions flag any exposed credential immediately. Make yours do the same.
4. Use a pre-commit hook as the hard floor. Mine runs Pint (blocks on failure) and PHPStan (warns) on staged PHP files. The agent cannot commit unformatted code even if it tries, because git itself refuses.
5. Production databases are read-only for agents. I generate idempotent, transaction-wrapped SQL for my own review instead of letting anything write directly. One rule, zero disasters so far.
6. Skip-permissions mode belongs in containers only. Disposable environment, fine. Anywhere with real data, no.
7. Review diffs before commit, every time. git diff reading is the cheapest QA you will ever do on agent output.
8. Give destructive commands a naming convention. Anything with rm, drop, truncate, or --force gets typed by me, not approved from a prompt.

Verification loops (tips 26-32)

1. Define "done" as passing commands, not confident prose. My CLAUDE.md swaps verify steps per domain: UI change means load the page, queue change means dispatch a job, search change means run a query. Write your own table.
2. Make the agent run the formatter before finishing. Pint for me, Prettier or Black for you. Formatting noise in diffs hides real changes.
3. Targeted tests over full suites during iteration. php artisan test --filter=RelatedTest keeps the loop tight; the full suite runs before merge.
4. Static analysis catches what tests miss. PHPStan at level 8 flags the type lies an LLM occasionally writes. Cheap to run, brutal to skip.
5. Verify UI at real widths. My rule is desktop, tablet, and mobile for anything user-facing; a browser MCP makes the agent do this itself.
6. Ask "what did you verify?" at handoff. An agent that must answer that question does more verifying. Evidence before assertions.
7. Keep a failing-command log. When a verify step fails twice for the same reason, that reason is either a bug or a missing CLAUDE.md rule. Decide which.

Skills, MCP, and extensions (tips 33-38)

1. Install MCP servers for capabilities, not conveniences. My project .mcp.json carries exactly one server, Laravel Boost, because version-accurate docs, tinker, and database access are things Claude cannot otherwise do. My full reasoning is in the three MCPs I actually use daily.
2. Audit MCP context cost. Every connected server loads schemas into your window. Uninstalling unused servers is a free context upgrade.
3. Turn repeated prompts into skills. I keep a whole family of SEO skills (audit, hreflang, images, content) because I ran those prompts weekly. Third repetition means it becomes a skill.
4. Scope skills tightly. A skill that does one check well beats a mega-skill that does five things vaguely.
5. Prefer project-scoped config, committed to the repo. Teammates and future sessions inherit it. Personal config is for personal quirks.
6. Read a skill before trusting it. Community skills are prompts with your permissions. Treat installation like adding a dependency.

Parallel work (tips 39-43)

1. Parallelize by file boundary, not by ambition. Two agents touching the same files produces merge archaeology. Independent surfaces only.
2. Use git worktrees for isolation. Each agent gets its own checkout and branch; my full workflow, including the push-to-main gotcha that makes isolation non-optional on an auto-deploying repo, is in how I run parallel Claude Code agents.
3. Three parallel agents is the honest ceiling. Beyond that, your review capacity, not the model, is the bottleneck.
4. Give each agent a deliverable, not a vibe. "Rewrite these ten posts, output one file each, backed up first" works. "Improve the blog" does not.
5. Batch independent work into waves. I have run content overhauls as six sequential waves of parallel workers. Waves make progress resumable when something interrupts.

Memory and continuity (tips 44-47)

1. Keep a memory index, not a memory dump. My auto-memory is a short index file linking topic files (translation status, SEO recovery, server credentials location). Indexes stay cheap to load; dumps rot.
2. Write the resume manifest before you need it. Long multi-session jobs get a status JSON (done/pending per item) so any future session can resume without re-reading everything. This habit has saved me across every multi-week project.
3. Record decisions with dates. "Freeze lifted 2026-05-29" is useful forever; "recently unfrozen" is useless in a month.
4. End sessions with a two-line summary. What changed, what is next. Future you is a different person with no context.

Cost and model choice (tips 48-50)

1. Match model to task shape. Deep refactors and judgment-heavy analysis get the big model; mechanical transforms get the fast one. Paying flagship prices for find-and-replace is the most common waste I see.
2. Measure your own numbers before optimizing. Run /context, look at what actually dominates, then fix that. Cargo-culting someone else's token diet fixes their problem, not yours.
3. Spend tokens on planning, save them on retries. The cheapest token is the one that prevented a wrong implementation. Every expensive session I have ever had was expensive because of rework, not because of planning.

Where to go from here

If you only adopt five of these, adopt 2, 8, 21, 26, and 40: document the traps, update docs when bitten, enforce quality in git itself, define done as passing commands, and isolate parallel work. Those five turned Claude Code from a clever autocomplete into something I trust against a production repo.

A lot of the repeatable workflows behind these tips, the SEO audits, content pipelines, and review routines, are packaged as installable skills in my Agent Skills Marketplace. If you would rather start from a working config than build one habit at a time, that is the shortcut.