Sign in Subscribe

Day 7: Putting It All Together — Your Complete Claude Code Setup

Complete Claude Code setup checklist combining git, CLAUDE.md, prompting habits, command rules, and review workflows. 10 minutes setup, hours saved.

Day 7: Putting It All Together — Your Complete Claude Code Setup

Hey, it's G.

Day 7 of the Claude Code series. Phase 1 wrap-up.

The first six days covered individual pieces:

  • Installation
  • Prompting
  • CLAUDE.md
  • File access
  • Terminal commands
  • Git safety

Today I'm tying it all together into one setup I now run on every project before touching Claude Code.

It's not complicated. It's just a checklist that makes everything else work better.

Let me show you the complete foundation.

Why Setup Matters (The Hard Truth)

Here's what I did with my first two production apps (Resiboko and 1MinThumb):

❌ No CLAUDE.md
❌ Barely using git properly
❌ Writing lazy prompts
❌ No command rules
❌ Not reviewing changes consistently

Did they ship? Yes.

Was the process messy and stressful? Absolutely.

Could I have avoided a lot of pain with proper setup? 100%.

Here's the reality:

Most developers skip setup and jump straight into prompting.

That works... until it doesn't.

Wrong conventions. Unexpected file changes. No way to revert. Debugging what Claude did becomes archaeology.

Ten minutes of setup at the start of a project means every Claude Code session after that is:

  • Faster
  • Safer
  • More accurate
  • More predictable

The Concept (Your Pre-Flight Checklist)

Think of this as your pre-flight checklist.

Pilots don't skip it even if they've flown a thousand times. Neither should you.

Claude Code is only as good as the environment you set it up in.

A project with no git, no CLAUDE.md, and no prompting habits = inconsistent, risky results.

A project that's properly set up takes 10 minutes to configure and pays back every single session.

The Five Layers (What Makes a Complete Setup)

1. Git Initialized

Your undo button. Without git, you're flying blind.

2. CLAUDE.md Written

Your permanent briefing. Claude knows your project, conventions, and rules every session.

3. Prompting Habits

Context, goal, constraints. Clear communication = better results.

4. Command Rules Set

What Claude can run freely vs. what needs approval. Prevents destructive operations.

5. Review Habit

git diff after every session. You always know what changed.

All five together = a Claude Code setup that's fast, safe, and consistent.

The Complete Setup Checklist (Run This on Every New Project)

Step 1: Initialize Git

git init
git add .
git commit -m "initial commit"

Why: Creates your baseline. Every change after this is trackable and reversible.

When to skip: Never. Seriously. Never work without git.

Step 2: Create CLAUDE.md

touch CLAUDE.md
code CLAUDE.md

Why: Gives Claude permanent context it reads automatically every session.

Step 3: Fill in Your CLAUDE.md Starter Template

# Project Name

## What This Is
[One paragraph describing what the project does]

## Tech Stack
- [Framework]
- [Language]
- [Database]
- [Styling]
- [Deployment]

## Key Folders
- /[folder] → [what lives here]
- /[folder] → [what lives here]

## Coding Conventions
- [Convention 1]
- [Convention 2]
- [Convention 3]

## Never Do This
- Don't install new dependencies without asking
- Don't modify [critical files] without flagging it
- Don't change existing component APIs without confirming

## Command Rules
- Always ask before: npm install, migrations, git push
- Run freely: npm run dev, npm run build, npm run lint

## Useful Commands
- `npm run dev` → start local server
- `npm run build` → production build
- `npm run lint` → run linter

Customize this template for your actual project.

Don't leave placeholder text. Fill in real values.

Step 4: Verify Claude Read Your CLAUDE.md

claude

> What do you know about this project and what are your rules?

Claude should summarize:

  • What the project is
  • Your tech stack
  • Your coding conventions
  • Command rules (what it can/can't run freely)

If the summary looks correct, you're set.

If not, edit your CLAUDE.md and verify again.

Step 5: Commit Before Every Claude Session

git add .
git commit -m "before claude session"

Why: Creates a clean baseline. Every change Claude makes is clearly visible in git diff.

This is the single habit that saves you the most pain.

Step 6: Review After Every Claude Session

git diff

Why: Shows you exactly what Claude changed. Catch mistakes before they become problems.

Then:

  • Good changes? → git add . && git commit -m "claude: descriptive message"
  • Bad changes? → git checkout .

Real Example (Complete Setup From Scratch)

Let me walk through setting up a brand new project with this checklist.

Scenario: Starting a new SaaS project for Filipino freelancers.

Step 1: Initialize Git

cd ~/projects/freelance-tracker
git init
git add .
git commit -m "initial commit"

Step 2-3: Create and Fill CLAUDE.md

touch CLAUDE.md
code CLAUDE.md

My actual CLAUDE.md for this project:

# Freelance Tracker

## What This Is
Project management and invoicing SaaS for Filipino freelancers. 
Helps track client projects, hours worked, and generate invoices in PHP.

## Tech Stack
- Next.js 14 (App Router)
- TypeScript (strict mode)
- Supabase (auth, database, storage)
- Tailwind CSS (no custom CSS)
- shadcn/ui components
- Vercel (deployment)

## Key Folders
- /app → App Router pages and API routes
- /components/ui → shadcn/ui components (don't modify)
- /components/custom → our custom components
- /lib/supabase.ts → Supabase client (don't touch)
- /utils → helper functions
- /types → TypeScript types

## Coding Conventions
- Functional components only (no class components)
- Named exports only (no default exports)
- Tailwind utility classes only (no inline styles, no custom CSS)
- TypeScript strict mode (no `any` types)
- Currency always displayed in PHP (₱)
- Use existing UI components before creating new ones

## Never Do This
- Don't install new dependencies without asking
- Don't modify /lib/supabase.ts
- Don't change component APIs without discussion
- Don't add custom CSS files
- Don't use default exports

## Command Rules
- Always ask before: npm install, Supabase migrations, git push
- Run freely: npm run dev, npm run build, npm run lint

## Useful Commands
- `npm run dev` → local dev server (port 3000)
- `npm run build` → production build
- `npm run lint` → ESLint check
- `npx supabase status` → check Supabase connection

Step 4: Commit CLAUDE.md

git add CLAUDE.md
git commit -m "add claude.md configuration"

Step 5: Verify Setup

claude

> What do you know about this project and what are your rules?

Claude responds:

This is Freelance Tracker, a project management and invoicing SaaS 
for Filipino freelancers built with Next.js 14, TypeScript, and Supabase.

Key rules I'll follow:
- Use named exports only, no default exports
- Tailwind utility classes only, no custom CSS
- TypeScript strict mode, no any types
- Display currency in PHP (₱)
- Always ask before installing dependencies or running migrations
- Can freely run dev, build, and lint commands

Tech stack: Next.js 14 App Router, TypeScript, Supabase, Tailwind, 
shadcn/ui components, deployed on Vercel.

Perfect. Claude knows the project.

Step 6: Start First Real Task

> Look at the folder structure and suggest what we should 
> build first based on the project description in CLAUDE.md

Claude analyzes the structure and responds:

Based on your project structure and description, I suggest starting with:

1. Database schema for projects and invoices
2. Authentication flow using Supabase
3. Dashboard layout with navigation
4. Project creation form

Would you like me to start with the database schema? 
I can create a migration file with tables for projects, 
clients, hours, and invoices.

Now we're building.

The Before/After (What This Setup Actually Changes)

Without Proper Setup

Session 1:

> Add user authentication

Claude: [adds auth, uses default exports, writes inline styles]

Me: Wait, I wanted named exports and Tailwind

Claude: [fixes it]

Me: Also this should use Supabase not Firebase

Claude: [rewrites everything]

Me: [30 minutes wasted explaining conventions]

With Proper Setup

Session 1:

> Add user authentication

Claude: [adds auth using Supabase, named exports, Tailwind components, 
matches existing patterns from CLAUDE.md]

Me: Perfect. Commit it.

[5 minutes total]

The difference: CLAUDE.md eliminates the explanation phase every session.

The Habits That Matter Most

From building with Claude Code for months, these are the habits that actually save you:

Habit 1: Git Commit Before Every Session

git add .
git commit -m "before claude: adding invoice generator"

Why it matters: Clean baseline for git diff. Easy revert point.

When I skip this: Debugging what Claude changed becomes guesswork.

Habit 2: Review Immediately After Changes

git diff

Why it matters: Catch mistakes while context is fresh.

When I skip this: Bad code makes it to production. Debugging takes hours.

Habit 3: Descriptive Commit Messages

❌ Bad:

git commit -m "claude changes"

✅ Good:

git commit -m "claude: add zod validation to project form"

Why it matters: Future you needs to know what happened and why.

Habit 4: Keep CLAUDE.md Updated

When tech stack changes, update CLAUDE.md immediately.

Examples:

  • Switch from Pages Router to App Router → Update tech stack section
  • Add Prisma → Update dependencies and command rules
  • Change styling approach → Update conventions

Why it matters: Stale CLAUDE.md = Claude following outdated rules.

Habit 5: Verify Claude Read CLAUDE.md on New Projects

First command every new project:

claude
> What do you know about this project?

If Claude's summary is wrong, fix CLAUDE.md before continuing.

Common Setup Mistakes (What Not to Do)

Mistake 1: Skipping Git Initialization

Problem: No undo button. Can't track what Claude changes.

Solution: git init before first Claude session. Always.

Mistake 2: Writing Vague CLAUDE.md

❌ Vague:

## Coding Conventions
- Write clean code
- Use best practices

✅ Specific:

## Coding Conventions
- Named exports only, never default exports
- Tailwind utility classes only, no inline styles
- TypeScript strict mode, no `any` types

Mistake 3: Not Testing the Setup

Problem: You create CLAUDE.md but never verify Claude actually read it correctly.

Solution: Always ask "What do you know about this project?" to verify.

Mistake 4: Inconsistent Review Habits

Problem: Sometimes you check git diff, sometimes you don't.

Solution: Make it non-negotiable. Review after every single session.

My Raw Notes (Unfiltered)

This is the stuff I wish I knew before I built Resiboko and 1MinThumb.

I was just winging it — no CLAUDE.md, barely using git properly, writing lazy prompts. It worked but it was messy.

Doing this properly from day one on the next project.

The checklist sounds simple but it makes a real difference.

The git commit before every Claude session is the one habit that saves you the most pain.

Ten minutes of setup = hours saved over the life of the project.

Phase 1 Complete 🎉

Days 1–7 covered:

  • Day 1: What Claude Code is and how to install it
  • Day 2: How to prompt it effectively
  • Day 3: CLAUDE.md — your permanent briefing
  • Day 4: What Claude Code can see in your project
  • Day 5: Running terminal commands
  • Day 6: Reading and writing files safely
  • Day 7: The complete setup checklist (today)

Phase 2 Starts Tomorrow

Topic: Getting Productive — CLAUDE.md mastery, custom workflows, and real vibe coding patterns.

Day 8 Preview: CLAUDE.md Mastery — going deeper on the most powerful configuration file in your Claude Code setup.

The Complete Checklist (Copy This)

Run this on every new project:

# 1. Initialize git
git init
git add .
git commit -m "initial commit"

# 2. Create CLAUDE.md
touch CLAUDE.md
code CLAUDE.md
# Fill in the template with real project details

# 3. Commit CLAUDE.md
git add CLAUDE.md
git commit -m "add claude.md"

# 4. Verify setup
claude
# Ask: "What do you know about this project and your rules?"
# Verify Claude's summary matches your CLAUDE.md

# 5. Before every Claude session
git add .
git commit -m "before claude: [what you're building]"

# 6. After every Claude session
git diff
# Review changes, then commit good ones or revert bad ones

That's your foundation. Everything in Phase 2 and beyond builds on this.

G

P.S. - I built 2 production apps without this setup. They shipped, but the process was messy and stressful. This 10-minute checklist changes everything.

P.P.S. - The single most valuable habit from this entire foundation: git commit before every Claude session. It creates a clean baseline that makes git diff actually useful.

P.P.P.S. - If you've been following this series, you now know more about Claude Code fundamentals than 95% of people using it. Phase 2 is where it gets really good.