Lesson 7.2
Shared Configuration, Skills and Plugins
How Claude Code configuration layers combine, what belongs in CLAUDE.md, settings, hooks, subagents, skills and plugins, and how to distribute and govern them so teams get consistent behaviour without central bottlenecks.
Claude Code behaves according to a stack of configuration that comes from the organisation, the user and the project. Getting consistent, safe behaviour across many teams means knowing what each layer is for, putting shared knowledge where it will be found, and packaging reusable capability so it spreads without every team reinventing it. The exam expects you to know the layers and to make sound placement decisions.
The settings hierarchy
| Layer | Location | Scope | Typical content |
|---|---|---|---|
| Managed (enterprise) | System path deployed by device management | All users on the machine; highest precedence | Deny rules, MCP allowlists, telemetry, login constraints |
| Command line | Flags on invocation | One session | Permission mode, allowed tools, model for headless runs |
| Local project | .claude/settings.local.json (not committed) | One user, one repository | Personal allow rules, local experiments |
| Shared project | .claude/settings.json (committed) | Everyone on the repository | Team allow and deny rules, hooks, environment |
| User | ~/.claude/settings.json | One user, all repositories | Preferences, personal tools |
Precedence runs from managed down to user. Permission rules take three forms: allow, ask and deny, matched against tool names and arguments (for example a shell command prefix or a file path pattern). Deny rules in managed settings cannot be overridden below.
CLAUDE.md: context, not configuration
CLAUDE.md files give the model project knowledge: how to build and test, conventions, architecture pointers, what not to touch. They also layer: an organisation-level file, the user's own file, the project file at the repository root (or under .claude/), a local uncommitted variant for personal notes, and modular rule files that keep the main file short. Content can import other files by reference.
Good CLAUDE.md content is short, specific and verifiable: commands, conventions, pointers to deeper docs. Bad content is a wall of prose, duplicated documentation, or rules that belong in settings or hooks. If an instruction must be enforced, enforce it with a hook or a permission rule; CLAUDE.md is guidance the model follows well but not a control.
Hooks: deterministic enforcement
Hooks run shell commands at lifecycle events such as before and after tool use, on prompt submission, on stop and at session start. They can block an action, inject context, or log. Shared project hooks are committed; organisation-wide hooks can be set in managed settings. Typical uses: run a formatter after edits, block commits to protected branches, redact secrets in tool output, record tool usage to a central log. Because hooks are code, they are the right home for anything that must happen every time.
Subagents, skills and commands
- Subagents are specialised assistants with their own prompt, tool access and optionally model, defined as markdown files in the project or user agents directory. Use them for repeatable roles such as a reviewer, a test writer or a security checker, and for context isolation on large explorations.
- Skills package instructions and supporting files for a task, defined by a
SKILL.mdwith metadata the model sees at all times and a body it loads only when relevant. They are the main vehicle for reusable organisational know-how: how we write migrations, how we produce a release note, how we query the data warehouse. - Slash commands are prompt shortcuts stored as markdown; many have been superseded by skills but remain useful for simple, frequent prompts.
Placement rule: knowledge the model should always have goes in CLAUDE.md; knowledge it should load on demand goes in a skill; a persona with distinct permissions is a subagent; something that must be enforced is a hook or a rule.
MCP servers in projects
Project-scoped MCP server definitions can be committed so that every engineer on the repository gets the same connectors, subject to approval on first use and to the organisation's allowlist. Keep credentials out of the committed file; reference environment variables or use OAuth. User-scoped servers serve personal tools.
Plugins and marketplaces
A plugin bundles commands, skills, subagents, hooks and MCP server definitions into one installable unit with a manifest. Marketplaces are catalogues, typically git repositories, from which plugins are installed and updated. For an organisation this is the distribution mechanism: a platform team maintains an internal marketplace of reviewed plugins (the standard security reviewer, the data-platform skill set, the compliance hooks), teams install what they need, and managed settings can pre-register the marketplace and enable required plugins.
Treat plugins like any dependency: review before publishing, version them, test skills against realistic tasks, and have a deprecation path.
Governance of shared configuration
- Shared project settings, hooks, CLAUDE.md and
.mcp.jsonchange through pull requests with review. - A platform team owns managed settings and the internal marketplace, with a request process for additions.
- Audit periodically: allow rules that have crept too wide, hooks that have been disabled locally, stale skills.
- Keep a short written standard for what belongs in each layer so that teams place things consistently.
Anti-patterns
- A thousand-line CLAUDE.md that nobody reads and the model cannot prioritise.
- Enforcing security through CLAUDE.md prose instead of deny rules and hooks.
- Credentials in committed MCP configuration.
- Each team maintaining its own copy of the same skill with drift between them.
- Managed settings so restrictive that engineers work around the tool entirely.
Exam focus
- Know the five settings layers and their precedence: managed, command line, local project, shared project, user; deny rules at the managed layer cannot be overridden.
- CLAUDE.md is layered project context, kept short and specific; it guides but does not enforce.
- Hooks are the deterministic enforcement mechanism; permission rules constrain tools by name and argument pattern.
- Subagents are personas with their own tools; skills are on-demand packaged know-how; commands are prompt shortcuts.
- Plugins bundle these artefacts and are distributed through marketplaces, ideally an internal reviewed one that managed settings can pre-register.
- Shared configuration changes through pull requests; credentials never live in committed configuration.
Check yourself
5 questions
1.A security engineer adds a rule to the organisation's managed Claude Code settings denying a dangerous command pattern. A developer then adds an allow rule for the same pattern in their user settings and another in the project's settings. What is the resulting behaviour?
2.A platform team wants to share three kinds of reusable assets across repositories: a detailed procedure for performing database migrations safely, a specialised reviewer persona with a restricted tool set that runs in its own context, and a quick shortcut to generate a release note from recent commits. Which mapping to Claude Code extension mechanisms is MOST appropriate?
3.An organisation has grown to forty repositories, each copying the same skills, subagents and hooks by hand, and they drift out of sync. Which approach BEST solves distribution and consistency?
4.A repository's committed Claude Code project settings file contains an engineer's personal preferences and an environment variable holding an API token for an internal service. Which guidance is CORRECT?
5.A team wants every file edit made by Claude Code in their repository to be formatted and linted automatically, and wants a record of which tests were run before the agent reports completion, regardless of which engineer is using it. Which mechanism and scope is MOST appropriate?