The Claude Code Starter Config I Drop Into Every Project

Most people install Claude Code, point it at a folder, and start asking it to build things. It works. But the same person can install Claude Code into a project that already has a CLAUDE.md and a couple of skills, and the difference in output quality is immediate. The model goes from generic helper to something that feels tuned to how you work.

I've watched this pattern across 100+ people in ClaudeFluent sessions. The students who hand Claude a baseline config on day one ship faster, get fewer wrong-direction outputs, and stop fighting the same conventions over and over again. The students who skip it spend the first week re-explaining the same preferences to every new session.

So I packaged the baseline I actually use into a public repo. It's the same CLAUDE.md and skills folder I drop into every new project, with nothing project-specific so you can fork it and bend it to your stack.

What's In The Repo

Three files do all the work, and it looks like this once it lands in your project:

Here's what each one is doing:

• CLAUDE.md sits at your project root. Claude Code reads it automatically every session, before you say anything. This is where you encode your communication preferences, your stack defaults, your git rules, and anything you'd otherwise have to remind it of every time. The file in the starter is opinionated toward the Next.js, TypeScript, Tailwind, Supabase stack, but the structure transfers to any stack.
• .claude/skills/front-end.md is a skill Claude pulls in when you're doing UI work. It's a distillation of what makes a frontend look intentional instead of generic AI slop: typography choices, color and theme guidance, animation behavior, and a list of defaults to avoid. If you've ever shipped a Claude-built UI and felt like it had that "Tailwind starter template" flatness, this is the file that fixes it.
• .claude/skills/architect.md is the skill Claude pulls in when you ask architectural questions. It's tuned toward simplicity-first decisions, structured proposal output, and a short list of anti-patterns to actively avoid. Use it any time you're sketching a system or making a non-trivial design call.

Install In Sixty Seconds

Open Claude Code in the project where you want this set up, then paste the prompt below. It clones the repo, copies the relevant files into your project, and tells you what changed.

Clone https://github.com/travisseh/cc-starter-config into a temporary directory, then copy CLAUDE.md to my project root and copy the .claude/skills/ folder into my project. If a CLAUDE.md already exists, merge sensibly instead of overwriting and show me the diff. After copying, delete the temp clone. Tell me which files you added or changed and explain the role of each one.

If you'd rather do it by hand, the manual path is:

git clone https://github.com/travisseh/cc-starter-config.git
cp cc-starter-config/CLAUDE.md ./
cp -R cc-starter-config/.claude ./
rm -rf cc-starter-config

Customize Before You Build

The starter is a baseline, not a finished config. The first ten minutes after you drop it in are the most valuable you'll spend on developer experience all month. Open CLAUDE.md and edit it for your reality:

• Replace the stack section with the one you actually use. If you're on Postgres + Drizzle instead of Supabase, say so. Claude will respect it.
• Add a section for your domain. If you're building a marketing site, list your routes. If you're building a SaaS, list the user roles and the rules around them.
• Add the rules you've learned the hard way. Things like "never run destructive Supabase migrations without a dry run first" or "always use the existing logger, never console.log in committed code". These prevent the same bug twice.

The skills are easier to keep generic, but it's worth reading them once and removing anything that doesn't apply. A skill Claude has to mentally translate is worse than no skill at all.

Why This Compounds

Every Claude Code session re-reads CLAUDE.md from scratch. That sounds inefficient, but it's actually the feature: the work you put into the file once gets replayed on every prompt forever. A rule you write today is still active six months from now, in a session you don't even remember starting.

Skills work the same way. Once a skill is in your .claude/skills/ folder, Claude can reference it whenever the task matches, without you mentioning it. The frontend skill kicks in the moment you ask for UI work. The architect skill shows up when you ask Claude to design something. You stop manually re-priming the model and start composing with it.

That's the actual value of the starter. Not the specific words inside the file, those are easy to write. The value is having the muscle memory of always starting a project with a config baked in, so that by week two of a new project you're not re-litigating decisions you made on day one.

What To Do Next

Once the starter is dropped in:

1. Make sure Claude Code is set up. If you don't have it yet, see the desktop setup guide or the terminal setup guide.
2. Add a few skills beyond the two in the starter. The repo intentionally only ships two so you have room to add your own.
3. Spend ten minutes reading Claude Code best practices so you're not just running the config, you're running it well.

And if you fork the repo and add something good, send it over. The starter is a living config, not a finished one.