Developer Productivity & Operational Enablement

The distinction that matters for a team is what is shared and checked in versus what is personal to one machine.

Project configuration lives in the repository and is committed: a CLAUDE.md at the project root carrying conventions, architecture notes, and rules that apply to everyone; a .claude/ directory holding project-scoped settings, and, depending on what your team uses, skills, subagents, and hooks. Because it is checked in, it is reviewed like code and changes are visible.

Personal configuration is per-user and stays out of the repository: local settings overrides, machine-specific paths, individual preferences. The practical rule is to gitignore the local settings file so one developer's machine-specific choices do not land on everyone else.

Three things are worth getting right when standing this up for a team:

Write CLAUDE.md for the non-obvious. Conventions that a reader could infer from the code are wasted space. What earns its place is the constraint that is invisible in the code: the invariant that must hold, the API that looks safe but isn't, the migration that must be forward-only.

Set permission boundaries deliberately. What may run without asking, and what must always prompt. This is the same least-privilege reasoning as tool design in Domain 3, applied to a developer's local environment.

Hooks are the mechanism for anything that must happen every time. An instruction in a prompt is a preference; a hook is executed by the harness. If a formatter must run after every edit, or a check must gate every commit, that is a hook, not a line in CLAUDE.md asking nicely.

The tasks where AI assistance pays off most reliably share a property: the output is verifiable. Test generation, mechanical refactors, migration across many similar files, documentation from existing code, and first-pass code review all have a way to check the result. Work with no verification path carries the risk forward into production.

Two failure modes to design against:

Volume without review. Generating more code than the team can meaningfully review converts a throughput gain into a review bottleneck and, eventually, into unreviewed code in production. The constraint on how much you should generate is how much can actually be checked.

Skipped understanding. Code nobody on the team understands is a liability the moment it breaks, regardless of who or what wrote it. The reviewer needs to understand the change, not just observe that the tests pass.

For operational debugging, the useful pattern is giving the model access to the evidence (logs, traces, the failing test, the relevant source) rather than describing the symptom and asking for a guess. The same discipline from Domain 4 applies: localize the fault before changing anything, and be skeptical of a diagnosis that arrives without the observation that supports it.

One caution that generalizes beyond Claude Code: an assistant that reports a fix is not the same as a verified fix. Intermittent failures in particular need repeated runs before "fixed" means anything, a single clean run on a flaky test is not evidence.