Anatomy of the .claude Folder: Your AI Dev Control Center
Understand every file inside the .claude folder ā CLAUDE.md, settings.json, rules, skills, agents, and hooks. Turn Claude Code from a chat assistant into a project-aware engineering partner.
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.
Enjoyed this article?
Explore the Cloud & DevOps learning path for more.
Found this helpful?
Leave a comment
Have a question, correction, or just found this helpful? Leave a note below.