Configure Claude Code for a Team Development Workflow

Why it matters

Domain 3 is mostly about where configuration lives and who receives it. This exercise sets up every layer in one repository, so you see each placement decision take effect.

What to practise

Build a multi-developer project whose standards live in a project-level CLAUDE.md, whose API and test conventions live in .claude/rules/ files scoped by paths globs, and whose shared skill runs with context: fork. Add a team MCP server in .mcp.json that reads its credentials through environment variable expansion, and a personal one in ~/.claude.json, and confirm that both are available in one session. Then give Claude a one-file fix, a multi-file migration and an open-ended feature, with and without plan mode. Watch which instructions load for which file, whether the forked skill leaves the main conversation clean, and on which task plan mode earns its extra step.

How it fits

For 3.1, project scope is 3.1.1; when an instruction seems not to load, diagnose it as 3.1.4 does. For 3.3, check your globs against 3.3.1 and 3.3.2. For 3.2, the forked skill is 3.2.4; the exercise speaks of allowed-tools restrictions, but 3.2.5 shows that allowed-tools only pre-approves tools, and disallowed-tools is what removes them. For 2.4, the two servers are the scopes of 2.4.1 and the ${VAR} expansion of 2.4.2. For 3.4, judge the three tasks by the signals of 3.4.1.