It is the second week of April 2026 and I am sitting at my kitchen table, sorting through my claude code tips 2026 notebook, repotting my keybindings one by one.
That is the only honest way to describe it. I had a cup of coffee, a paper notebook open to a fresh page, and a terminal humming next to me. I was going through my zsh aliases the way I go through the kitchen herbs at the start of every season. Half of them were dead. Some had been replaced by something better. A few I had forgotten I planted at all.
When I wrote down my notes for the original 50 Claude Code tips last year, I had no idea how much of that document would need a second pass. The bones are still right. The 50 tips still work. But if you have been using Claude Code daily through Q1 2026, you already know what I know: the tool you opened in January is not the tool you are using in April.
So here is the sequel pack. The things I learned the hard way, mostly by deleting work I should not have deleted and then walking around the block to calm down.
If you are new here, please go read the original 50 tips first. This post assumes you already know what /init does, what a CLAUDE.md file looks like, and why you should never run git reset --hard while a coding agent is mid-thought. This is the expansion pack.
Thirty new tips. Numbered 51 through 80, picking up exactly where the pillar post left off. Grouped into six themed sections so you can skim. Save your favorites. Argue with me about the rest.
Plan smarter (Tips 51-55)
The original 50 covered plan mode at a basic level. In 2026, planning is its own discipline.
Tip 51: Use /ultraplan for migrations, not for renames
/ultraplan sends your prompt to Opus 4.6 in the cloud, which thinks for as long as ten minutes before returning a plan. It is expensive compared to a normal plan-mode chat: roughly $0.40 to $1.20 per call depending on context size. So I treat it like ordering a tasting menu, not like grabbing a snack. I use /ultraplan for things like "migrate our auth from session cookies to JWT across 14 services" or "design the data model for the new billing system." I do not use it to rename a variable. The line I draw: if the plan would benefit from someone with two hours of uninterrupted thinking, use it. If a junior dev could plan it in five minutes, do not.
Tip 52: Chain plan mode into auto mode for one-shot features
Plan mode in 2026 has a quiet superpower. If you accept the plan with --auto, Claude Code will execute the entire plan in Auto Mode without asking permission for each step. I use this for greenfield features where I trust the plan completely, things like "scaffold a new internal admin tool with these five pages." It saves me from babysitting a thirty-step implementation. I do not use it for production refactors. Auto mode is a delicious shortcut for the right meal and a stomachache for the wrong one.
Tip 53: Write a "plan critique" prompt before accepting any plan
After Claude returns a plan, I paste this back: "Pretend you are the senior engineer reviewing this plan. What is the weakest assumption? What is missing? What would you push back on?" Roughly four out of five times this surfaces something I had not considered. The model is happy to disagree with itself. I learned this trick after I accepted a plan that quietly assumed my Postgres instance had pgvector installed. It did not.
Tip 54: Save plans as MDX in /plans/
Treat plans like recipes. I have a /plans/ directory checked into every project, and every accepted plan from /ultraplan lives there as a dated MDX file. When the implementation drifts, I have a paper trail. When I onboard someone new, I can show them why we chose what we chose. This is my single biggest team multiplier in the last six months.
Tip 55: Use plan mode in your shell history search
Your shell history is a dataset. I run history | grep "plan" once a week and skim what I planned versus what I shipped. The gap is where my estimation muscle gets stronger. Plan mode is not just a feature, it is a journal.
Memory and context (Tips 56-60)
I wrote a whole deep dive on the memory system recently, so I will keep these tight.
Tip 56: Treat MEMORY.md like a garden, not a junk drawer
The auto-memory file fills up faster than you think. After two months on a project, mine had 380 lines of notes, and easily 40% of them were stale. I now prune MEMORY.md every other Friday. I delete anything that is no longer true, anything Claude figured out from looking at the code itself, and anything that is just me being polite to a model. Keep what surprised you the first time. Toss what is obvious now.
Tip 57: Use the # shortcut to capture decisions, not facts
The # shortcut adds a line to memory mid-conversation. I used to use it for facts ("we use Stripe for payments"). Now I use it almost exclusively for decisions and their reasons ("we chose Stripe over Adyen because we needed Indian rupee support and Adyen pricing for INR was 40% higher"). Facts age. Decisions, with their reasons attached, age beautifully.
Tip 58: Keep CLAUDE.md and MEMORY.md doing different jobs
This is the question I get asked most often, so let me settle it. CLAUDE.md is the recipe card: rules, conventions, project facts, what to do, what not to do. MEMORY.md is the cook's notebook: things you learned while cooking, observations about this particular kitchen. There is a whole guide on the rules-files distinction if you want to go deeper. I check CLAUDE.md into git. I usually gitignore MEMORY.md.
Tip 59: Reset memory before big pivots
When my team pivoted our pricing model in February, I deleted MEMORY.md entirely and started fresh. The old memory was actively misleading the agent, full of references to the old plan structure. A clean compost pile is sometimes the right move. I keep a .bak copy for a week, then delete it.
Tip 60: Use 1M context for one-shot codebase reads, not for daily work
Sonnet 4.6 can read a million tokens of context. That is roughly 35,000 lines of code in one shot. I use it once a week, usually on Mondays, to ask Claude "summarize what changed in this codebase last week and what I should worry about." For daily work, smaller context is faster and cheaper. Fitting your whole pantry into one bowl is impressive but not how you should cook every meal.
Parallel and async (Tips 61-65)
This is where 2026 changed my life the most. I no longer think of Claude Code as a single conversation. I think of it as a small team.
Tip 61: Use Worktrees for any change touching more than 3 files
/worktree spins up an isolated git workspace, runs a parallel Claude session inside it, and lets you keep working on the main branch while the agent does its thing. I use this for anything non-trivial. The trick I had to learn the hard way: name your worktrees after the intent, not the branch. wt-fix-checkout-bug is much easier to find at 4pm on Friday than wt-feature-1234.
Tip 62: Routines for the boring stuff, never for the creative stuff
A Routine is a scheduled agent workflow. Mine run nightly at 2am: dependency audit, broken-link check, summary of yesterday's GitHub issues, tag cleanup. They are a kitchen prep crew, not a chef. I do not let routines write feature code. I do not let routines deploy anything. I do let them open draft PRs that I review with my morning coffee.
Tip 63: Use Dispatch when an idea hits at the worst possible time
Dispatch lets you send a task from your phone to a desktop Claude session. The killer use case is not "code while walking the dog." It is "I just remembered the staging env is broken, send a fix to my desk so it is ready when I get back." I have a small grammar I use in dispatch messages: verb, scope, constraint. "Investigate failing test on auth.test.ts, do not modify production code." That structure prevents the agent from improvising while I am away from the keyboard.
Tip 64: Never run more than 3 parallel agents on the same repo
I tried four. I tried six. The merge conflicts ate half the time the parallelism saved. Three is the sweet spot for a single repo. If you need more parallelism, split work across services or repos, where conflicts cannot reach each other.
Tip 65: Use the /background command for long-running tasks
/background pushes a task into a background slot and frees your active session. I use it for things like "run the full integration suite and summarize failures" or "scan the codebase for unused exports." The pattern: kick it off, switch contexts, come back in twenty minutes. Treat your active terminal like the front burner and /background like the slow cooker.
Power commands (Tips 66-70)
These are the small, quiet commands that I now use every day and could not work without.
Tip 66: /batch for repetitive edits across many files
/batch takes a single instruction and applies it across a glob of files in parallel. "Add a copyright header to all *.ts files," "rename this prop in every component that uses it," "convert these test files from Jest to Vitest." It is the find-and-replace I always wanted. The catch: always run with --dry-run first. Always.
Tip 67: /simplify on any function over 30 lines
/simplify asks Claude to refactor a chunk of code for readability without changing behavior. I run it on any function I wrote in a hurry. It is not a code reviewer. It is a sous-chef who tidies your station. Keep behavior tests handy and run them after.
Tip 68: /remote-control when you need browser context
/remote-control attaches Claude to a browser session via Playwright. I use it for "look at this page, tell me why the spacing is off" or "click through the signup flow and tell me where it breaks." It is slower than Cowork for full UI work but lighter for quick visual checks. The cost is real, around $0.10 per minute of active session, so I close it as soon as I am done.
Tip 69: /teleport-plan to move a plan from cloud to local
You ran /ultraplan in the cloud, you got a great plan back, and now you want to execute it locally with full filesystem access. /teleport-plan ports the plan into a local session with all the context. Without this, you would be copy-pasting the plan and losing references. With it, the local agent picks up exactly where the cloud planner left off.
Tip 70: /undo is not git, but it is your safety net
/undo reverses Claude's last set of file changes within a session. It is not the same as git checkout. It works even on uncommitted changes the agent made minutes ago, and it preserves your own intermediate edits. I have used /undo more times in 2026 than I have used Cmd-Z in any text editor. It saved me last Tuesday after I let an agent "modernize" a file that I had been hand-tuning for two days.
Extending Claude Code (Tips 71-75)
The plugin and skill ecosystem is the thing that separates 2026 power users from 2025 power users.
Tip 71: Write Skills for anything you do more than three times
Skills are reusable mini-prompts with their own instructions and tool access. The rule I follow: if I find myself typing the same setup paragraph for the third time, I turn it into a skill. My current top skills are migrate-django-model, write-rspec-from-pytest, and audit-tailwind-classes. None of them are clever. All of them save me a few minutes every time.
Tip 72: Custom MCP servers for your internal APIs
If your team has an internal API that Claude needs to interact with, write a small MCP server for it. We wrote one for our internal feature-flag service in about two hours, and it has saved an embarrassing number of "how do I toggle this flag" Slack messages. Start with the official MCP docs before reinventing anything.
Tip 73: Pin plugin versions in CLAUDE.md
The plugin ecosystem moves fast. I pin the versions of any plugin I rely on inside CLAUDE.md, and I update them on the same Friday rotation as my MEMORY.md cleanup. Surprise plugin upgrades have broken my workflow more than once.
Tip 74: Use PostToolUse hooks for auto-format and PreToolUse for guardrails
Hooks are the unsexy, life-changing feature of 2026. PostToolUse hooks run after a tool call finishes, perfect for auto-formatting any file the agent touched. PreToolUse hooks run before, perfect for blocking anything dangerous, like rm -rf or pushes to main. I have a small library of hooks I copy into every new project. The official Anthropic announcements page usually shows the latest hook patterns when new ones ship.
Tip 75: One agent, one job, when you orchestrate
When I run multi-agent setups, I give each agent one specialty and one specialty only. Reviewer. Tester. Implementer. Documenter. The temptation to make one agent do everything is strong and almost always wrong. Specialization beats generalization in agent orchestration the same way it does in restaurant kitchens.
Working at scale (Tips 76-80)
These are the ones I learned from running a small team and watching what broke as we grew.
Tip 76: Use Cowork for design feedback, not for code
Cowork is the desktop agent with Computer Use, the one that can drive your apps. I tried using it for code editing. It was fine but slower than the CLI. Where it shines is design feedback: "open Figma, look at the new dashboard, tell me what is off." That is something the CLI cannot do, and Cowork does it well. Right tool, right meal.
Tip 77: Standardize CLAUDE.md across teammates' machines
Nothing erodes team trust faster than "it works on my machine because my CLAUDE.md is different." We solved this by checking a team-CLAUDE.md into the repo and using a small bootstrap script that merges it into everyone's local ~/.claude/rules/. It took half a day to set up and removed an entire category of bug.
Tip 78: Set per-project budget alerts
Claude Code in 2026 lets you set a per-project monthly spend cap, and it warns you at 80%. I set every new project at $200 a month by default. Some projects need more. None of them need unlimited. The first time I forgot this, a runaway agent spent $87 in a single afternoon refactoring a file it should not have touched. Now budget caps are the first thing I configure.
Tip 79: Track your "edit acceptance rate" weekly
This is my favorite metric and almost nobody talks about it. How often do you accept Claude's diffs as-is? If your acceptance rate is above 90%, you are probably under-using the model. If it is below 50%, your prompts or your CLAUDE.md need work. My target is 70-80%. It is the closest thing to a North Star metric I have for working with an agent.
Tip 80: Take a Claude-free day every two weeks
This one is not a feature. It is a discipline. Every other Friday, I write code with no agent assistance. Just me, my editor, my brain. The point is not nostalgia. The point is to keep the muscle. I notice when my own habits get sloppy. I notice when I have started to outsource thinking I should be doing myself. The garden needs the gardener, not just the irrigation system.
A note on what is missing from this list
You will notice I did not write a tip about Claude Code on mobile, or a tip about the new voice mode, or a tip about the Slack integration. Two reasons. One, I have not used any of them enough yet to have an opinion worth printing. Two, the tips I list here are the ones I find myself recommending to teammates by reflex, in Slack, three or four times a week. That filter, "would I bother typing this to a friend who asked," kept the list honest. I would rather give you 30 tips I actually use than 50 tips I read about.
I also left out anything that is mostly hype. There are a handful of features that shipped in early 2026 that I think will matter eventually but do not yet. I will probably write about them in the third installment, sometime around the autumn.
What I am still figuring out
I will be honest. I do not have strong opinions yet on a few things.
I do not know whether Routines for code review is a great idea or a terrible one. I have one running on a side project and it is okay, but I keep wanting to argue with its tone.
I do not know whether /ultraplan is worth it for one-person projects, or whether the cost only justifies itself once you have teammates who will read the plan.
I do not know whether the plugin ecosystem will consolidate around a few official ones or stay scattered. My bet is consolidation by Q4 2026, but I have been wrong about ecosystem bets before.
If you have figured any of these out, I would love to hear. Tell me which of these 30 tips clicked for you, which ones you would replace, and which ones I missed entirely. The first 50 were the foundation. These 30 are the second story. There is going to be a third.
And if you got here without reading the original 50 Claude Code tips, please go read those next. They are the ground floor of everything I have written here. The sequel only makes sense if you have seen the first movie.
I am going back to my kitchen table to finish my coffee. The herbs need water.
