How Claude Code finds your config

A common point of confusion when setting up the command centre for the first time: if Claude Code reads skills from ~/.claude/skills/, and your project lives in ~/command-centre/, shouldn’t the command centre folder be nested inside ~/.claude/?

No. The two folders are independent. Both get loaded when you run claude from inside the command centre folder, without one being nested inside the other.

This page explains the mental model, because getting it wrong early leads to file-system layouts that are harder to undo later.

Two folders, two jobs

~/.claude/ is Claude Code’s own configuration folder. It holds settings, skills, subagents, and user-level CLAUDE.md that apply across every project you work on. It’s the equivalent of ~/.zshrc or ~/.gitconfig — config for the tool, not content you’re working on.

~/command-centre/ is your project folder. It holds your work: context files, workflows, scripts, outputs. It can live anywhere — ~/command-centre/, ~/Documents/command-centre/, ~/projects/command-centre/ all work identically.

These folders don’t need to know about each other. They’re not nested, and they don’t need to be.

What happens when you run claude from a folder

When you cd ~/command-centre && claude, Claude Code does this on startup:

1. Scans ~/.claude/skills/ for user-level skills. Every skill found here is available in this session.
2. Scans <current-folder>/.claude/skills/ for project-level skills. This is inside the project folder, not inside ~/.claude/. Project-scoped skills are committed with the project and only available when working from that folder.
3. Reads <current-folder>/CLAUDE.md if it exists. This is how the command centre’s index file gets picked up.
4. Reads ~/.claude/CLAUDE.md if it exists. A user-level CLAUDE.md layers on top, applying personal preferences across every project.

The skills don’t need to be physically near the command centre folder. Claude Code knows to look in both places automatically.

What it looks like on disk

~/                                    ← your home folder
├── .claude/                          ← Claude Code's config folder
│   ├── CLAUDE.md                     ← user-level CLAUDE.md (optional)
│   └── skills/                       ← user-level skills (everywhere)
│       ├── xlsx/
│       │   └── SKILL.md
│       └── pptx/
│           └── SKILL.md
│
├── command-centre/                   ← your project folder
│   ├── CLAUDE.md                     ← loaded when you cd here
│   ├── context/
│   ├── workflows/
│   └── outputs/
│
└── other-project/                    ← any other Claude Code project
    └── CLAUDE.md                     ← loaded when you cd here

When you’re in ~/command-centre/, Claude Code uses both: user-level skills from ~/.claude/skills/, and the project’s CLAUDE.md from ~/command-centre/. They cooperate without being nested.

Why this separation matters

Forcing skills to live inside each project folder would create three problems:

Duplication. Every project would need its own copy of xlsx, pptx, and any other skills. Update one, you’d have to update them everywhere.

Mixed concerns. Skills aren’t your content — they’re how Claude Code works. Putting them inside your project folder would blur the line between “stuff I’m working on” and “stuff that makes Claude work”.

Maintenance burden. Adding a second project — say, a separate folder for content drafting — would force you to duplicate every skill into it. The user-level pattern means installing once and using everywhere.

When project-level scope is the right answer

User-level isn’t always right. The rule:

• User-level (~/.claude/skills/) — for skills you want available across every project. The document-creation skills (xlsx, pptx, docx, pdf) almost always belong here.
• Project-level (<project>/.claude/skills/) — for skills that only make sense in the context of one project. A skill that encodes rules unique to your command centre — say, a custom “draft a reply in my voice” skill that depends on your specific voice.md examples — could live in ~/command-centre/.claude/skills/.

The same logic applies to subagents and settings. The full table is in section 04 of the Foundations page.

For most users starting out, everything goes at user level until a specific reason emerges to scope something to a project.

A sanity check after setup

After installing your first user-level skills, this confirms the wiring is correct:

cd ~              # go to home folder (NOT command-centre)
claude

Ask Claude: “What skills do you have available?”

If your installed skills appear in the list, user-level skills are working from anywhere — exactly the expected behaviour.

Then:

cd ~/command-centre
claude

Ask the same question. The skills should still be listed (user-level skills persist regardless of folder), plus Claude should reference your CLAUDE.md content when asked “what do you know about this folder?”

If both checks pass, the two folders are cooperating correctly without being nested.

Common mistakes worth flagging

Putting ~/.claude/ inside your project folder. If you create ~/command-centre/.claude/skills/, those skills are now project-scoped to the command centre only. They won’t be available in other projects. Sometimes this is what you want; usually it isn’t.

Treating skills like project files. Skills get installed once and updated rarely. They’re not part of the day-to-day content you maintain. Don’t include them in your project’s mental model — they’re a layer below.

Forgetting CLAUDE.md is also scoped. A CLAUDE.md at ~/.claude/CLAUDE.md applies across every project. A CLAUDE.md at ~/command-centre/CLAUDE.md applies only when working from that folder. Both load together when you’re in the command centre. Make sure they don’t contradict each other.