The Claude Code setup that actually works for weekend builds

The whole config, on one tree

Before the long version, here is the file layout. Two CLAUDE.md files. One settings.json. Three skill folders. That is the entire surface. If your current Claude Code setup has more files than this, the extra files are probably hurting you, not helping you.

The settings.json that does the heavy lifting

The full settings.json is six lines. The only field that matters is permissions.defaultMode set to acceptEdits. That single line is the difference between Claude Code feeling like a partner on a weekend build and feeling like a paranoid intern who interrupts you every 90 seconds for written approval.

What it does. File edits land without a permission dialog. Bash commands still prompt when they could touch outside the working tree (rm, curl piped to a shell, anything that writes to /etc), so the dangerous category still gets human approval. The shape of the prompt cadence flips: instead of one approval per write, you only see prompts when Claude wants to do something that could affect the host.

Why we tried richer settings and rolled them back. We shipped a version with custom allow rules per command. We shipped a version with file-path scope rules. We shipped a version that auto-denied anything outside /app. Every one of those got rolled back because the cost of being right (a few avoided shell prompts) was lower than the cost of being wrong (Claude getting blocked on an obvious-in-hindsight edit and the user wondering why their feature stopped working halfway through prompt three). The minimal config wins because the model is already good at picking which moves matter.

If you are not in a sandbox, this exact same field still works on a laptop. You are the sandbox. The blast radius of a bad edit is your working tree, which lives in git. git stash is a perfectly fine recovery primitive.

The project CLAUDE.md (the one Claude reads at the start of every session)

The project CLAUDE.md is the file most weekend setups skip. It is also the file that pays off the fastest. The job of this file is to tell Claude what is load-bearing and what is open for editing. Get this right and the model stops trying to be helpful in places it should leave alone.

The full file is around 100 lines. The four lines that pay rent are the "do not modify" list. vite.config.ts, src/main.tsx, src/_mk0rBridge.ts, src/index.css. Without this list, Claude will eventually get clever and reorganize one of them on a turn that was supposed to be about a button.

The second high-value piece is the mount rule: every new component must be imported in src/App.tsx. Without that rule written down, you get the most confusing failure mode in a weekend build, a feature where Claude wrote a beautiful component, the file is on disk, the dev server compiles cleanly, and nothing changes on the page. The component never got mounted. One sentence in CLAUDE.md prevents that for the rest of the session.

The third piece is styling rules: Tailwind v4 (which uses @import "tailwindcss", not v3's @tailwind base), three-color palette, no decorative icons. These exist because models will, in the absence of a specific style guide, default toward 2022-era purple gradients on Inter. CLAUDE.md is where you head that off once and never deal with it again.

The system prompt is three sentences. On purpose.

Most setup guides treat the system prompt as the place to write your "voice and tone" novella. That is the wrong file. System prompts are sticky, they live in code, they require a redeploy to change. CLAUDE.md is plain text in the working tree. It re-reads on every session start. It is the right place for everything substantive.

The system prompt covers exactly four things: role identity, working directory, dev server URL, what tools are available. Then it says "read your CLAUDE.md files" and gets out of the way. If you are tempted to write a long system prompt because you do not have CLAUDE.md yet, write CLAUDE.md instead. You will be glad you did the first time you want to change a coding rule mid-session without restarting Claude.

The MCP servers (Playwright is the one that pays off the fastest)

Three MCP servers run alongside the agent. Only one of them is essential for a weekend build, and that is Playwright. The other two are workflow extensions, useful but droppable.

Playwright MCP is what closes the loop on whether a change actually worked. After Claude writes a component, it runs browser_navigateagainst the dev server, takes a snapshot, and reads the DOM. If the form is not on the page, Claude knows it. If a console error fired, Claude reads it. The accuracy gain over "the file compiled, ship it" is the single biggest reason Claude Code feels good on a weekend build instead of feeling like you are debugging the agent.

Scheduler MCP is for the projects that need recurring work: a daily digest email, a periodic scrape, a Sunday-night data refresh. Standard 5-field cron, runs inside the same sandbox the agent edits in. You can drop this on a laptop setup; replace it with a launchd plist or systemd timer when you actually need scheduling.

mk0r-provisioning MCP is the lazy backend. When the user asks for email or persistence, the agent calls provision_email_audience() or provision_database(), which writes the env vars into /app/.env. On a laptop you would replace this with a personal Resend key and a local Postgres. The pattern (provision on demand, write to .env, restart the dev server, integrate) is the part worth stealing even if you swap out the implementation.

What it actually looks like when a turn runs

Concrete trace of what a single "add a contact form" turn looks like with this config. The agent is reading CLAUDE.md, picking the matching skill, calling the matching MCP, editing files, then running Playwright to verify, all without prompting the user.

This is the specific experience the six-line settings.json buys you. Without acceptEdits, the agent stops after step one and asks "may I edit src/components/ContactForm.tsx?" You answer yes, it stops again to ask about src/App.tsx, you answer yes, and so on. The turn balloons from a few seconds of focused work into a multi-minute approval drill. On a weekend build, that is the difference between shipping by Sunday and not shipping.

Three skills, all global

The three SKILL.md files in /root/.claude/skills/ are how Claude Code picks the right tool for the right phrase. Each skill has frontmatter with a description; Claude scans the descriptions on session start and matches them against incoming prompts. Concretely:

• frontend-designactivates when the user asks to build a component, page, or UI. It forces a step before code, "commit to an aesthetic direction", that pushes the model away from the default purple-gradient look. This is also the skill that bans Inter and Roboto in favor of distinctive Google Fonts pairings.
• copywritingactivates on any "write copy for" or "rewrite this" request. It enforces the obvious-but-easily-missed rules: clarity over cleverness, benefits over features, customer language over company language. On a weekend build, this is the skill that prevents the "Empower your workflow" landing page from happening.
• backend-servicesactivates on database, email, analytics, or auth requests. It is what wires the user's ask for "a contact form that emails me" to the actual provisioning call, then to the integration code that reads the freshly-written env vars.

Three is enough. We tried more. The hit rate per skill goes down sharply past the third, because the model is already good at the broader cases without a skill. Skills earn their keep when there is a specific failure mode worth pinning down: generic AI aesthetics, vague marketing copy, "but where do these env vars come from" provisioning confusion.

Drop-in for a laptop weekend build

If you want this exact setup on a laptop on Saturday morning, here is the short version, no sandbox required:

1. Create ~/.claude/settings.json with the six lines above. That is the whole file.
2. Create ~/.claude/CLAUDE.md with your global rules: how you want memory used, how you want corrections handled, your design defaults. Roughly 50 to 200 lines depending on how opinionated you are.
3. In the project root, create CLAUDE.md with the do-not-modify list, the mount rule, and the styling rules for that project. 30 to 80 lines.
4. Add Playwright MCP to your Claude Code config. Point it at your local Chrome. Drop the scheduler and provisioning MCPs unless you need them; you do not.
5. Optional: drop frontend-design, copywriting, or backend-services SKILL.md files into ~/.claude/skills/. Or write your own. The pattern is name + frontmatter description + body.
6. Run claude in the project. The first turn will tell you whether the config is doing what you wanted: edits should land without prompting, the agent should know the file rules, Playwright should fire after the change.

If you skip the project CLAUDE.md, you will hit the "component on disk but never mounted" failure mode within an hour. If you skip Playwright, you will be the one verifying every change. If you skip acceptEdits, you will give up by 3pm Saturday. The other pieces are nice. These three are load-bearing.

The honest counterpoint

defaultMode: "acceptEdits" is the right default in a sandbox. It is the wrong default if you are running Claude Code against a production codebase you ship to paying customers without a CI gate. In that environment, the cost of a bad edit is real, the recovery is more than git stash, and the time you save by skipping prompts is dwarfed by the time you spend untangling a regression.

The right framing is: this is the weekend-build config. Disposable working tree, fast feedback, low cost of a mistake. If you are using Claude Code to ship a real release on Monday morning, dial the permissions back up, add a pre-commit hook that runs the typechecker and tests, and treat the agent more like a colleague than a demo.

The setup in this article is for the four-hour Saturday window where you have an idea and you want it running. Use the right tool for the right context.