I'm Not Going to Share My Claude Code Setup With You

I've sent about 11,000 prompts to Claude Code over the last five months. I've built 21 custom skills, configured 100 security rules, wired up integrations to my company's data warehouse and Slack, and shipped 57 PRs in production TypeScript as a PM who isn't an engineer by training.

People keep asking me to share my setup.

I'm not going to.

Not because it's secret. Because it wouldn't help you.

The Setup That Only Works for Me

My degree is in civil engineering. My grad degree is in education. Before I became a PM I spent years deploying software for enterprise customers. I started writing code in the production codebase about a year ago, and Claude Code is a big part of how that became possible.

Every piece of my setup reflects that specific path. I built a customer sentiment skill that reads full Gong call transcripts instead of AI summaries because I spent years in customer-facing roles and I know that the exact words people use matter more than a one-paragraph brief. I built a skill that simulates code reviews from the specific engineers who work on the files I touch because I'm a PM shipping code into an engineering codebase and I need to catch the obvious mistakes before real reviewers see them. I built a writing skill that runs a four-pass edit to strip AI patterns from text because I have strong opinions about how writing should sound and I know what makes AI output recognizable.

If I gave you those skills, you'd be adopting my workflow, my opinions about how call transcripts should be read, my assumptions about what a code review should catch, my rules about what makes writing sound human. You'd spend more time adapting my stuff to fit your brain than you would building your own from scratch.

Why Sharing Setups Misses the Point

There's a whole genre of content right now that's "here's my CLAUDE.md" or "here's my dotfiles for AI." I get the impulse. When a tool is new, you want to see how other people use it. I look at other people's setups too. I enjoy seeing how someone else thinks about the problem.

But there's a difference between learning from someone's approach and adopting their configuration. When you copy someone's CLAUDE.md, you're importing their assumptions about how work should flow, their opinions about what's important, their tolerance for risk, their communication style. Those things are personal, and they should be.

The whole promise of AI tools like Claude Code is that they bend to you. You don't have to learn a rigid interface or adapt to someone else's workflow. You can describe how you think, how you work, what annoys you, what you care about, and the tool shapes itself around that. Every other productivity tool in history made you adapt to it. This one adapts to you.

So why would you start by adopting someone else's adaptation?

What I Actually Did

I didn't start with a plan. I started with a problem.

The first skill I built was for customer research. I was spending hours reading call transcripts manually, trying to find patterns across dozens of calls. So I described that workflow to Claude Code and turned it into a reusable command. It wasn't elegant. But it worked for me because I built it around how I actually think about customer conversations, not how someone else thinks I should.

Then I built one for CI monitoring because I was tired of watching build dashboards. Then one for account research because I was doing the same data warehouse queries every week. Then one for drafting Slack messages because I wanted to review before sending. Then one for generating demo data. Then one for filing documents into the right folder. Each one started with something that annoyed me, not with a best practices list.

I've built a browser router app for my local machine. I've built a custom MCP server for a tool that didn't have one. I built an entire self-improving loop where my PR review feedback gets extracted into a database, and future code gets checked against those patterns automatically. None of this came from reading someone else's guide. It came from hitting a wall, getting annoyed, and saying "can Claude Code fix this?"

Some of it was probably counterproductive. I've definitely spent time (and tokens!) building things that already existed somewhere. But I learned more from building my own version than I would have from installing someone else's. The building is where you figure out what you actually need, because you're forced to articulate your own workflow to a machine that takes you literally.

How I Use the Basics

I run about 10 sessions at once. Right now one is for this article, one for a mobile feature I'm researching, one for a PR I'm iterating on, one where I was debugging a Slack bot earlier. I flip between them like browser tabs. Each holds its own context, so I can leave something mid-thought and come back hours later without re-explaining. About 650 sessions total over five months.

I rename sessions as soon as I know what they're about: "Mobile POC Demo," "csv import issue," "tabbed record detail pages." Takes two seconds. When you have ten sessions open and they're all called "Claude," you waste time clicking through each one.

About 4% of my prompts are screenshots. I paste one in and say "this doesn't look good" or "the spacing is off." For UI work, pointing at what's wrong beats describing it every time.

The Things Worth Sharing

What I will share is the principles, not the implementation.

Build for your annoyances. My skills exist because of specific friction in my specific day. Yours will be different. Start with the thing that makes you sigh.

Let it run. Auto mode with a strong deny list instead of approving every action. The deny list blocks about 100 patterns (package installs, credential access, shell config edits). Everything else runs on its own. Permission prompts break concentration. Define your real boundaries and let the tool move within them.

Simulate the humans before you ship. My favorite skill is one that reviews my PRs as the specific engineers who actually review them. It looks at who recently touched the files I changed, pulls their last 20 review comments to build a profile of what each person flags, then dispatches parallel agents to review my code as each engineer would. It fixes what it finds and runs another round with fresh reviewers until it's clean. By the time real engineers see my PR, the obvious stuff is already caught. The pattern transfers: figure out who or what is going to judge your work, and have the AI play that role before they do.

Talk to it. Over 80% of my prompts are voice-dictated through Wispr Flow. You wouldn't know from reading them because Wispr produces clean, punctuated text. On a typical day I type maybe 15-20% of my inputs: slash commands, file paths, "yea" or "push it." Everything else is spoken. It changes how you interact with the tool. You explain what you want the way you'd tell a colleague, not the way you'd write a spec. More honest about what you actually need.

Steal these principles, not the config.

The Real Takeaway

AI is an equalizer, but not the way people usually mean. It's not that we all get the same tools and produce the same output. It's that we can all reach the same outcomes (shipping code, building products, writing documents, researching customers) through paths that are genuinely our own.

I think in terms of customer conversations and product gaps. Someone else thinks in terms of data models and system architecture. Someone else thinks in narratives and stakeholder management. We all do overlapping work, but how we approach it is shaped by how we think, what we've done before, and what we care about. AI tools can accommodate all of that.

The instinct to standardize, to find the one best CLAUDE.md, to build a team-wide skill set, to define "best practices" for how everyone should use the tool: that instinct comes from a world where tools were rigid and people had to conform to them. We're not in that world anymore.

So don't copy my setup. I'm not going to share it, and you wouldn't want it anyway. Build your own. Start with what annoys you, describe it to the machine, iterate until it feels right. You'll end up somewhere I never would have, and that's the whole point.

— AP