Configure Claude Code for a Team Development Workflow

Why it matters

A team’s Claude Code behavior is only as consistent as the configuration everyone loads. This exercise has you build each layer of it and prove where each one applies.

What to practise

Build a project CLAUDE.md, .claude/rules/ files scoped by paths globs, a project skill with context: fork and allowed-tools, and a shared MCP server in .mcp.json that reads its credential from an environment variable beside a personal one in ~/.claude.json. The point is observation: confirm that a rule loads only for matching files, that the forked skill leaves the main conversation clean, and that both MCP servers are available at once. Then run tasks of different sizes with and without plan mode, and note where planning paid off.

How it fits

The shared files are the release unit of 7.1.1; check that they work together on a clean clone. The project and personal MCP split is 7.1.2’s scope ownership, and the environment-variable credential is 7.1.3’s credential reference, which keeps the secret out of the repository but not out of the process environment. The exercise calls the skill’s allowed-tools a restriction; 7.1.3 treats it as a pre-approval rather than an exclusive tool list, so check which other tools stay available while the skill runs. The plan-mode comparison is 7.2.2: plan where uncertainty is consequential, such as a migration or a feature with several valid designs, and stay direct for a single-file fix. The exercise is the Foundations guide’s; the Professional guide has none.