Vibe Coding · Lesson 3 of 3
The .claude Folder Anatomy
Claude Code — AI Pair Programmer
The .claude/ folder is how you configure, constrain, and extend Claude's behaviour on a per-project basis. Master it and Claude stops being a chat tool and starts being a senior teammate.
Why the .claude Folder Exists
When you run claude in a project, it doesn't just read your prompt — it reads your entire project context: architecture rules, allowed commands, saved workflows, memory from past sessions. All of that lives in .claude/.
There are two separate locations:
| Location | Scope | Committed? |
|---|---|---|
| .claude/ in your repo root | Project-level — shared with your team | ✅ Yes (except *.local.*) |
| ~/.claude/ in your home directory | Global — applies to every project on your machine | ❌ No |
The Full Folder Structure
your-project/
├── .claude/
│ ├── settings.json ← permissions & behaviour flags
│ ├── settings.local.json ← your personal overrides (gitignored)
│ ├── rules/ ← auto-loaded instruction files
│ │ ├── api-design.md
│ │ └── ef-core.md
│ ├── skills/ ← on-demand reusable workflows
│ │ ├── code-review/
│ │ │ └── SKILL.md
│ │ └── fix-issue/
│ │ └── SKILL.md
│ ├── agents/ ← specialized subagents
│ │ └── security-auditor.md
│ ├── docs/ ← reference docs skills pull on demand
│ │ ├── architecture.md
│ │ └── coding-standards.md
│ └── worktrees/ ← temp git worktrees for agent isolation
├── CLAUDE.md ← root instruction file (always loaded)
└── src/CLAUDE.md — The Foundation
Rule of thumb: Whatever you write in CLAUDE.md, Claude will follow. It's the single most impactful file in the entire setup.
CLAUDE.md is loaded into every session automatically, before you type a word. It survives context compaction — when Claude's memory gets compressed, this file is reloaded fresh from disk.
Claude also walks up the directory tree looking for CLAUDE.md files. A file in src/api/CLAUDE.md applies only when working in that folder. The root one applies everywhere.
Keep it under 200 lines. Longer files cause instruction-adherence to degrade.
What to put in CLAUDE.md
# Project: Clinic Appointment System
## Tech stack
- .NET 9, PostgreSQL, Kafka, React 19
- ORM: EF Core 9 — code-first, Fluent API only
- Auth: JWT (JJWT 0.12) — never store tokens in localStorage
## Build & test
- `dotnet build` — build all
- `dotnet test` — run all tests (Testcontainers, needs Docker)
- `npm run dev` — start frontend
## Architecture rules
- Package by feature, not by layer
- Commands/Queries: sealed interfaces, MediatR handlers
- Never throw generic Exception — use ProblemDetails
## What NOT to do
- Do not add logging inside domain models
- Do not run `git push` without asking
- Do not modify migration files that are already appliedWhat NOT to put in it
- Linting rules (your linter handles those)
- Long prose explanations (link to docs instead)
- Anything already in your
rules/folder
.claude/rules/ — Modular, Path-Scoped Instructions
When your CLAUDE.md starts exceeding 200 lines, split it into focused rule files. Rules in this folder load automatically — but the smart part is path scoping: a rule only activates when Claude edits a file that matches a path pattern.
.claude/rules/
├── ef-core.md ← only when touching DbContext or migrations
├── api-design.md ← only when editing controller/endpoint files
└── dotnet-conventions.md ← always loadedA path-scoped rule uses YAML frontmatter:
---
paths:
- "src/Infrastructure/Persistence/**/*.cs"
- "**/*DbContext*.cs"
- "**/Migrations/**"
---
# EF Core Rules
- Always use Fluent API in `OnModelCreating` — no data annotations on entities
- Never add navigation properties without explicit `HasForeignKey`
- Every new migration must have a descriptive name: `Add_AppointmentStatus_Column`
- Run `dotnet ef migrations add` — never hand-edit migration filesBenefits:
- Rules only consume context tokens when relevant
- Different teams can own different rule files
- Much easier to review than one giant CLAUDE.md
.claude/settings.json — Permissions & Configuration
This is Claude's permission firewall. It uses a three-tier evaluation: deny rules win first, then explicit allows, then Claude asks you.
{
"permissions": {
"allow": [
"Bash(dotnet build *)",
"Bash(dotnet test *)",
"Bash(dotnet ef migrations *)",
"Bash(npm run *)",
"Bash(git status)",
"Bash(git diff *)",
"Bash(git add *)",
"Bash(git commit *)",
"Read",
"Write",
"WebFetch(domain:docs.microsoft.com)",
"WebFetch(domain:learn.microsoft.com)"
],
"deny": [
"Bash(rm -rf *)",
"Bash(git push *)",
"Bash(git reset --hard *)",
"Bash(DROP *)",
"Read(./.env*)",
"Read(**/secrets/**)"
]
},
"env": {
"ASPNETCORE_ENVIRONMENT": "Development"
}
}Permission Pattern Reference
| Pattern | What it allows |
|---|---|
| Bash | All bash commands |
| Bash(dotnet test *) | Any command starting with dotnet test |
| Read | All file reads |
| Read(./.env) | Reads of .env only |
| WebFetch(domain:github.com) | Fetches to github.com only |
| Agent(Explore) | Spawning the Explore subagent |
| Skill(deploy *) | Running any skill starting with deploy |
settings.local.jsonis the machine-local sibling — same format, but gitignored automatically. Use it for personal allowances you don't want to share with the team.
.claude/skills/ — Reusable Workflows
Skills replace the old commands/ system. They're more powerful — they can auto-invoke, restrict tools, use cheaper models for read-only tasks, and pre-process shell output before Claude sees it.
Each skill lives in its own subfolder with a SKILL.md file:
.claude/skills/
├── code-review/
│ └── SKILL.md
├── generate-migration/
│ └── SKILL.md
└── fix-issue/
└── SKILL.mdExample: Code Review Skill
---
name: code-review
description: >
Perform a structured code review. Auto-invoke when the user
asks to review a PR, diff, or set of changed files.
allowed-tools: Read, Glob, Grep, Bash(git diff *), Bash(git log *)
model: sonnet
argument-hint: "[branch or file path]"
---
You are a senior engineer reviewing a pull request.
Changed files since main:
!`git diff main...HEAD --name-only`
Full diff:
!`git diff main...HEAD`
Review for:
1. Logic bugs and edge cases
2. Missing error handling
3. Naming clarity
4. Test coverage gaps
5. Security issues (SQL injection, auth bypass, secrets in code)
Output a structured review with: ✅ Good / ⚠️ Concern / ❌ Blocker labels.The !`` backtick syntax runs a shell command and injects its output into the prompt before Claude sees it. So !git diff main...HEAD`` becomes the actual diff text.
Invoking Skills
/code-review # manual invoke
/code-review src/api/ # with argument
/generate-migration AddClinicTable # passes argOr Claude auto-invokes them based on the description field when the context matches.
.claude/agents/ — Specialized Subagents
Agents are separate Claude instances with their own isolated context windows. They're great for:
- Security audits (don't want security findings contaminating your main context)
- Long exploratory research
- Running tasks in parallel
---
name: security-auditor
description: >
Security specialist. Automatically invoke when reviewing authentication,
payment processing, or HIPAA-sensitive code.
tools: Read, Glob, Grep
model: sonnet
maxTurns: 50
---
You are a senior application security engineer.
Audit for:
- SQL injection (especially raw queries, string interpolation in SQL)
- Broken authentication (missing JWT validation, weak token storage)
- Insecure direct object references (IDOR)
- Hardcoded secrets or API keys
- Missing input validation on public endpoints
- HIPAA violations: PHI in logs, unencrypted storage
Return a prioritised findings report: CRITICAL → HIGH → MEDIUM → LOW.When Claude spawns this agent, it gets a separate context window. It reads files, analyses code, then compresses findings back into your main session.
Key difference from Skills:
- Skills run in your current conversation context
- Agents run in complete isolation — they can't accidentally contaminate your main session
.claude/docs/ — On-Demand Reference
Unlike rules/ (which always loads), docs/ files are dormant until a skill explicitly reads them. This is the DRY principle applied to prompts — write your architecture decisions once, reference from multiple skills.
.claude/docs/
├── architecture.md ← domain model, bounded contexts
├── api-contracts.md ← REST conventions, status codes, versioning
├── deployment.md ← environments, Terraform, CI/CD steps
└── coding-standards.md ← patterns, naming, what to avoidA skill references a doc file like this:
---
name: write-api-endpoint
---
Read .claude/docs/api-contracts.md before writing any endpoint.
Then implement the requested feature following those conventions exactly.Global ~/.claude/ — Personal Configuration
Everything in ~/.claude/ applies across all your projects, on your machine only.
~/.claude/
├── CLAUDE.md ← your personal rules for every project
├── settings.json ← your global permission defaults
├── rules/ ← personal rules (load before project rules)
├── skills/ ← personal skills available everywhere
├── agents/ ← personal agents
└── projects/
└── my-project/
└── memory/ ← auto-memory (first 200 lines per session)Example personal CLAUDE.md:
# Personal preferences
- Always use British English in comments and docs
- Never use `var` — use `const` or `let`
- Prefer explicit return types in TypeScript
- When I ask to "clean up" code, fix formatting only — don't refactor logic
- Never commit without asking me firstConfiguration Loading Order
When Claude starts in a project, this is the exact priority stack (highest wins):
1. Managed policy (enterprise system-level)
↓
2. CLI arguments
↓
3. settings.local.json (your personal overrides)
↓
4. .claude/settings.json (project settings)
↓
5. ~/.claude/settings.json (global personal settings)Deny rules always override allow rules, regardless of position in the stack.
Visual Summary
┌─────────────────────────────────────────────────────────┐
│ .claude/ folder │
│ │
│ CLAUDE.md Always loaded. The team contract. │
│ │
│ settings.json Firewall: allow / deny / env vars │
│ │
│ rules/ Auto-loaded. Path-scoped. Passive. │
│ └── ef-core.md Only activates for DB files │
│ │
│ skills/ On-demand. Active workflows. │
│ └── code-review/ Invoked by /code-review or auto │
│ │
│ agents/ Isolated context. Subagents. │
│ └── security-auditor.md Spawns separate Claude │
│ │
│ docs/ Dormant. Read by skills when needed.│
│ └── architecture.md │
└─────────────────────────────────────────────────────────┘What to Commit vs What to Gitignore
| File/Folder | Commit? | Why |
|---|---|---|
| CLAUDE.md | ✅ Yes | Team contract |
| .claude/settings.json | ✅ Yes | Shared permissions |
| .claude/rules/ | ✅ Yes | Shared code standards |
| .claude/skills/ | ✅ Yes | Shared workflows |
| .claude/agents/ | ✅ Yes | Shared agents |
| .claude/docs/ | ✅ Yes | Shared reference docs |
| .claude/settings.local.json | ❌ No | Machine-specific |
| ~/.claude/ (global) | ❌ No | Personal preferences |
Add this to your .gitignore:
# Claude personal overrides
.claude/settings.local.json
# If you don't want to expose your team config at all:
# .claude/
# CLAUDE.md
# AGENTS.mdPractical Progression: When to Add What
Day 1 — Start here
- Create
CLAUDE.md(30–50 lines) - Add
settings.jsonwith basic denies - Block
git pushandrm -rf
Week 2–3 — Organise
- Split into
rules/with path scoping - Add
docs/architecture.md - Add team coding standards rule
Month 2 — Automate
- Add
skills/for repeated workflows - Code review skill
- Migration generator skill
Month 3+ — Scale
- Security auditor agent
- Hooks for pre/post actions
- Worktree isolation for big tasks
Key Distinctions to Remember
Rules vs Skills:
- Rules load passively and automatically — they're standing instructions
- Skills activate on-demand (manual
/skill-nameor auto-triggered by context)
Skills vs Agents:
- Skills run inside your current conversation context
- Agents spawn an isolated context window — useful for tasks you don't want polluting your main thread
Project vs Personal:
- Project files (committed) ensure every team member's Claude behaves consistently
- Personal files (local) preserve your individual workflow without affecting colleagues
The Big Picture
The .claude/ folder transforms Claude Code from a general-purpose assistant into a project-aware engineering partner — one that knows your architecture, respects your constraints, and executes your workflows with minimal friction. The 30 minutes you spend on a good CLAUDE.md saves hours of repeated corrections across every session.