← 10.611.1 →
1255 words Slides

10.7 Sharing Configurations Across Projects

Course: Claude Code - Power User Section: Customizing Claude Code Video Length: 2-5 minutes Presenter: Daniel Treasure

Opening Hook

You built the perfect setup. Custom commands that save your team hours. Agents that specialize in code review and security. Standards in CLAUDE.md that keep everyone aligned. Now you've got a second project. Do you rebuild all this? No. You share it. Let's see how configurations cascade across projects and teams.

Key Talking Points

1. Three Levels of Configuration

  • User-level (~/.claude/): Your personal setup, applies to every project you work on
  • Project-level (.claude/): Team standards, checked into git, shared with everyone on the project
  • Local-level (.claude/local/): Personal overrides per project, gitignored (don't share) What to say: "Your preferences follow you everywhere. Your team's standards travel with the code. Your personal tweaks stay on your machine. Three layers, clean separation." What to show on screen: File browser showing all three locations. Highlight what's in each.

2. User-Level Configuration: Personal Everywhere

  • ~/.claude/settings.json: your output style, model preference, terminal setup
  • ~/.claude/skills/: custom commands you've built (available in all projects)
  • ~/.claude/agents/: subagents you've created (available globally)
  • ~/.claude/permissions.json: your default permission profile What to say: "If you love Opus and vim and concise output, set it once in ~/.claude/ and never think about it again. Every project inherits your preferences." What to show on screen: ~/.claude/ directory structure. Open ~/.claude/settings.json. Show how changes apply globally.

3. Project-Level Configuration: Team Standards

  • .claude/settings.json: team-wide output style, model, attribution
  • .claude/CLAUDE.md: architecture, coding standards, testing rules
  • .claude/skills/: team custom commands
  • .claude/agents/: team subagents
  • .claude/permissions.json: role-based permissions for the project What to say: "When you clone a project, you get the team's Claude setup automatically. New developer on day one has the same Claude configuration as the senior engineer." What to show on screen: .claude/ directory in a project. Show .claude/settings.json and .claude/CLAUDE.md. Demonstrate: clone repo, run claude, see it using team settings.

4. Local Configuration: Personal Overrides (Gitignored)

  • .claude/local/settings.json: your personal overrides (not committed)
  • .claude/settings.local.json: alternative local file (gitignored)
  • Useful for: development machine specifics, personal preferences, debugging What to say: "Sometimes you want to experiment. Use .claude/local/ for personal tweaks without affecting your team's shared setup." What to show on screen: .gitignore showing .claude/local/ excluded. Show how to create local overrides.

5. Configuration Cascade and Precedence

  • Precedence (highest to lowest):
  • Local overrides (.claude/local/settings.json)
  • Project settings (.claude/settings.json)
  • User settings (~/.claude/settings.json)
  • Built-in defaults
  • Later settings override earlier ones
  • Non-conflicting settings merge (e.g., user skills + project skills) What to say: "Settings cascade. Your project can say 'we use Opus' but you can locally override to 'I'm using Haiku today for speed'. Later wins." What to show on screen: Show a conflict scenario. Set outputStyle to "concise" in user, "detailed" in project, see project win. Show how to merge skills from both.

6. Sharing Across Team and Organization

  • Commit .claude/ to git—everyone gets it
  • Use standard project structure so all repos look alike
  • Create a template repo with your complete setup
  • Use symlinks or git submodules for shared agent definitions
  • Document what's in each file in CLAUDE.md What to say: "Your team's best practices are too valuable to keep in one project. Codify them, share them, reuse them." What to show on screen: A template repo with optimized .claude/ setup. Show cloning it and reusing the configuration.

Demo Plan

  1. Show three config locations:
  2. ~/.claude/ (user)
  3. .claude/ (project)
  4. .claude/local/ (local, gitignored)
  5. Open a project and trace settings resolution:
  6. cat ~/.claude/settings.json
  7. cat .claude/settings.json
  8. Show which one wins (project)
  9. Create a local override and show it takes precedence
  10. Clone a second project and show it immediately inherits user settings
  11. Create a template repo with complete .claude/ setup
  12. Share a skill from user to project and show both available

Code Examples & Commands

Check where settings come from:

cat ~/.claude/settings.json

cat .claude/settings.json

cat .claude/settings.local.json

Precedence example:

# ~/.claude/settings.json (user)
# model: claude-opus-4-6
# outputStyle: detailed

# .claude/settings.json (project)
# outputStyle: concise

# Result: model=opus (from user), outputStyle=concise (from project)

Create a local override:

mkdir -p .claude/local

cat > .claude/settings.local.json << 'EOF'
{
  "model": "claude-haiku-4-5",
  "debug": true
}
EOF

# This overrides both user and project settings locally (not committed)

.gitignore for Claude Code:

.claude/settings.local.json
.claude/local/
.claude/agent-memory-local/
.claude/sessions/
.claude/.env.local

Listing all available configs:

# User skills
ls ~/.claude/skills/

# Project skills (override/supplement user)
ls .claude/skills/

# Effective skill set: user + project (project takes precedence)

Template repo structure:

claude-code-template/
├── .claude/
│   ├── settings.json (team output style, model)
│   ├── CLAUDE.md (architecture, standards)
│   ├── permissions.json (role-based access)
│   ├── skills/
│   │   ├── commit/
│   │   ├── review/
│   │   └── test/
│   └── agents/
│       ├── code-reviewer/
│       ├── security-auditor/
│       └── style-enforcer/
├── .gitignore (excludes .claude/local, sessions, etc.)
└── README.md (explains Claude Code setup)

Share a user skill to project:

cp -r ~/.claude/skills/commit .claude/skills/

git add .claude/skills/commit
git commit -m "chore: add team commit-summary skill"

Environment variable overrides:

export CLAUDE_CONFIG_DIR=~/.claude/work
claude chat "Hello"

export CLAUDE_CONFIG_LOCAL=.claude/settings.local.json
claude chat "Hello"

Create a shared agents directory:

mkdir -p .claude/agents/shared

cat > .claude/agents/shared/code-reviewer/AGENT.md << 'AGENT_EOF'
---
name: code-reviewer
description: "Team code reviewer"
tools: ["read"]
model: "claude-opus-4-6"
---

Code Reviewer

Team code reviewer agent
AGENT_EOF

git add .claude/agents/shared/
git commit -m "feat: add shared code-reviewer agent"

Gotchas & Tips

Gotcha: If you forget to gitignore .claude/local/, local secrets might leak. Use the template .gitignore above.

Tip: Document your team's .claude/ setup in the project README or CLAUDE.md so new developers understand what's there.

Gotcha: If user and project both define the same skill, project wins. Document this in CLAUDE.md to avoid confusion.

Tip: Use template repos. Create one perfect .claude/ setup, use it as a template for all new projects. Saves repetition.

Tip: Update shared configs regularly. If you discover a better skill or agent, update it in the project so the whole team benefits.

Gotcha: Symlinks to ~/.claude/ might not work across different machines or CI environments. Use copies for portability.

Tip: Version your skills and agents. If you refactor a skill significantly, consider creating a v2 until the old one is unused.

Lead-out

You've built a complete customization system. From personal preferences to team standards, from custom commands to specialized agents, and now configurations that travel with your code. Claude Code now works the way your team works, not the other way around. You're a power user.

Reference URLs

  • Configuration file locations and precedence
  • .claude/ directory specification
  • .gitignore template for Claude Code
  • Sharing configurations across projects
  • Environment variables for config overrides

Prep Reading

  • What configuration would you like every project you touch to have?
  • What's unique to your current team that shouldn't be shared across org?
  • How would you organize shared configs if your org had 50 projects?

Notes for Daniel: This is the capstone of customization. Emphasize how configurations follow people and teams, not just projects. Show a real scenario: engineer joins team, clones repo, runs claude, and immediately has the team's setup without manual configuration. That's the power. Wrap up the section by celebrating how much Claude has been customized to match human workflows, not the reverse.