Claude Code Configuration & Workflows

The Meridian Platform team writes a line into the checked-in project CLAUDE.md stating that the production migration command must not be run from a Claude Code session and that migrations are applied by the release engineer instead. Over the following 800 sessions the audit log records seven sessions in which the command was run anyway, each time during a debugging task where the schema looked stale. The engineering manager wants that count at zero. Which statement best explains the residual rate?

• AThe rule sits at the wrong scope, and moving the same sentence into the user level memory file would make it binding for every session run on every machine in the team.
• BMemory files are instruction text weighed alongside everything else in the context window, so compliance stays probabilistic; a PreToolUse hook is what refuses the command outright.check_circle Correct
• CThe prohibition holds while plan mode is active and lapses in direct execution, so each of the seven sessions fell outside the window in which project memory is consulted during a task.
• DThe memory file exceeded the length Claude Code reads in one pass, so the prohibition sat past the cut-off point and was simply absent from the context of the seven failing sessions.

Why A is wrong: Scope genuinely changes which sessions load a rule, so this sounds like a real diagnosis. It is wrong twice over: a user level file reaches one machine rather than the team, and moving instruction text between scopes does not change its nature as instruction text.

Why B is correct: Correct. CLAUDE.md influences behaviour rather than gating it, so a small non-compliance rate is the expected outcome; a deterministic requirement needs a mechanism that inspects and blocks the call.

Why C is wrong: Plan mode does change what a session may do before approval, which makes this feel mechanically grounded. It is wrong because project memory is loaded for the session regardless of mode and does not switch off in direct execution.

Why D is wrong: Long memory files really do dilute attention, so a size story is credible. It is wrong as an explanation here because nothing in the evidence points at file length, and the same seven failures would be expected from probabilistic compliance on a short file.

Northwind approves a nine step plan for a schema migration produced in a Claude Code plan mode session. Reviewing the resulting diff, the team finds that two of the planned steps were carried out as one edit and that a configuration file the plan never mentioned was also changed. The team lead had assumed approval bound the rest of the session to the approved text. Which statement correctly describes what approving a plan does?

• AApproval registers the planned steps with the harness, which then refuses any edit to a file the plan did not name, so the change to the configuration file indicates the registration failed.
• BApproval lifts the restriction on writing files and running commands and leaves the plan in the conversation as guidance, so the session can still combine steps or touch a file the plan omitted.check_circle Correct
• CApproval converts the plan into a queue of tool calls that the harness then issues in turn, so two steps arriving as one edit means the queue merged adjacent calls before dispatching them.
• DApproval pins the plan into the context as a standing instruction that the model is prevented from contradicting, so any departure from it points to the plan being evicted by later turns.

Why A is wrong: Tempting because a file allowlist is exactly the enforcement people picture, but approval carries no scope registration; nothing derived a permitted file set from the plan's prose.

Why B is correct: Correct. The approval gate controls tool availability, and the plan afterwards is ordinary context, so deviation remains possible and review of the diff is still required.

Why C is wrong: Tempting because the plan is numbered and looks executable, but it is never compiled into calls; the model decides each subsequent tool call in the ordinary agentic loop.

Why D is wrong: Tempting because the plan does remain in context and does influence what follows, but context is guidance rather than constraint; no mechanism prevents the model from contradicting text it can still see.

The Halyard platform team keeps a skill at .claude/skills/migration-review/SKILL.md holding their 400 line database migration checklist. Its frontmatter description reads, in full, "Halyard internal review helper". The file is committed and present in every clone, yet engineers report that Claude Code applies the checklist during migration work only when they name the skill themselves. Which mechanism explains that behaviour?

• AThe skill body exceeds the size the harness will hold at startup, so the checklist is truncated well before the model can apply any part of it.
• BOnly the skill name and description are loaded up front, so a description that does not describe the triggering situation leaves the model nothing to match a migration request against.check_circle Correct
• CSkills placed under the project directory stay inert until they are registered by name in the project CLAUDE.md, which this team has not done.
• DSkills are invoked when the user types their name, so no amount of description text can cause the model to select one on its own initiative.

Why A is wrong: Tempting because long instruction files do compete for context, but 400 lines sits well within what a skill body can carry, and truncation would degrade the checklist rather than stop it being selected at all.

Why B is correct: Correct: the description is the sole selection surface at the point the model decides whether a skill is relevant, and this one names the team rather than the work, so nothing in a migration request matches it.

Why C is wrong: Tempting because CLAUDE.md is the file teams reach for when they want project behaviour picked up, but a skill is discovered from its own directory and needs no registration entry to be available.

Why D is wrong: Tempting because the observed workaround is exactly that the engineers name the skill, but skills are model invoked by design, and a description that described the situation would be selected without being named.

Beacon Platform scopes a test-naming rule with the pattern packages/*/src/*.test.ts. Within one session, reviewers find the rule clearly applied to packages/engine/src/scoring.test.ts and entirely absent for packages/engine/src/scoring/edge-cases.test.ts, which was edited a few minutes later. What explains the difference between the two files?

• ABoth files matched the pattern, but rule activation is evaluated once per session against the first matching file touched, so the later edit reused a context that had already been fixed.
• BTest files nested inside a source subdirectory are excluded by default, since path scoping skips directories that are not declared in the workspace configuration for that package.
• CA single star matches within one path segment, so the nested test file is not matched and the rule stays unloaded for it; a pattern using a double star for the trailing part would cover both files.check_circle Correct
• DBoth files matched the pattern and the nested one was skipped because its name carries two dots, which the matcher reads as a compound extension falling outside the declared suffix.

Why A is wrong: Tempting because activation does happen during the session, but it is evaluated per matching path rather than latched to whichever file was touched first.

Why B is wrong: Plausible in a monorepo full of workspace declarations, but glob matching operates on the literal path and consults no workspace configuration.

Why C is correct: Correct: segment-limited matching is exactly what separates the two paths, and widening the trailing portion of the pattern brings nested files back into scope.

Why D is wrong: Tempting because the dotted test suffix looks like a parsing edge case, but the matched file carries the same double-dotted suffix and was covered without difficulty.

On the Cartwright billing repository, engineers reply to review comments with decisions such as accepting a documented risk, and expect the following pipeline run to honour them. Instead the same finding returns on the next push in 8 of 10 sampled pull requests. Each run starts a fresh non-interactive session on a new ephemeral runner. Which two changes most effectively address this? Select TWO.

• ARaise the context window available to the review session, since the accepted decisions are long discussions and the session is dropping the oldest part of that conversation.
• BRead the reply threads from the pull request in the pipeline and pass the accepted decisions into the prompt as explicit context for the run that is about to start.check_circle Correct
• CDispatch the review through a subagent with the Task tool, so a coordinator holds the accumulated history of the repository and the subagent inherits it on each run.
• DInstruct the model in the prompt to check whether a human has already responded to a finding before raising that finding a second time on the same pull request.
• ERecord accepted risks in a file committed to the repository, so each decision travels with the code and is available to any later session that reads the working tree.check_circle Correct

Why A is wrong: Tempting because context limits do cause forgetting, but a fresh session never held those discussions at all, so a larger window only adds room for material that was never loaded.

Why B is correct: Correct. The decisions live in the pull request rather than in any session, so fetching them and putting them in the prompt is what makes them visible to the run.

Why C is wrong: It rests on a false assumption, because a subagent receives only the prompt it is dispatched with rather than the coordinator's conversation, and no coordinator persists between pipeline runs.

Why D is wrong: The instruction reads as sensible but is unactionable, because the session has no access to the reply threads and is told to consult evidence that is absent from its context.

Why E is correct: Correct. Committing the decision moves it out of ephemeral session state and into the repository, where every future run can read it, and it survives runner and branch changes.