Claude Code Quick Wins

Give me a lever long enough and a fulcrum on which to place it, and I shall move the world.

-Archimedes

This is the first post in a new series I'm calling Product Engineering - little notes for the people building software, regardless of whether your title says PM, designer, or engineer. The thread is the same: how do we ship better stuff, faster.

I've been using Claude Code everyday for a few months now, and what I see most often is people running it completely vanilla - one agent at a time, no custom commands, no tweaks to the defaults, just typing prompts into a fresh terminal like it's a fancier ChatGPT. It works! But it's leaving a lot on the table. Most of what makes Claude Code actually good is one settings change or one tiny habit away.

Here are the quick wins I'd give to anyone who already has it installed.

1. Plan first, then auto-accept

For anything complex - a new feature, a refactor, anything that touches more than a couple of files - hit shift+tab to enter plan mode, get Claude to write out exactly what it's going to do, then let it run on auto-accept while you go grab coffee.

Plan mode forces a checkpoint before any code gets touched. You read the plan, push back on the parts you don't like, and only approve once the approach is right. By the time it's executing, you've already done the hard thinking - the rest is just typing, and Claude is great at typing.

Skip plan mode for the small stuff. Save it for the work where the approach actually matters.

Bonus tip: use Opus in plan mode. The plan is the part that matters most, so spend the tokens there.

2. Make a slash command for anything you do twice

Got a workflow you keep repeating? Commit, push, open a PR. Run the linter, fix what it finds, re-run. Write a changelog entry from the diff.

Don't write the slash command yourself. Just tell Claude:

"Make me a slash command called /ship that stages, commits with a good message, and opens a PR."

It'll create the file, you'll have a new shortcut, and you'll feel slightly smug about it for the rest of the day. I have maybe a dozen of these now and I use them constantly.

3. Always give Claude a way to check its work

If Claude can't verify what it built, it will confidently tell you it works and then you'll spend twenty minutes finding out it doesn't.

So: point it at the test suite. Tell it the URL to hit. Give it a screenshot tool. Tell it to actually run the thing it just wrote.

Better yet, stop relying on yourself to remember. Drop a line in your CLAUDE.md that says something like "after any change, run the relevant tests and confirm the feature actually works end-to-end before declaring done." Now it's the default, not something you have to nag for in every prompt.

I took this one step further and wrote a /verify skill that runs the e2e flow for whatever I just touched. Anytime I finish a chunk of work I just type /verify and let it tell me if I actually shipped what I think I shipped. Roughly the highest-leverage skill I've made.

4. Install the GitHub code review action

Run /install-github-action once and from then on Claude will leave review comments on every PR you open. It's not perfect - sometimes it nitpicks, sometimes it misses things - but having a second set of eyes that always shows up has caught real bugs for me.

Five-minute setup. Pays for itself within a week.

5. Don't go nuts on MCPs

There's a temptation to install every MCP you find on Twitter. Resist it. Each one eats context and most you'll never use.

The short list I'd actually recommend:

• GitHub - for PRs and issues
• Context7 - up-to-date library docs (huge, since training data goes stale)
• Your task system (Notion, Linear, whatever) - so it knows what you're working on

Add others when you have a real reason. Not before.

6. Use worktrees to run Claudes in parallel

If you've ever wanted to kick off two big changes at once but didn't want them stomping on each other's git state, this is for you.

git worktree lets you check out multiple branches into separate folders backed by the same repo. Spin up a worktree, point a fresh Claude session at it, and it'll happily work on a feature while another Claude in your main folder works on something completely unrelated. No branch-switching, no stash dance, no "wait, why is this file modified."

The shortcut: claude -w. It creates a fresh worktree and drops you straight into a Claude session inside it - no manual git worktree add ceremony required. One command, new branch, new sandbox, go.

I'll usually have one Claude grinding on a refactor in a worktree while I keep building features in the main checkout. When the refactor's done, it's just a normal merge.

---

None of these are clever. They're all roughly five-minute changes. But the difference between a Claude Code user who does these six things and one who doesn't is enormous - the same way the difference between someone who knows three Vim shortcuts and someone who knows zero is enormous.

Pick one this week. See how it feels.

See you in the next one, Caden