Failure modes at scale
What belongs in shared configuration
Shared configuration should carry what a newcomer could not derive from the repository, and nothing else. The scoping is documented precisely enough to follow without guessing.
Claude Code loads instruction files from four scopes: managed policy, user, project and local. The sharing model is explicit per scope. The project file is the one that goes into source control, the local variant holds personal preferences and belongs in the ignore file, and managed policy files cannot be excluded by an individual's settings. All discovered files are concatenated from the filesystem root down rather than overriding one another.1 Anthropic's own include test is narrow: commands the model cannot guess, style rules that differ from defaults, test instructions, repository etiquette, project-specific architectural decisions, and environment quirks. The exclude list is anything derivable by reading the code, standard language conventions, API documentation, and information that changes frequently.2 Instructions that apply to part of the tree belong in rule files with a path glob, so they load only when a matching file is touched.1
Settings are a separate layer with their own precedence, highest first: managed settings, a settings flag, the per-developer local file, the committed project file, then the user file.3 The distinction that matters is enforcement. Blocking tools, commands and paths is enforced by the client and belongs in settings; something that must run at a fixed point, rather than merely be blocked, belongs in a hook instead.1 Code style and behavioural instructions belong in the instruction file, which is delivered as context and carries no guarantee of compliance. For servers, the committed configuration holds endpoints while credentials are referenced through environment variable expansion, and servers needing API keys stay in local scope.4
| Tool | Committed file | Scoping mechanism | Precedence |
|---|---|---|---|
| Claude Code | project instruction file | rule files with a path glob | all files concatenate, root down1 |
| Cursor | versioned project rules | always, by description, by glob, or manual | team rules outrank project and user5 |
| Copilot | repository instructions file | path-specific files with glob frontmatter | personal, then repository, then organization6 |
| AGENTS.md | root file, nested per package | nearest file to the edited file wins | an explicit chat prompt overrides7 |
Two claims here are advice, not findings. The 200-line target, and the claim that longer files reduce adherence, are vendor assertions with no cited study; the only hard limit documented is that a file above four mebibytes is skipped entirely.1 No documentation was found stating that committing an instruction file measurably changes a team's delivery outcomes, as opposed to one engineer's behaviour. The Cursor and Copilot precedence rows were read from pages carrying no version or date stamp, so treat that ordering as observed current behaviour rather than a contract.
参考文献
测验
An instruction that must run at a fixed point in every session, rather than merely be allowed or blocked, belongs where?
- A hook, which executes at that defined point in the flow
- The committed instruction file, since teammates need to see it too
- A personal local file that each developer keeps out of version control
The instruction file is delivered as context with no guarantee of compliance, so anything that must execute at a fixed point needs a hook; settings enforce blocking decisions, but a hook is what runs at that specific point.
This page's guidance is that a rule a newcomer could derive from reading the code belongs in the committed instruction file.
- True
- False
The exclude list places anything derivable from reading the code outside the committed instruction file; only what a newcomer could not derive from the repository belongs there.
评论
还没有评论，来说第一句吧。