Back to blog
Cloud & DevOpsintermediate

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.

LearnixoApril 16, 202611 min read
Claude CodeAI ToolsDeveloper ProductivityClaudeAnthropicAI CodingWorkflow
Share:š•
Anthropic / Claude logo

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

Claude

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

MARKDOWN
# 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 applied

What 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 loaded

A path-scoped rule uses YAML frontmatter:

YAML
---
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 files

Benefits:

  • 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.

JSON
{
  "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.json is 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

Claude

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.md

Example: Code Review Skill

MARKDOWN
---
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

Bash
/code-review              # manual invoke
/code-review src/api/     # with argument
/generate-migration AddClinicTable   # passes arg

Or 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
MARKDOWN
---
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 avoid

A skill references a doc file like this:

MARKDOWN
---
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:

MARKDOWN
# 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 first

Configuration 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:

GITIGNORE
# Claude personal overrides
.claude/settings.local.json

# If you don't want to expose your team config at all:
# .claude/
# CLAUDE.md
# AGENTS.md

Practical Progression: When to Add What

Day 1 — Start here

  • Create CLAUDE.md (30–50 lines)
  • Add settings.json with basic denies
  • Block git push and rm -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-name or 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

Claude

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?

Share:š•

Leave a comment

Have a question, correction, or just found this helpful? Leave a note below.