Privacy Notice: When you sign in with GitHub, your quiz attempts are stored in Google Firebase so you can track your progress. This data is only accessible to the course instructor, is not otherwise shared, and will be deleted at the end of the semester. For earlier deletion, contact the instructor. Prefer to stay anonymous? Use guest mode or a GitHub account without your real name.
Loading...
Sign in to track your progress and see your results across devices.
●Progress is being saved
07 Orchestration Placement Diagnosis: 6 Cards
Score:0 / 18
Question Overview
PendingCorrectIncorrectSubmitted
Goal
In this quiz you treat six recurring needs in an AI-assisted development workflow as objects of study. For each need you decide where in the orchestration layer it belongs and why, then predict the cost of the tempting wrong placement — in context-budget and attention terms. This is a routing exercise, not a lab: it cites budget reasoning only as justification. By the end you will:
Route a recurring need to the right orchestration mechanism — root CLAUDE.md, a subdirectory CLAUDE.md, a skill, memory, a tool/MCP server, a hook/CI gate, or out-of-scope;
Reason about placement as a shared, finite context window (§10.1): the window has a fixed size, so every token an always-on block occupies is a token (and a slice of cost and latency) not available to the task — treat “budget” as window occupancy and cost, not as a single pool of attention split evenly among tokens (attention is normalised per head and per position and concentrates on what the model has learned to weigh, so this budget metaphor is a planning heuristic, not a literal attention law);
Predict the concrete failure of a mis-placement — wasted window cost, lost-in-the-middle, never-loaded-so-absent, probable-not-guaranteed, stale memory, or widened blast radius.
Learning objectives
After working through this quiz, you should be able to:
Place a recurring need at the right point in the orchestration layer, and justify the choice on a named axis.
Distinguish the four kinds of need — influence, enforcement, capability, human — and recognise that a placement decision sits inside a kind, not instead of it.
Reason in budget terms about always-on standing charges vs. on-demand vs. free, treating the window as one finite, shared resource (occupancy and cost) — every always-on token is window the task does not get, which is true regardless of how attention itself distributes.
Predict the cost of a wrong placement mechanistically: which failure mode it triggers and why.
Reject the sterner CLAUDE.md reflex — recognising that more or louder influence never substitutes for enforcement, a capability, or a better placement.
Answer “it depends” responsibly — by naming the deciding condition, never leaving it bare.
The three-layer model is the first cut. L6 gave you influence / enforcement / human. L7 lets you derive every property of those layers — and adds a fourth kind of need, capability: the system actually touching the world, which only a tool can do.
A skill is a codified L6 pattern. The L6 few-shot example you used to retype becomes a versioned artifact on disk (§7.1). Placement is the next station of L6’s “structure, promoted from habit to artifact.”
“Wrong tool for the job” becomes “wrong placement.” L6’s anti-pattern — using prompting where the task needed enforcement or a tool — generalises here to using the wrong orchestration mechanism: putting a one-task rule in always-on root, prompting a capability that only a tool can grant, or wording a CLAUDE.md sterner when the task needs a hook.
Placement menu reference sheet
Use this as your cheat sheet. The right-hand column is the single question that routes most needs.
Mechanism
What it is
Cost profile
Decide this when…
Root CLAUDE.md / AGENTS.md
Always-on instruction file, loaded at session start (§4.1)
Always-on standing charge in every session
The need is genuinely always-on — relevant to (nearly) every session
Subdirectory CLAUDE.md
On-demand instruction file, spliced when a tool reads that subtree (§4.2)
On-demand: paid only by sessions that touch the subtree
The need is subtree-only — scoped to one directory
A Skill
A codified prompting pattern, injected at invocation near the query (§7)
Free until triggered, then on-demand at the recency-advantaged position
The need is one-task-type — a recurring pattern for one kind of task
Free in context-budget terms — runs outside the window
The need must be guaranteed, not merely made likely
Out-of-scope
Leave it off the always-loaded set entirely
Free
The need is rarely needed and cheap to supply ad hoc when it arises
A subagent / workflow(stretch / emerging)
Skills that invoke skills; phase-by-phase context loading (§7.3)
On-demand, per phase
The need is a multi-phase task whose phases each want different context — emerging, treat as stretch
A dating caveat. The mechanism names and paths above are mid-2026 Claude Code specifics; .claude/skills/, MEMORY.md, and the exact loader rules will date. The concepts — always-on vs. on-demand, influence vs. enforcement vs. capability, one shared budget — transfer to every orchestration layer.
A note on judgment vs determinate facts
This is the L7 analogue of the L6 deck’s “anti-pattern” note, and it matters just as much here. The two graded questions per card ask only what the lecture’s rules make determinate. The correct home of each need, and the kind of need it is, follow from the axes the lecture establishes — that is why they can be graded.
The genuinely contestable material — how often is “frequent enough” to amortise an MCP server’s standing charge, exactly which secondary mechanism is second-best, how to weigh a borderline cost trade-off — lives in the ungraded reflection. There you write your reasoning in prose and compare it to a model answer; nothing is scored. If you find yourself disagreeing with a graded key, you have probably found a card where the placement is genuinely close (Cards 3 and 5 have defensible runners-up) — note it, and bring it to the debrief. The reflection is where the real learning happens.
How the quiz is structured
Each of the 6 cards produces three questions:
Placement (single-select, graded). Where does this need primarily belong? One correct home; the menu mixes in the tempting wrong home and a few plausible others.
Need (multi-select, graded). What kind of need is it — influence, enforcement, capability, human? The same five options appear every time, and the fifth — “best solved by a sterner / better-worded CLAUDE.md” — is a decoy that is never correct. Card 6 is deliberately a split (two creditable boxes).
Reflection (free-text, ungraded). Name the deciding axis, work the cost ledger, identify the tempting wrong placement and its concrete cost, and write the one-sentence final placement. After you click submit, a model answer reveals for each field; your text stays in your browser (localStorage) only.
That means 18 questions total: 12 graded (6 placement + 6 need) + 6 ungraded reflections. The score on the progress bar reflects the 12 graded questions only.
Where to go for the group-workshop format
This page is the interactive self-study version. To run the same six cards as a group workshop in class — with the warm-up example, student worksheet, full instructor keys (including a “draft the artifact” model answer for each card), group activity options, rubric, grading scale, and debrief questions — use the companion exercise page.
Final takeaway. Placement is context engineering. The window is finite, so a token an always-on block occupies is a token of window (and a slice of cost) the task does not get.
Question1
Card 1 — placement
Card 1: The always-on rule that is really a one-task rule
A 25-line quiz-formatting block — the <details markdown="1"> rule, the two-trailing-spaces rule, the quiz front-matter rules — currently lives in this repo’s root CLAUDE.md. It is therefore loaded into every session, including the hundreds of lecture-writing and slide-building sessions that never touch a quiz. You want the block to be reliably present whenever someone authors a quiz, without charging its tokens to every other conversation. (This repo has no .claude/skills/ directory yet — this would be a genuine first extraction.)
Where does this need primarily belong?
✓Correct!
Correct home: a Skill. The deciding axis is frequency — always-on vs. on-demand — together with in-window position.
A skill is context on demand (§7): zero tokens until it is triggered, and when it loads it lands near the current query, in the recency-advantaged region — not adrift in the middle of a long session. The rule is needed only when authoring a quiz, which is exactly the “one kind of task” signature the lecture names: “anything in your CLAUDE.md that is only relevant to one kind of task is a skill waiting to be extracted.”
Tempting wrong home: root CLAUDE.md — where it lives today. That charges 25 lines to every conversation, the 90%+ that never author a quiz included (window, cost, and latency spent for nothing in those sessions), and because root files load at the top, the block can drift toward the lost-in-the-middle zone as a long quiz-authoring session grows — a model- and format-dependent tendency, so it may be attended to less just when you need it most.
Acceptable secondary: a _quizzes/CLAUDE.md subdirectory file would at least make the cost on-demand (paid only when a tool reads under _quizzes/). But a skill is the better fit because the trigger is the task (“author a quiz”), not “a tool happened to read a quiz file” — and a skill lands beside the query, not at a mid-sequence splice point.
Bridge from Lecture 6. A skill is the L6 few-shot example, promoted from a retyped habit to a versioned artifact (§7.1).
✗Not quite.
Hint 1
Start with frequency: how often is this 25-line block actually relevant — every session, only when authoring a quiz, or rarely? That answer narrows the menu before you pick a mechanism.
Hint 2
The deck’s own rule: anything in your CLAUDE.md that is only relevant to one kind of task is a skill waiting to be extracted. Which candidate home costs zero tokens until that one task type begins, and then lands near the query?
💡Solution
Correct home: a Skill. The deciding axis is frequency — always-on vs. on-demand — together with in-window position.
A skill is context on demand (§7): zero tokens until it is triggered, and when it loads it lands near the current query, in the recency-advantaged region — not adrift in the middle of a long session. The rule is needed only when authoring a quiz, which is exactly the “one kind of task” signature the lecture names: “anything in your CLAUDE.md that is only relevant to one kind of task is a skill waiting to be extracted.”
Tempting wrong home: root CLAUDE.md — where it lives today. That charges 25 lines to every conversation, the 90%+ that never author a quiz included (window, cost, and latency spent for nothing in those sessions), and because root files load at the top, the block can drift toward the lost-in-the-middle zone as a long quiz-authoring session grows — a model- and format-dependent tendency, so it may be attended to less just when you need it most.
Acceptable secondary: a _quizzes/CLAUDE.md subdirectory file would at least make the cost on-demand (paid only when a tool reads under _quizzes/). But a skill is the better fit because the trigger is the task (“author a quiz”), not “a tool happened to read a quiz file” — and a skill lands beside the query, not at a mid-sequence splice point.
Bridge from Lecture 6. A skill is the L6 few-shot example, promoted from a retyped habit to a versioned artifact (§7.1).
Question2
Card 1 — need
Card 1 — what kind of need is this?
Setting placement aside, classify the underlying need the quiz-formatting block serves. Select all that apply.
Select all that apply:
✓Correct!
Influence only. The block is text that, once in the window, biases the model toward the right output shape — exactly the influence-layer material the completed three-layer model defines: anything that enters the token sequence is influence-layer material. A skill is still influence; the only question this card asks is where and when that influence is injected, not which layer it belongs to.
It is not enforcement — nothing here is a deterministic guarantee (you could add one later, e.g. a build check that fails on a malformed quiz, but that is a different need). It is not capability — no tool has to touch the world. And the sterner CLAUDE.md option is the decoy: a sterner file does not solve a placement problem; the block is already worded fine, it is simply in the wrong place at the wrong cost.
✗Not quite.
Hint 1
Ask the layer question first: is the goal to bias the model toward the right output shape, to guarantee an outcome, or to touch the world? Only one applies to a block of formatting text.
Hint 2
The deck’s rule: anything that enters the token sequence is influence-layer material — a skill is still influence. And remember the fifth option is a decoy: a sterner file never fixes a problem that is really about where and when text is injected.
💡Solution
Influence only. The block is text that, once in the window, biases the model toward the right output shape — exactly the influence-layer material the completed three-layer model defines: anything that enters the token sequence is influence-layer material. A skill is still influence; the only question this card asks is where and when that influence is injected, not which layer it belongs to.
It is not enforcement — nothing here is a deterministic guarantee (you could add one later, e.g. a build check that fails on a malformed quiz, but that is a different need). It is not capability — no tool has to touch the world. And the sterner CLAUDE.md option is the decoy: a sterner file does not solve a placement problem; the block is already worded fine, it is simply in the wrong place at the wrong cost.
Question3
Card 1 — reflection
Card 1 reflection — quiz-formatting block
Write out your full placement reasoning in plain prose. There is no automatic grading — after you submit, the reference answer for each field reveals so you can compare.
Write your answer in each field. After you submit, the reference answer reveals. (No automatic grading; your text stays in your browser only.)
☰Reference answer
Frequency: always-on vs. on-demand (reinforced by in-window position). The rule is needed only when authoring a quiz — a one-task-type need — so it should load on demand and land near the query, not be paid in every session and drift into the middle.
☰Reference answer
Root CLAUDE.md = an always-on standing charge: 25 lines paid in every conversation, whether or not it authors a quiz, competing for the same finite window as the actual work.
Subdirectory _quizzes/CLAUDE.md = on-demand: paid only by sessions whose tools read under _quizzes/.
Skill = free until triggered, then on-demand at the query position.
The window is finite, so a token an always-on block occupies is a token of window (and a slice of cost and latency) the task does not get — one shared window, not separate pools (§10.1).
☰Reference answer
Leaving it in root CLAUDE.md (where it already is). Cost: it occupies window in every session — 25 always-on lines paid in 90%+ of sessions that never author a quiz (tokens, cost, and latency for nothing), plus a lost-in-the-middle tendency: loaded at the top, the block can be attended to less as the long quiz-authoring session grows, so it may be weakest at the moment it is needed most — a tendency that depends on the model and formatting, not a guaranteed proportional fade.
☰Reference answer
This belongs in a skill (.claude/skills/quiz-format/SKILL.md) because it is a one-task-type need that should cost zero until triggered and land beside the query, and keeping it in root CLAUDE.md would tax every non-quiz session and risk pushing the rule into the lost-in-the-middle zone (a model- and format-dependent tendency) just when a quiz session needs it.
✓Correct!
✗Not quite.
💡Solution
Question4
Card 2 — placement
Card 2: “Always run add-anchors before committing a lecture”
Lecture anchors must be regenerated by scripts/add_anchors.py whenever headings change, and the CI job check-anchors.ymlalready fails the PR if the committed anchors are stale. A teammate, tired of CI failures, proposes adding a strongly-worded paragraph to root CLAUDE.md: “ALWAYS run uv run add-anchors after editing a lecture. NEVER commit stale anchors.”
Where does this need primarily belong?
✓Correct!
Correct home: a hook / CI check — and the good news is it already exists (check-anchors.yml). The deciding axis is influence vs. enforcement — likely vs. guaranteed.
“Stale anchors must never be committed” is a property you want guaranteed, and only the enforcement layer can guarantee it. A deterministic check that fails the commit (or the PR) truncates the bad outcome; an instruction can only make it less probable (§11.2: a better influence layer narrows the distribution; only the enforcement layer truncates it).
Tempting wrong home: a sterner CLAUDE.md paragraph. That is influence wearing the mask of enforcement. It works most of the time and fails precisely when the session is long and the accumulated tokens outvote the rule — intermittent compliance is softmax arithmetic over a sequence, not defiance (§6.2). Worse, it spends always-on tokens to do — unreliably — a job a free deterministic check already does for certain.
Bridge from Lecture 6. This completes L6’s “prompting cannot fix this — it needs enforcement”: now the hook has a street address, at the commit interface (§9.3).
✗Not quite.
Hint 1
Think on the influence-vs-enforcement axis: do you want “never commit stale anchors” to be merely likely, or guaranteed? Note the deterministic check (check-anchors.yml) already exists and is free.
Hint 2
The deck’s rule: a better influence layer narrows the distribution; only the enforcement layer truncates it. A sterner CLAUDE.md paragraph is influence wearing the mask of enforcement — which layer actually makes the bad outcome impossible?
💡Solution
Correct home: a hook / CI check — and the good news is it already exists (check-anchors.yml). The deciding axis is influence vs. enforcement — likely vs. guaranteed.
“Stale anchors must never be committed” is a property you want guaranteed, and only the enforcement layer can guarantee it. A deterministic check that fails the commit (or the PR) truncates the bad outcome; an instruction can only make it less probable (§11.2: a better influence layer narrows the distribution; only the enforcement layer truncates it).
Tempting wrong home: a sterner CLAUDE.md paragraph. That is influence wearing the mask of enforcement. It works most of the time and fails precisely when the session is long and the accumulated tokens outvote the rule — intermittent compliance is softmax arithmetic over a sequence, not defiance (§6.2). Worse, it spends always-on tokens to do — unreliably — a job a free deterministic check already does for certain.
Bridge from Lecture 6. This completes L6’s “prompting cannot fix this — it needs enforcement”: now the hook has a street address, at the commit interface (§9.3).
Question5
Card 2 — need
Card 2 — what kind of need is this?
Classify the underlying need. Select all that apply.
Select all that apply:
✓Correct!
Enforcement only. “Anchors must never be stale at commit time” is a binary, deterministic property — the defining shape of the enforcement layer.
It is not influence: you do not want this biased, you want it guaranteed, and the whole trap of the card is mistaking one for the other. It is not capability in the orchestration sense — running a script is mechanical, not a world-touching tool the model must be granted. The sterner CLAUDE.md decoy is the exact mistake the teammate is about to make: you cannot prompt determinism into the model; it has to be bolted on from outside.
✗Not quite.
Hint 1
Frame it on the axis: is ‘never commit stale anchors’ something you want to make more likely (bias), to make impossible (guarantee), or a reach into the world (capability)?
Hint 2
The deck’s rule: a binary, deterministic property is the defining shape of the enforcement layer — you cannot prompt determinism into the model. And the sterner CLAUDE.md box is the exact mistake the teammate is about to make; it is never the right need here.
💡Solution
Enforcement only. “Anchors must never be stale at commit time” is a binary, deterministic property — the defining shape of the enforcement layer.
It is not influence: you do not want this biased, you want it guaranteed, and the whole trap of the card is mistaking one for the other. It is not capability in the orchestration sense — running a script is mechanical, not a world-touching tool the model must be granted. The sterner CLAUDE.md decoy is the exact mistake the teammate is about to make: you cannot prompt determinism into the model; it has to be bolted on from outside.
Question6
Card 2 — reflection
Card 2 reflection — anchor regeneration
Write out your full placement reasoning. After you submit, the reference answer for each field reveals.
Write your answer in each field. After you submit, the reference answer reveals. (No automatic grading; your text stays in your browser only.)
☰Reference answer
Influence vs. enforcement — likely vs. guaranteed. “Never commit stale anchors” is a guarantee, and only the enforcement layer can provide guarantees; the influence layer can only make the right action more probable.
☰Reference answer
The sterner CLAUDE.md paragraph = an always-on standing charge: more tokens in every session, paid forever, to do the job unreliably.
The pre-commit hook / check-anchors.yml gate = free, in context-budget terms: it runs outside the token window entirely and costs the model zero tokens. (The existing CI gate is already paid for.)
A deterministic check is the cheapest possible home: zero budget, total reliability.
☰Reference answer
A strongly-worded paragraph in root CLAUDE.md. Cost: probable-not-guaranteed compliance. It is influence masquerading as enforcement — it works in short sessions and fails when accumulated tokens outvote it (intermittent compliance, softmax arithmetic), while spending always-on tokens to do a job a free deterministic check already does for certain. The deeper cost is a false sense of safety.
☰Reference answer
This belongs in a hook / the existing check-anchors.yml CI gate because it must be guaranteed, not merely likely, and putting it in a sterner CLAUDE.md paragraph would buy only probabilistic compliance — failing exactly in the long sessions where it matters — while charging always-on tokens for the privilege.
✓Correct!
✗Not quite.
💡Solution
Question7
Card 3 — placement
Card 3: “Let the agent read and file tickets in our tracker”
Instructors want Claude Code to look up open issues and open new ones from inside a session, instead of copy-pasting between the chat and the tracker.
Realization A: connect a Jira/GitHub MCP server so the capability is available in every session.
Realization B: when a session needs ticket text, paste the issue that one time and leave the tracker unwired.
Twice-a-week need. Which placement wins?
✓Correct!
Correct answer: “Depends — and the deciding condition is frequency.” The honest answer to this card is conditional, but a named condition is the whole point — the bare “It depends” (option E) is wrong precisely because it names no condition and so settles nothing.
Two axes decide it. Always-on vs. on-demand: an MCP server’s tool descriptions occupy tokens in every conversation whether or not a tool is ever called (§9.2 — the same standing charge as instruction files). Blast radius: every connected server widens what a hallucinated or injected token sequence can do, so wiring a tool is a security decision every time (§9.3). For a genuinely frequent need, the standing charge amortises and wiring pays off; for a twice-a-week need it does not.
Why A is wrong here: always-wiring for a twice-a-week need taxes the budget and the attack surface seven days a week for a Tuesday-and-Thursday payoff.
Why C is the worst option: instructions bias a distribution, they do not grant a capability. Pasting API docs into CLAUDE.md cannot give the model hands — it still cannot reach the tracker, so it hallucinates plausible-but-wrong calls — and the docs become an always-on charge in every session. It confuses the influence layer with the capability the task actually needs.
Bridge from Lecture 6. This is L6’s “using prompting for the wrong tool” generalised to orchestration: option C is prompting a capability that only a tool can provide.
✗Not quite.
Hint 1
Two axes are in play, both turning on frequency: how often does this need actually arise, and how much does always-wiring it widen the blast radius? Twice-a-week is the figure to weigh.
Hint 2
The deck’s rules: an MCP server’s tool descriptions are an always-on charge in every session whether or not a tool is called, and every connected server widens the attack surface — while instructions bias a distribution, they do not grant a capability. One option spends that standing charge for a twice-a-week payoff; one tries to prompt a capability into being.
Hint 3
A bare “it depends” settles nothing — the credit goes to the option that names the single condition that would decide it. What one fact about this need tips always-wire vs. paste-when-needed?
💡Solution
Correct answer: “Depends — and the deciding condition is frequency.” The honest answer to this card is conditional, but a named condition is the whole point — the bare “It depends” (option E) is wrong precisely because it names no condition and so settles nothing.
Two axes decide it. Always-on vs. on-demand: an MCP server’s tool descriptions occupy tokens in every conversation whether or not a tool is ever called (§9.2 — the same standing charge as instruction files). Blast radius: every connected server widens what a hallucinated or injected token sequence can do, so wiring a tool is a security decision every time (§9.3). For a genuinely frequent need, the standing charge amortises and wiring pays off; for a twice-a-week need it does not.
Why A is wrong here: always-wiring for a twice-a-week need taxes the budget and the attack surface seven days a week for a Tuesday-and-Thursday payoff.
Why C is the worst option: instructions bias a distribution, they do not grant a capability. Pasting API docs into CLAUDE.md cannot give the model hands — it still cannot reach the tracker, so it hallucinates plausible-but-wrong calls — and the docs become an always-on charge in every session. It confuses the influence layer with the capability the task actually needs.
Bridge from Lecture 6. This is L6’s “using prompting for the wrong tool” generalised to orchestration: option C is prompting a capability that only a tool can provide.
Question8
Card 3 — need
Card 3 — what kind of need is this?
Classify the underlying need. Select all that apply.
Select all that apply:
✓Correct!
Capability only. Reading and filing tickets means the system must touch the world — reach a service outside the token sequence — and the lecture is emphatic that what an AI system can actually do is determined by its tool surface, not by its intelligence (§9.3). No amount of text in the window grants that reach.
It is not influence — biasing the distribution cannot move bytes to Jira. It is not enforcement — the need is to act, not to guarantee-or-refuse an outcome. The sterner CLAUDE.md decoy is option C’s mistake in disguise: a better-worded file still cannot give the model hands.
✗Not quite.
Hint 1
Ask the layer question: does reading and filing tickets ask the system to bias its output, to guarantee an outcome, or to touch the world and reach a service outside the token window?
Hint 2
The deck’s rule: what an AI system can actually do is determined by its tool surface, not by its intelligence — no amount of text in the window grants that reach. So the sterner CLAUDE.md decoy is option C’s mistake in disguise: a better-worded file still cannot give the model hands.
💡Solution
Capability only. Reading and filing tickets means the system must touch the world — reach a service outside the token sequence — and the lecture is emphatic that what an AI system can actually do is determined by its tool surface, not by its intelligence (§9.3). No amount of text in the window grants that reach.
It is not influence — biasing the distribution cannot move bytes to Jira. It is not enforcement — the need is to act, not to guarantee-or-refuse an outcome. The sterner CLAUDE.md decoy is option C’s mistake in disguise: a better-worded file still cannot give the model hands.
Question9
Card 3 — reflection
Card 3 reflection — ticket tracker access
Write out your full placement reasoning. After you submit, the reference answer for each field reveals.
Write your answer in each field. After you submit, the reference answer reveals. (No automatic grading; your text stays in your browser only.)
☰Reference answer
Two axes, both decided by frequency. (1) Always-on vs. on-demand: MCP tool descriptions are paid in every session whether or not the tool is called. (2) Blast radius: every connected server widens what a hallucinated or injected sequence can do, so wiring a tool is a security decision every time. For a twice-a-week need, neither standing cost is justified.
☰Reference answer
MCP server (A) = an always-on standing charge: tool descriptions occupy tokens in every conversation, called or not, and a standing widening of the attack surface every day.
Paste-when-needed (B) = on-demand: the issue text costs tokens only in the sessions that actually need it, and wires no new capability.
API docs in CLAUDE.md (C) = an always-on standing charge that buys nothing — it cannot grant the capability, so it is window spent for no benefit in every session.
☰Reference answer
Two tempting wrongs. Always-wiring the MCP server (A) for a twice-a-week need: cost is a widened blast radius plus an always-on token charge seven days a week for a payoff two days a week. Worse: pasting API docs into CLAUDE.md (C): instructions bias a distribution, they do not grant a capability — the model still cannot reach the tracker, so it hallucinates plausible-but-wrong calls, while the docs become an always-on standing charge.
☰Reference answer
This is a capability that belongs in a wired MCP tool when the need is frequent enough to amortise its always-on token charge and widened blast radius — and at twice a week it does not, so paste-when-needed wins; always-wiring would tax budget and attack surface seven days a week, and pasting API docs into CLAUDE.md would grant no capability at all while charging tokens in every session.
✓Correct!
✗Not quite.
💡Solution
Question10
Card 4 — placement
Card 4: “Remember that I prefer British spelling and terse commit messages”
This preference is genuinely personal (it is yours, not the team’s), genuinely recurring (it comes up most sessions), low-stakes, and verified by nothing — no test checks it, no convention enforces it.
A: write it to the model-authored MEMORY.md.
B: commit a “Preferences” block to the version-controlled root CLAUDE.md.
Where does this need primarily belong?
✓Correct!
Correct home: MEMORY.md. This is the rare card whose best home really is memory. The deciding axis is ephemeral-vs-persistent + who authors it (provenance).
The lecture lets you derive exactly when memory is the right tool: a memory is soft context — useful for preferences and working style, fine to be unverified (§5.3). This preference is soft, per-user, persistent across sessions, and nothing breaks if the memory is occasionally wrong. That is the memory profile.
Tempting wrong home: a Preferences block in the team’s root CLAUDE.md. CLAUDE.md and MEMORY.md are the same transport with opposite provenance (§5.2): CLAUDE.md is committed and shared with everyone who clones the repo. Putting one developer’s taste there ships it as always-on tokens into every teammate’s sessions.
The deeper trap (the inverse lesson): memory is the right home here precisely because the fact is soft and personal. Memorising a load-bearing technical fact — “the auth service runs on port 8081” — is the opposite: it is born possibly-wrong, nothing verifies it against the repo, and it is re-injected into the privileged early positions of every future session until deleted (§5.3 — stale and born-wrong memories). Soft preferences are the only kind of content that belongs in memory.
✗Not quite.
Hint 1
Think on the provenance axis: who authors this preference, and who should it follow — the person or the version-controlled project? And is it safe for it to be occasionally wrong?
Hint 2
The deck’s rule: CLAUDE.md and MEMORY.md are the same transport with opposite provenance — CLAUDE.md is committed and shared with everyone who clones the repo, while a memory is per-user soft context, fine to be unverified. Which home keeps one developer’s taste off every teammate’s session?
💡Solution
Correct home: MEMORY.md. This is the rare card whose best home really is memory. The deciding axis is ephemeral-vs-persistent + who authors it (provenance).
The lecture lets you derive exactly when memory is the right tool: a memory is soft context — useful for preferences and working style, fine to be unverified (§5.3). This preference is soft, per-user, persistent across sessions, and nothing breaks if the memory is occasionally wrong. That is the memory profile.
Tempting wrong home: a Preferences block in the team’s root CLAUDE.md. CLAUDE.md and MEMORY.md are the same transport with opposite provenance (§5.2): CLAUDE.md is committed and shared with everyone who clones the repo. Putting one developer’s taste there ships it as always-on tokens into every teammate’s sessions.
The deeper trap (the inverse lesson): memory is the right home here precisely because the fact is soft and personal. Memorising a load-bearing technical fact — “the auth service runs on port 8081” — is the opposite: it is born possibly-wrong, nothing verifies it against the repo, and it is re-injected into the privileged early positions of every future session until deleted (§5.3 — stale and born-wrong memories). Soft preferences are the only kind of content that belongs in memory.
Question11
Card 4 — need
Card 4 — what kind of need is this?
Classify the underlying need. Select all that apply.
Select all that apply:
✓Correct!
Influence only. A memory file is “influence the model wrote for itself in an earlier conversation” (§11.1) — text that enters the sequence and biases the distribution toward British spelling and terse commits. The need is purely to bias; it carries no guarantee and reaches into no external system.
It is not enforcement (nothing checks it — and that is fine for a soft preference). It is not capability. And the sterner CLAUDE.md decoy is doubly wrong here: the right file is MEMORY.md, not CLAUDE.md at all, and the content is soft preference, not a rule to be sternly worded.
✗Not quite.
Hint 1
Ask the layer question: does a spelling-and-commit-style preference bias the distribution, guarantee an outcome, or reach into the world?
Hint 2
The deck’s rule: a memory file is influence the model wrote for itself in an earlier conversation — pure influence, carrying no guarantee. And the sterner CLAUDE.md decoy is doubly wrong here: the right file isn’t CLAUDE.md at all, and a soft preference is not a rule to be sternly worded.
💡Solution
Influence only. A memory file is “influence the model wrote for itself in an earlier conversation” (§11.1) — text that enters the sequence and biases the distribution toward British spelling and terse commits. The need is purely to bias; it carries no guarantee and reaches into no external system.
It is not enforcement (nothing checks it — and that is fine for a soft preference). It is not capability. And the sterner CLAUDE.md decoy is doubly wrong here: the right file is MEMORY.md, not CLAUDE.md at all, and the content is soft preference, not a rule to be sternly worded.
Question12
Card 4 — reflection
Card 4 reflection — personal preference
Write out your full placement reasoning. After you submit, the reference answer for each field reveals.
Write your answer in each field. After you submit, the reference answer reveals. (No automatic grading; your text stays in your browser only.)
☰Reference answer
Ephemeral-vs-persistent + provenance (who authors it). The preference is persistent across sessions (so not ephemeral prompt text), personal (so it should follow the user, not the repo), and unverified-but-low-stakes — which is the exact profile MEMORY.md is for.
☰Reference answer
MEMORY.md = an always-on standing charge, but a small one (~50–500 tokens for the whole memory file) and borne by you alone, per-machine.
Preferences block in root CLAUDE.md = an always-on standing charge multiplied across the whole team — every teammate pays your preference’s tokens in every session.
Type-in-the-prompt = on-demand but you re-pay the effort each session; wrong for a recurring need.
The cheapest correct home is the one whose standing charge falls on the single person who benefits.
☰Reference answer
Committing a Preferences block to the team’s root CLAUDE.md. Cost: it ships one developer’s personal taste to the whole team as always-on tokens in everyone’s sessions (widened blast radius of a personal choice). The inverse trap is memorising a load-bearing technical fact instead of a soft preference: born possibly-wrong, never verified against the repo, re-injected into privileged early positions of every future session until deleted — the “works on my machine” divergence.
☰Reference answer
This belongs in MEMORY.md because it is a soft, persistent, per-user preference that is safe to be unverified, and committing it to the team’s root CLAUDE.md would broadcast one person’s taste as always-on tokens in every teammate’s session.
✓Correct!
✗Not quite.
💡Solution
Question13
Card 5 — placement
Card 5: A tests-only convention in a monorepo
A convention applies only inside tests/: fixtures go in conftest.py, and tests must be parametrized rather than looped. This is a large repo; most sessions never touch tests. A colleague put the rule in root CLAUDE.md “to be safe.”
Where does this need primarily belong?
✓Correct!
Correct home: a subdirectory tests/CLAUDE.md. The deciding axis is always-on vs. on-demand timing, used as a budget instrument.
Rule two of CLAUDE.md loading injects a directory’s CLAUDE.md only when a tool reads a file under that directory (§4.2). A convention in tests/CLAUDE.md is therefore “paid only by conversations that actually touch the tests” — the lecture’s own example of the directory tree as a budget instrument. The test sessions get the rule exactly when they need it; the non-test sessions never pay for it.
Tempting wrong home: keeping it in root “to be safe.” A tests-only rule in root is a standing charge in every session, including the majority that never go near tests — window, cost, and latency spent for nothing in those sessions. It is one more competitor for attention and can push the genuinely always-on rules toward the lost-in-the-middle zone (a model- and format-dependent tendency), and it buys the test sessions nothing, because they would receive it on demand anyway. “To be safe” is the exact instinct §10.1 warns against: every always-on token is a token of window the work does not get.
(A skill could also carry a test-writing pattern, but the natural fit for “a convention scoped to a directory subtree” is the subdirectory file, whose trigger — a tool reading under tests/ — matches the scope precisely.)
Bridge from Lecture 5/6. This is the context-budget point applied to placement: relevant context sharpens the model’s continuation, while irrelevant always-on context spends window for no benefit and can add distractors that pull the model off-task (an effect that depends on the model and the content, not a fixed share of the window) (§10.1).
✗Not quite.
Hint 1
Start with scope as a frequency question: where in the directory tree does this convention actually apply, and how often do sessions touch that subtree versus the rest of the monorepo?
Hint 2
The deck’s rule (loading rule two): a directory’s CLAUDE.md is injected only when a tool reads a file under that directory — the directory tree used as a budget instrument. The colleague’s “to be safe” instinct is the trap §10.1 warns against: every always-on token is a token denied to the work. Which home charges only the sessions that need the rule?
💡Solution
Correct home: a subdirectory tests/CLAUDE.md. The deciding axis is always-on vs. on-demand timing, used as a budget instrument.
Rule two of CLAUDE.md loading injects a directory’s CLAUDE.md only when a tool reads a file under that directory (§4.2). A convention in tests/CLAUDE.md is therefore “paid only by conversations that actually touch the tests” — the lecture’s own example of the directory tree as a budget instrument. The test sessions get the rule exactly when they need it; the non-test sessions never pay for it.
Tempting wrong home: keeping it in root “to be safe.” A tests-only rule in root is a standing charge in every session, including the majority that never go near tests — window, cost, and latency spent for nothing in those sessions. It is one more competitor for attention and can push the genuinely always-on rules toward the lost-in-the-middle zone (a model- and format-dependent tendency), and it buys the test sessions nothing, because they would receive it on demand anyway. “To be safe” is the exact instinct §10.1 warns against: every always-on token is a token of window the work does not get.
(A skill could also carry a test-writing pattern, but the natural fit for “a convention scoped to a directory subtree” is the subdirectory file, whose trigger — a tool reading under tests/ — matches the scope precisely.)
Bridge from Lecture 5/6. This is the context-budget point applied to placement: relevant context sharpens the model’s continuation, while irrelevant always-on context spends window for no benefit and can add distractors that pull the model off-task (an effect that depends on the model and the content, not a fixed share of the window) (§10.1).
Question14
Card 5 — need
Card 5 — what kind of need is this?
Classify the underlying need. Select all that apply.
Select all that apply:
✓Correct!
Influence only. A convention (“fixtures in conftest.py, parametrize don’t loop”) is text that biases the model toward the house style — influence-layer material, whether it sits in root or in a subdirectory file. The card is a pure placement question within the influence layer: same kind of need as Card 1, different mechanism (subdirectory splice vs. skill) because the trigger is “a tool reads this subtree” rather than “this task type starts.”
It is not enforcement (you could additionally enforce parametrization with a lint rule, but the convention itself is influence). It is not capability. The sterner CLAUDE.md decoy is the colleague’s “to be safe” instinct: the file does not need stronger wording, it needs to move down the tree.
✗Not quite.
Hint 1
Ask the layer question: is a house-style convention (“fixtures in conftest.py, parametrize don’t loop”) a guarantee, a world-touching action, or text that biases the model toward the style?
Hint 2
The deck’s rule: anything that enters the token sequence is influence-layer material — so this is the same kind of need as Card 1, just a different mechanism. The sterner CLAUDE.md decoy is the colleague’s “to be safe” reflex: the file doesn’t need stronger wording, only a different place in the tree.
💡Solution
Influence only. A convention (“fixtures in conftest.py, parametrize don’t loop”) is text that biases the model toward the house style — influence-layer material, whether it sits in root or in a subdirectory file. The card is a pure placement question within the influence layer: same kind of need as Card 1, different mechanism (subdirectory splice vs. skill) because the trigger is “a tool reads this subtree” rather than “this task type starts.”
It is not enforcement (you could additionally enforce parametrization with a lint rule, but the convention itself is influence). It is not capability. The sterner CLAUDE.md decoy is the colleague’s “to be safe” instinct: the file does not need stronger wording, it needs to move down the tree.
Question15
Card 5 — reflection
Card 5 reflection — tests-only convention
Write out your full placement reasoning. After you submit, the reference answer for each field reveals.
Write your answer in each field. After you submit, the reference answer reveals. (No automatic grading; your text stays in your browser only.)
☰Reference answer
Always-on vs. on-demand timing, used as a budget instrument. The convention is scoped to one subtree (tests/), so its tokens should be paid only by sessions that read that subtree — exactly what subdirectory CLAUDE.md loading (rule two) provides.
☰Reference answer
Root CLAUDE.md = an always-on standing charge: paid in every session, including the majority that never touch tests.
tests/CLAUDE.md = on-demand: injected only when a tool reads under tests/ (§4.2’s rule two) — zero cost to non-test sessions.
The on-demand home buys the test sessions exactly what the always-on home does, at a fraction of the total budget.
☰Reference answer
Keeping it in root CLAUDE.md “to be safe.” Cost: a tests-only rule paid as a standing charge in every non-test session — window, cost, and latency spent for nothing in sessions that never touch tests — and one more competitor that can push the genuinely always-on rules toward the lost-in-the-middle zone (a model- and format-dependent tendency), while buying the test sessions nothing they would not have received on demand.
☰Reference answer
This belongs in a subdirectory tests/CLAUDE.md because the convention is scoped to one subtree and should be paid on demand by sessions that read it, and keeping it in root CLAUDE.md “to be safe” would charge every non-test session for it and add a competitor that can push the always-on rules toward the lost-in-the-middle zone.
✓Correct!
✗Not quite.
💡Solution
Question16
Card 6 — placement
Card 6: A hard “no-secrets-in-logs / no-prod-deploy” rule that keeps slipping
The assistant must never write code that logs secrets and must never run a production deploy. The team keeps adding sterner CLAUDE.md wording — “NEVER log credentials, this is CRITICAL” — and it still occasionally slips, especially after the model reads a web page or issue that contains an injected instruction.
Where does this need primarily belong?
✓Correct!
Correct home: enforcement + permission scoping at the tool interface. The deciding axis is likely-vs-guaranteed, with blast radius behind it.
The lecture is categorical: for adversarial inputs, assume the influence layer is defeated — safety properties must live in enforcement, not in prompts (§9.3). A model that emits a destructive call because an attacker buried an instruction in a web page it just read is not malfunctioning — it is completing the most contextually plausible continuation. So the guarantee has to be structural: a secret-scanning hook/CI, schema validation on the deploy tool, scoped non-prod credentials, and a human gate in front of the irreversible. The defense is a narrower tool surface, never a sterner file.
Tempting wrong home: a sterner, ALL-CAPS CLAUDE.md rule. It confuses influence with enforcement. A stern instruction makes the bad action less probable but never impossible, and it widens nothing about the blast radius. Against an adversarial sequence you must assume it is already defeated — so the false sense of safety it creates is itself the cost.
Bridge from Lecture 6. This is the capstone of L6’s three-layer model: you cannot replace enforcement with more influence; only the enforcement layer truncates the distribution (§11.2, §11 the completed model).
✗Not quite.
Hint 1
Frame it on likely-vs-guaranteed, with blast radius behind it: against an attacker who buried an instruction in a page the model just read, can ANY wording be trusted? Note the team has already tried escalating the wording and it still slips.
Hint 2
The deck’s rule: for adversarial inputs, assume the influence layer is defeated — safety properties must live in enforcement, not in prompts, and only the enforcement layer truncates the distribution. A model emitting a destructive call after reading an injected page is not malfunctioning — so what makes the bad outcome structurally impossible rather than merely less likely?
💡Solution
Correct home: enforcement + permission scoping at the tool interface. The deciding axis is likely-vs-guaranteed, with blast radius behind it.
The lecture is categorical: for adversarial inputs, assume the influence layer is defeated — safety properties must live in enforcement, not in prompts (§9.3). A model that emits a destructive call because an attacker buried an instruction in a web page it just read is not malfunctioning — it is completing the most contextually plausible continuation. So the guarantee has to be structural: a secret-scanning hook/CI, schema validation on the deploy tool, scoped non-prod credentials, and a human gate in front of the irreversible. The defense is a narrower tool surface, never a sterner file.
Tempting wrong home: a sterner, ALL-CAPS CLAUDE.md rule. It confuses influence with enforcement. A stern instruction makes the bad action less probable but never impossible, and it widens nothing about the blast radius. Against an adversarial sequence you must assume it is already defeated — so the false sense of safety it creates is itself the cost.
Bridge from Lecture 6. This is the capstone of L6’s three-layer model: you cannot replace enforcement with more influence; only the enforcement layer truncates the distribution (§11.2, §11 the completed model).
Question17
Card 6 — need
Card 6 — what kind of need is this?
Classify the underlying need. This card is a split: more than one option is creditable. Select all that apply.
Select all that apply:
✓Correct!
Split: influence and enforcement. Both are genuinely creditable here. A CLAUDE.md line (“don’t log credentials”) still makes the good behaviour likelier — that is real, useful influence, and worth keeping. But the guarantee the task actually demands can only come from the enforcement layer: a secret-scanning gate, schema validation, scoped credentials, a human approval gate.
The distinction the card tests is that you must not let the influence half stand in for the enforcement half. A better influence layer narrows the distribution; only the enforcement layer truncates it (§11.2).
The sterner CLAUDE.md decoy must not be checked. It is the precise trap: it dresses the influence half up as if it could do the enforcement half’s job. Checking it is the mistake the whole card is built to expose.
✗Not quite.
Hint 1
Work the layer question both ways: a CLAUDE.md line does still make the good behaviour likelier (real influence) — but what does the task actually demand be guaranteed against an injected instruction?
Hint 2
The deck’s rule: a better influence layer narrows the distribution; only the enforcement layer truncates it. Don’t let one half stand in for the other — both can be genuinely creditable on this card.
Hint 3
This card is a split: more than one box can be right. But the sterner CLAUDE.md box is the trap — it dresses the influence half up as if it could do the enforcement half’s job. Decide each box on its own merits without letting that one in.
💡Solution
Split: influence and enforcement. Both are genuinely creditable here. A CLAUDE.md line (“don’t log credentials”) still makes the good behaviour likelier — that is real, useful influence, and worth keeping. But the guarantee the task actually demands can only come from the enforcement layer: a secret-scanning gate, schema validation, scoped credentials, a human approval gate.
The distinction the card tests is that you must not let the influence half stand in for the enforcement half. A better influence layer narrows the distribution; only the enforcement layer truncates it (§11.2).
The sterner CLAUDE.md decoy must not be checked. It is the precise trap: it dresses the influence half up as if it could do the enforcement half’s job. Checking it is the mistake the whole card is built to expose.
Question18
Card 6 — reflection
Card 6 reflection — no-secrets / no-prod-deploy
Write out your full placement reasoning. After you submit, the reference answer for each field reveals.
Write your answer in each field. After you submit, the reference answer reveals. (No automatic grading; your text stays in your browser only.)
☰Reference answer
Likely-vs-guaranteed, with blast radius behind it. The team wants a safety property guaranteed against adversarial input, and for adversarial input you must assume the influence layer is defeated — so the guarantee can only come from enforcement and a narrowed tool surface.
☰Reference answer
Sterner CLAUDE.md rule = an always-on standing charge that grows with each ALL-CAPS escalation, and buys no guarantee.
Secret-scanning hook / CI + schema validation = free in context-budget terms: they run outside the token window.
Scoped non-prod credentials + a human approval gate = free in budget terms (configuration and permissions, not tokens).
Keep a short influence line if it helps — but the load-bearing protections are budget-free enforcement.
☰Reference answer
A sterner, ALL-CAPS CLAUDE.md rule. Cost: it confuses influence with enforcement. Against an injected/adversarial sequence you must assume the influence layer is defeated — the model emitting a destructive call is the most plausible continuation, not a malfunction. A stern instruction makes the bad action less probable but never impossible and widens nothing about the blast radius; the false sense of safety is the real cost.
☰Reference answer
This belongs in enforcement plus permission scoping at the tool interface (secret-scanning gate, schema validation, scoped non-prod credentials, human approval on the irreversible) because a safety property must be guaranteed, not merely made likely — and relying on a sterner CLAUDE.md rule would confuse influence with enforcement, leaving the system defeatable by a single injected instruction while feeling safe.