The Best Claude Code Setup for 2026 (30-Minute Guide)

Every Claude Code setup I’ve reviewed falls into one of two failure modes. The first is bare default: no CLAUDE.md, no skills, permissions prompts on every command, and the user wondering why Claude keeps forgetting how their project builds. The second is the over-configured machine: 40 skills, 9 MCP servers, a CLAUDE.md the length of a term paper, and a context window that’s half consumed before the first prompt.

The good setup sits between those, and it takes about 30 minutes to build if you do the layers in dependency order. That order matters. Skills assume a working install. Permissions decisions depend on which MCP servers you run. The per-project split only makes sense once you know what you’re splitting. This is the guide we hand new SkillProof teammates on day one, with the parts we got wrong over six months removed.

Layer 1: install and auth, five minutes

You’ve probably done this already, so I’ll keep it short.

npm install -g @anthropic-ai/claude-code
cd your-project
claude

On first run, /login walks you through auth. You have two billing paths: a Claude subscription (Pro or Max) or an API key with pay-per-token billing. If you code with Claude daily, the subscription is almost always cheaper; API billing on heavy agentic sessions adds up faster than people expect. If you’re on a team, check whether your org has a Claude for Work seat before burning a personal API key.

Verify with something trivial (“what does this repo do?”) and confirm Claude can read your files. That’s the whole layer. Everything below is where setups actually diverge.

Layer 2: a CLAUDE.md that earns its tokens

CLAUDE.md is a markdown file Claude reads into context at the start of every session in that project. Every session, whether the content is relevant or not. That loading behavior dictates everything about what belongs in it.

What belongs: facts that apply to nearly every session. Build and test commands. The two-sentence version of your architecture. Conventions Claude keeps getting wrong without being told (your import ordering, your commit format). Where the bodies are buried: the deprecated module nobody should touch, the config file that looks unused but isn’t.

What doesn’t belong: procedural knowledge you need occasionally. How to write a database migration. Your release checklist. The house style for customer emails. Each of those applies to maybe 5% of sessions, and in CLAUDE.md you pay for them in the other 95% too. That material wants to be a skill (next layer), which loads only when triggered.

Our rule of thumb after testing this on our own repo: if your CLAUDE.md is over 60 lines, something in it should move out. Ours started at 400 lines because we treated it like documentation. Claude followed it worse, not better, because the signal drowned. The compressed version, about 50 lines of commands and hard constraints, gets obeyed almost every time.

Write the first draft in ten minutes and stop. You’ll refine it for weeks as you catch Claude repeating mistakes; that iterative loop is the actual method. The full treatment, including the anti-patterns we see in reader-submitted files, is in our CLAUDE.md guide.

Layer 3: skills, the layer most people skip

This is the layer that separates a setup from an install, and it’s the one most people never touch. A skill is a folder with a SKILL.md file that teaches Claude a way of working. It costs roughly 100 tokens of metadata while idle and loads its full instructions only when a task matches its description. Installed once, it applies forever, across every session.

People skip this layer for a rational reason: about half the community skills on GitHub fail on first install. We know because installing and testing them is our whole business. Every skill in the SkillProof catalog gets a clean-machine install and trigger checks, then real tasks run against a no-skill baseline, before it gets a verdict. Of the 73 skills we’ve cataloged so far, 35 passed.

For a developer setup, these are the five to install first, with scores from our test runs:

1. Test-Driven Development, 9.6. Forces strict red-green-refactor: failing test first, minimal implementation, then cleanup. In our three-feature session it never skipped the cycle, even when we tried to talk it into skipping.
2. Systematic Debugging, 9.6. Replaces guess-and-check fixes with a hypothesis-test-verify loop. It root-caused a race condition Claude had previously “fixed” three times by guessing.
3. Frontend Design, 9.6. The largest before/after gap we’ve measured on any skill. Same landing-page brief, run twice: baseline produced the neon-gradient centered-everything look, the with-skill version had a real type scale and a palette that looked chosen.
4. Memory Management, 9.2. Gives Claude a persistent memory across sessions. Over a week of testing it reliably recalled project decisions and preferences, and recall stayed accurate as the store grew.
5. Webapp Testing, 8.8. Claude drives your app in a real browser through Playwright and reports what breaks. It caught a regression our unit tests missed.

The first two come from Jesse Vincent’s Superpowers collection (/plugin marketplace add obra/superpowers-marketplace, then /plugin install superpowers). Frontend Design ships in Anthropic’s official skills repo and copies straight into ~/.claude/skills/. Exact steps, including the failure modes that eat people’s first hour, are in the install guide. After installing, restart Claude Code and test each trigger by asking for the work without naming the skill. If nothing visibly changes, the skill isn’t firing, and an installed skill that never fires is just a folder.

If your work leans a different direction, our best coding skills list ranks the full category, updated as new test runs land.

Layer 4: MCP servers, only the ones you’ll use

MCP servers connect Claude to things outside the repo: your database, your issue tracker, a live browser. They’re powerful and they are the most expensive line item in your context budget. Every connected server injects its tool definitions into every session, used or not, and a single chatty server can cost more standing tokens than 50 installed skills combined. We measured this in the token cost guide, and the numbers changed how we configure our own machines.

So the bar for an MCP server should be high: it earns a slot only if Claude needs to reach something it otherwise can’t. Three tend to survive that test for developers:

A database server (Postgres or whatever you run). Claude writing queries against your real schema instead of a guessed one is a different product. This is the single highest-value MCP connection for most teams.

Browser automation (Playwright MCP), if you ship UI and don’t use the Webapp Testing skill’s own setup. Seeing the rendered page beats inferring it from JSX every time.

Your issue tracker, but only if you actually work ticket-to-ticket inside Claude Code. If you glance at Linear twice a day, the browser is fine and the tokens aren’t worth it.

Notice what’s missing: the GitHub MCP server. The gh CLI does everything it does, Claude already knows how to use it, and it costs zero standing context. This substitution pattern generalizes. Before adding any server, ask whether a CLI tool Claude can call gets you the same reach for free. And if you’re weighing whether a problem needs MCP at all or just a skill, the decision rule is in skills vs MCP: skills change what Claude knows how to do, MCP changes what it can touch.

Layer 5: permissions and safety settings worth changing

The default permission experience is a prompt for nearly every command, which trains people to click allow reflexively. That’s the worst possible outcome: all the friction, none of the safety. Two changes fix it.

First, allowlist the commands you’d approve anyway. In .claude/settings.json:

{
  "permissions": {
    "allow": [
      "Bash(npm test:*)",
      "Bash(npm run lint:*)",
      "Bash(git status)",
      "Bash(git diff:*)",
      "Bash(git log:*)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)"
    ]
  }
}

Second, notice the deny block, because it’s the half people skip. Claude has no business reading your .env, and a deny rule makes that a property of the system instead of a hope. If you run MCP servers or skills from third parties, this matters more, since a malicious instruction can’t exfiltrate what the harness won’t read. Our security guide covers the audit side.

On --dangerously-skip-permissions: the flag name is honest. Inside a throwaway container with no credentials, it’s a fine way to run long unattended jobs. On your laptop, with your SSH keys and your logged-in browser sessions, it’s how you end up starring in a postmortem. We use it in CI sandboxes and nowhere else.

Per-project vs global: where each piece lives

Everything above exists at two levels, and mixing them up is the most common config mess we see. The split:

Piece	Global (~/.claude/)	Per-project (.claude/ in repo)
CLAUDE.md	Your personal style: response length, languages, pet peeves	Build commands, architecture, project conventions (commit this)
Skills	Everything general: debugging, TDD, writing	Team-specific workflows only
Settings	Your personal allowlist	Team allowlist and deny rules (commit this)
settings.local.json	—	Your machine-only overrides (gitignore this)
MCP servers	Servers you use everywhere	Project’s .mcp.json, so teammates get the same connections

The principle: anything a teammate would need goes in the repo, anything that’s about you goes global. The payoff shows up when someone new clones the project and Claude already knows the build commands and conventions, with the database connection ready to go. Their layer 2 and half of layer 4 come free.

My setup after six months

What actually survives on my machine, for calibration: a 54-line project CLAUDE.md, nine skills, two MCP servers (Postgres and Playwright), and the permissions block above. Setup sessions feel identical to six months ago; the difference is everything I deleted.

The removals taught me more than the additions:

Removed the GitHub MCP server. Kept it four months out of inertia. Its tool definitions cost thousands of standing tokens per session and gh did the same work. Nothing degraded. This one deletion paid for the time to write this article.

Removed a memory MCP server in favor of the Memory Management skill. The server was another process to babysit and another auth to maintain. The skill does the job in plain files I can read and edit myself. When memory misbehaves, I open the markdown and fix it, which I could never do with an opaque store.

Cut CLAUDE.md from 400 lines to 54. The long version read like good documentation and performed like noise. Compliance with the rules that mattered went up when the rules that didn’t were deleted. I now treat every line as rent.

Uninstalled 19 of 28 skills. Most were “might be useful” installs that never triggered in real work. Lazy loading means they cost little, but overlapping descriptions caused two real trigger conflicts, and the audit that found them was tedious. Nine skills that fire weekly beat 28 that mostly don’t.

Rolled back a blanket Bash(*) allow rule. Added it during a deadline week, kept it too long. The day Claude confidently ran a destructive migration against a dev database that turned out to be less disposable than labeled, I put the prompts back for anything that writes.

The pattern across all five: I never once regretted a removal. I frequently regretted additions.

Common first-week mistakes

Five things almost everyone does in week one, so you can skip them:

1. Writing the 500-line CLAUDE.md on day one. You don’t know yet what Claude gets wrong in your repo. Start with 15 lines and grow it from observed failures.
2. Installing every interesting MCP server. Each one taxes every session. Start with zero and add one when you hit a wall it solves.
3. Running --dangerously-skip-permissions on your main machine because the prompts annoyed you. Allowlist the safe commands instead; it kills 90% of the prompts without the exposure.
4. Installing skills and never verifying they trigger. Half the value of a skill dies in a vague description field. Test each one with a natural request, no skill names.
5. Keeping config out of the repo. If your project CLAUDE.md and settings.json aren’t committed, every teammate rebuilds your setup badly from memory.

Maintenance: what to revisit after each Claude release

A setup tuned for one model version drifts on the next. After each significant Claude release, spend 20 minutes on four checks.

Re-read your CLAUDE.md and delete rules the new model no longer needs. Model upgrades regularly obsolete instructions; the “always run the linter” rule you wrote a year ago may now be default behavior you’re paying tokens to restate.

Re-test your skill triggers. Trigger matching is model behavior, not keyword matching, so a description that fired reliably on one model can go quiet on the next. Our catalog re-tests top skills after major releases, and per-skill pages carry the current verdict.

Re-measure your context overhead. New releases sometimes change how MCP tool definitions are counted or cached. The efficiency tooling on our efficiency skills list is where we point people who want to audit what’s actually burning their budget; several skills in that category exist precisely for this checkup.

And check the changelog for permission-model changes before your team’s settings silently mean something different. This takes five minutes and has saved us twice.

FAQ

Is 30 minutes realistic, honestly?

For layers 1 through 5 as written, yes, we’ve timed it with new hires. What takes longer is the tuning: your CLAUDE.md reaches its stable form after two or three weeks of catching Claude’s repeated mistakes. Budget 30 minutes for the build and expect a few minutes of refinement per day for the first fortnight.

Do I need MCP servers at all?

Plenty of strong setups run zero. If your work lives in the repo (code, tests, docs), skills plus CLI tools cover it. MCP earns its cost when Claude needs live access to something external, and a database is the most common genuine case. When in doubt, start without and add the server the first time you feel the wall.

Should CLAUDE.md be global or per-project?

Both, holding different things. Global (~/.claude/CLAUDE.md) carries your personal preferences and applies everywhere. Per-project carries build commands and conventions, and belongs in git so the whole team shares it. The mistake is putting project facts in the global file, where they pollute every other project’s sessions.

How many skills is too many?

Token-wise, the ceiling is high: even 50 skills cost only a few thousand tokens of standing metadata. The practical ceiling is lower because skills with overlapping descriptions start competing for the same triggers. We run nine. Past 15 or so, you should be pruning whatever hasn’t fired in a month rather than adding.

Can I skip the permissions layer if I work in a sandbox?

If the sandbox is genuinely disposable, no credentials, no mounted volumes you care about, then yes, and --dangerously-skip-permissions exists for exactly that. The layer matters on machines with real secrets. Most people’s “sandbox” is a laptop with their production AWS keys in a dotfile, which is not a sandbox.