How I use Claude Code | Rafal Muszynski

I gave a talk at work recently about how I use Claude Code. Figured I’d write it up properly since most of it applies to anyone writing code with AI tools.

Quick context: I’ve been messing with AI dev tools since 2021 — got into the early OpenAI beta, built a side project on top of it. Since then I’ve tried basically everything that came out. Copilot, Cursor, Cline, Codex. I’ve been using Claude Code daily for about a year now and I’m part of their developer program. So this isn’t a first impressions post.

Why Claude Code over everything else

Honest take on what I’ve used:

GitHub Copilot is good autocomplete but that’s it. No reasoning, no codebase awareness. Cursor is a decent IDE but I felt like I was adapting to the tool instead of the other way around. Cline is agentic but heavy, less control. Codex is solid for TypeScript — it thinks longer but produces accurate results in one go. Weaker in PHP though, and you can’t have a back-and-forth while it works.

Claude Code fits because I live in terminal, I work mostly in PHP, and I want to see what the model does and correct it as it goes. It took config investment to get here, but that’s the point.

How I actually work with it

I almost never say “build me X” and accept whatever comes back.

My flow: I tell it to create a plan. It explores the codebase and writes up an approach. I review, we go back and forth — “what about X” or “this part won’t work because Y” — until the plan is solid. Then it implements step by step. I review every change as it happens and correct when something’s off. When I’m happy with the code, I run the tests myself locally. No point burning tokens on test runs when I can just do it. Then I create the PR.

The model never just runs off and does everything.

I also do this thing where I tell it “you’re a senior engineer at Stripe with 20 years of experience — how would you approach this? Don’t edit code.” It pushes the model to give a more opinionated answer instead of a generic one. I switch the persona depending on what I’m working on — Shopify for e-commerce flows, Anthropic for AI tooling, whatever fits the problem.

The model proposes, I decide. It’s a fast teammate, not a substitute for judgment.

On prompts

This might sound obvious but it took me a while to get right: the more detail you put in, the better the output. Be specific, give context, set constraints.

But — one thing at a time. If you ask for five things in one prompt, you’ll get weak results on all of them. Break it down. One clear ask per prompt. That alone makes a huge difference. I sometimes see the model going sideways mid-task, but I wait until it finishes and then correct, rather than interrupting.

The config file

Every project can have a CLAUDE.md file — instructions the model follows every session. This is the single most important thing in my setup.

Mine has dynamic context loading. I work across multiple projects, so instead of loading everything, the agent figures out which project I’m talking about based on keywords. PHP stuff goes to one repo, Angular to another.

It also has my workflow preferences, commit conventions, common mistakes I’ve corrected over time. When the model does something wrong and I fix it, I add the correction to CLAUDE.md so it doesn’t happen again. Over time the file gets smarter. After a year it knows my codebase, my conventions, my preferences.

I invest maybe 10 minutes a week updating it. That compounds.

Skills

Skills are markdown files that give Claude Code specific expertise for a task. I have 9; the ones I lean on most:

ticket — I type /ticket with a ticket number, it fetches the Jira ticket, figures out which project it belongs to, loads the right context, and suggests an implementation approach
commit-push-pr — stages, commits, pushes, and opens a PR. The model is actually disabled for this one (disable-model-invocation: true). It just follows the script. No hallucination possible.
code-review-php — reviews PHP code with DDD awareness, outputs findings with file and line references
domain-driven-design — helps with domain modeling decisions
playwright-tests — writes E2E tests
staff-engineer — helps think through architectural trade-offs

They’re portable — work in Codex too, same format. They follow an open spec at agentskills.io. You can clone the repo, symlink the skills to ~/.claude/skills/, and use them right away as slash commands.

I also use the code-review skill to review teammates’ pull requests. I run it locally on their branch, it produces findings with file and line references, and I copy the relevant comments into the PR myself. I tried automating this with a GitHub Action but hit an SDK error I haven’t debugged yet. Manual for now, but it still saves a lot of time reading through changes.

Hooks

One small thing that removes daily friction: I have a PostToolUse hook that runs after Claude edits a file. If the file is PHP, it automatically runs php-cs-fixer through Docker. Every edit gets auto-formatted. No manual formatting, no style comments on PRs. I don’t have to think about it.

Navigating across repos

Probably the biggest win I’ve had wasn’t writing code — it was navigating code.

I needed to integrate a testing framework across four repositories. Mostly legacy code I’d never worked in. I pointed Claude Code at these repos and it helped me trace data flows across all of them — how things connect, where the legacy parts are, what’s safe to change. I ended up shipping a backward-compatible integration. Would have taken me way longer without it.

This is honestly where I get the most value. Not generating code — understanding code. Especially across repos you don’t fully own.

Writing docs while exploring

When I’m exploring something complex, I tell Claude to write a short doc about what it found. Or when I’m planning a new feature, I tell it to write an RFC.

Something like: “Explore how fields flow from API to the analyzer. Don’t edit code. When you’re done, write a one-pager under docs/.”

These docs accumulate in the project. Next time I or Claude needs that context, I just say “read this doc first.” The exploration work isn’t wasted — it becomes reusable context.

Git worktrees for parallel work

When I’m juggling multiple tasks on the same repo, I use git worktrees. Each worktree is an isolated copy of the repo on its own branch. I can have Claude Code working on one thing while I review or test something else. No branch switching, no stashing. I usually just tell it something like “create it in a new git worktree” when I kick off a task, and it sets one up automatically.

How these pieces fit together

If it helps, think of it like onboarding a new team member.

CLAUDE.md is onboarding — “here’s how we do things, here’s what to watch out for.” You write it once, keep it updated. The agent reads it every time.

Skills are specialized training. The person knows the basics from onboarding, but when they need to do a code review or write E2E tests, they pull out the playbook for that specific job.

Docs are notes someone left in a shared folder. “I looked into how X works, here’s what I found.” Next person who needs that context just reads the notes instead of figuring it out from scratch.

Try this today

Install Claude Code, open your project, and type:

Explain the architecture of this project. Don't edit code.

No risk. No changes to your code. Just see if it understands your codebase. That’s the gateway.

If that’s useful: write a CLAUDE.md in your project root, grab a skill or two, add a hook for your formatter. It takes a few weeks before it clicks. But once it knows how you work, you stop fighting it.

Thanks for reading.