Claude Code Configuration & Workflows

Koko: Domain three is twenty percent of the exam, and almost every question in it is secretly the same question. Once you see that, the whole domain clicks into place. So let me give you the instinct right up front: every capability in a code-working AI agent lives in one of three buckets. Always loaded, summoned on demand, or running with no human in the loop.

Chris: Right — and those aren't just categories for tidiness. The exam is testing whether you can sort a described capability into the correct bucket before you even look at the answer choices.

Koko: Exactly. So let's make each bucket concrete. Always loaded is the project memory file. It gets read into the agent at the start of every single session — before the agent touches a single line of code. Think of it like the briefing sheet a surgeon reviews before entering the operating room. It's always there, it doesn't wait to be asked for.

Chris: So project conventions, repo-level context, standing instructions — that's memory-file territory. It's not invoked by a task, it just exists in the background for every task.

Koko: That's it. Now bucket two: summoned on demand. This covers skills, subagents, and workflows. They only get pulled in when a specific task actually needs them. Think of these like specialists you page — a radiologist isn't standing in every room, they get called when there's a scan to read.

Chris: And the discriminator there — if the question describes something that runs for every task regardless, that's bucket one, not bucket two.

Koko: Precise. That's exactly where the exam puts the fork in the road. Bucket three is the one that trips people up most: no human in the loop. That's the CI/CD case — the agent running headless inside a pipeline, completely automated, nobody watching.

Chris: Headless is the keyword there. No interactive session, no human approving steps mid-run.

Koko: Right. And the trap here is treating a headless pipeline step like a summoned skill — they sound similar because both are task-triggered, but a CI step has no human in the loop at all, and that changes the entire trust model.

Chris: That makes sense. The moment there's no human available to catch a mistake mid-run, the design constraints shift.

Koko: They do. Which is why on top of the sorting instinct, two habits apply everywhere in this domain: least privilege for tools, and credentials come from named secrets — never hard-coded. Those aren't separate topics, they're the follow-through after you sort correctly.

Chris: So the question flow is basically: sort the capability into always-on, summoned, or headless — and then least privilege and named secrets are the defaults you apply once you know where it lives.

Koko: That's the whole domain in one move. Every question is asking you to do that sort, and then those two habits tell you which answer is right. Keep that three-bucket frame in your head and we'll build everything else on top of it.

Koko: So the project memory file — think of it as the first page of the onboarding binder you hand a brand-new contractor. What this place is, the run and build commands, and the one habit they must never forget. That's it. One page.

Chris: And the reason it stays lean is that it loads into the agent's working memory at the start of every single session, so every line you add is a line you're paying for in tokens every time.

Koko: Exactly. High-value, always-relevant orientation at the top — and when something is long, you link to it, you don't paste it. The trap here is treating the file like a wiki. Every runbook inline, every procedure dumped in. Now the always-loaded context is bloated, and the actual question the agent needs to answer gets crowded out.

Chris: So the instinct is: if it matters every session, put it in. If it's situational, it belongs somewhere that loads only when it's needed.

Koko: That's the instinct the exam rewards. Keep it lean, link the rest.

Koko: Now, it's not just one file — there's a whole hierarchy. Personal user level that travels with you across projects, shared project level that lives in the repo, and directory-level files that only kick in inside a specific subtree.

Chris: And they're additive — more specific layers add to the broader ones and can override them, but they don't wipe out what's above.

Koko: Right. Not replace — override. That distinction shows up on the exam.

Chris: What about imports? I know you can import from within a memory file — does that save you context?

Koko: That's the precise question, and the answer is no. An import is for organizing the file, not for saving tokens, because imported files load together with the file that imports them. The trap here is thinking a nested file replaces the root, or that importing is a lazy context-saving trick. It isn't.

Chris: So if you want something to load only when needed, you scope it to a subdirectory — you don't import it from the root file.

Koko: Exactly. Scope to the narrowest layer that applies. That's the rule.

Koko: Last piece — what makes an instruction actually effective. Think of it like a local rules sign on one workshop door versus a vague 'be careful' poster in the lobby. The sign on the door wins every time.

Chris: Because it's specific to where you are, and it tells you what to actually do.

Koko: Three things: specific, actionable, and it names a real failure mode. Ideally phrased as a trap that already bit the team. Here's a worked example — instead of 'be careful with deploys,' the rule reads: 'a green succeeded status only means the request was sent — confirm the real result in the response's status code.' That's a symptom, a false signal, and the real check, all in one sentence.

Chris: And that rule lives in a nested memory file inside the deploys subtree, not in the root file, because it only governs that one area.

Koko: You've got it. Scope the rule to its blast radius so the agent sees it exactly when it's editing the code it governs.

Chris: The exam option sitting next to the right answer will probably say something like 'add a general best practices reminder to the top-level file.' That sounds safe, but it's just noise.

Koko: The trap there is vague motivational rules — 'be careful,' 'follow best practices.' They give the model nothing to act on. Specific, actionable, named failure mode. That's the instinct.

Koko: So we have three ways to package capability in this domain, and the exam loves forcing you to pick the right one. Let's start with the first: skills. A skill is knowledge or a procedure the agent loads only when a task actually calls for it.

Chris: So it's reusable expertise that stays off to the side until it's needed — rather than riding along in memory every session.

Koko: Exactly. Think of a reference card you pull from a drawer for a specific job. You don't tape every card to your desk — that's clutter. The always-on context stays lean, and the skill gets summoned on demand.

Chris: The instinct the exam rewards is: if something is needed occasionally, package it as a skill. Only load it when the task actually requires it.

Koko: That's it. And the trap is pasting that same procedure into the always-loaded memory file. It rides along every session, eating context, even when it's completely irrelevant to what the agent is doing.

Koko: Next up: subagents. A subagent is a separate worker with its own isolated context and its own least-privilege tools.

Chris: The isolated context part is doing a lot of work there. If one subagent is deep in research on one topic, another subagent's tokens can't derail it. And the main agent gets back a clean summary, not everyone's raw scratch work.

Koko: Right. Delegate a self-contained task to a specialist who reports back a tidy summary — not their entire desk. That's the analogy. And the least-privilege piece matters just as much: give the subagent only the tools its narrow job requires.

Chris: So the instinct is: reach for a subagent when you need context isolation or specialization, and keep its toolset narrow.

Koko: Exactly. The trap is doing everything in one context and handing every worker every tool. You blow the context window and you widen the blast radius of any single mistake. One bad move can affect everything.

Chris: What's the sharpest discriminator between a skill and a subagent? Both feel like ways to keep the main context clean.

Koko: Good question. A skill is knowledge or a procedure — it loads into the current context when called. A subagent is a separate worker running in its own isolated context. Different execution model entirely. If you need isolation or specialization, that's a subagent. If you just need a procedure available on demand, that's a skill.

Koko: Now the third option — workflows — and this is where the exam really tests you, because all three can look like reasonable answers.

Chris: A workflow is deterministic orchestration — code-driven control flow with loops, branches, fan-out. The sequence is guaranteed, not model-chosen.

Koko: Exactly. If you need the steps to run in a fixed, repeatable order, that's a workflow. The rule of thumb is clean: skill for occasional knowledge, subagent for isolation or specialization, workflow when the sequence has to be guaranteed.

Chris: The option sitting next to the right answer on the exam will often say to just put the guaranteed sequence into a prompt and let the model decide the order.

Koko: And that's exactly the trap — using one hammer for all three. Cramming a guaranteed sequence into a prompt, or packaging a reusable procedure into a subagent when a skill would do. The instinct the exam rewards is matching the mechanism to the actual need instead of defaulting everything to just another prompt.

Chris: So the sorting question is: do I need knowledge on demand, isolation, or a guaranteed sequence? Each answer points to a different mechanism.

Koko: That's the whole framework. Nail that sorting instinct and this section of the exam gets a lot less slippery.

Koko: So the first big working decision the exam tests is when to plan and when to just execute. The framing that unlocks it is two questions: how reversible is this, and what is the blast radius if it goes wrong?

Chris: Right — small and contained, execute directly. Risky, broad, or ambiguous, do a plan-first pass and get approval before touching any files.

Koko: Exactly. Think of it as sketching the blueprint before pouring the concrete. A one-line copy fix — the concrete is barely wet, you can redo it in seconds. A twelve-file refactor that is hard to unwind — you really want the blueprint approved before anyone mixes cement.

Chris: And planning mode is essentially a human gate applied to the work itself — a cheap checkpoint exactly where a mistake would be most expensive.

Koko: That is the instinct the exam rewards: decide by reversibility and blast radius, not by habit. The trap is the two lazy defaults. Always planning wastes time on a typo fix. Always executing turns a sprawling risky change into an expensive diff with no checkpoint in sight.

Chris: The tool-selection piece feels related — each file tool has a specific lane, and the pattern is to narrow before you read.

Koko: Exactly right. Glob to find where things live by filename, content-search to find which files mention a specific thing, read only the relevant slice to understand it, then edit. Shell for commands. That order matters.

Chris: So for a function bug — content-search to locate the file, read just that section, then edit. Not load the whole repo.

Koko: Right. The analogy is a library catalog and an index. You use them to find the paragraph — you do not photocopy the whole building. Targeted reads are cheaper and they are actually more accurate because you are not burying the signal in noise.

Chris: What is the exam trying to catch here? Because most candidates probably know you should not load everything.

Koko: The trap is framed as safety: read everything to be safe. The exam will make it sound thorough and responsible. But burning the context window on files you do not need is the thing that buries the signal. The instinct is investigate as a funnel — find, search, read, edit — and match the tool to the specific question, not to a general desire to feel informed.

Chris: CI/CD mode is where this gets higher stakes. The agent runs non-interactively — reviewing a pull request, generating tests, triaging an issue — and emits structured output that a script acts on directly.

Koko: Right, its verdict can gate a merge or open a follow-up automatically, with no human in the loop in real time. Two things change the moment the human leaves.

Chris: Least-privilege tooling, and irreversible actions still gated. Because there is no one to catch a bad call before it lands.

Koko: And the second is credentials. They come from the pipeline's named secret store — never hard-coded, never echoed into logs.

Chris: The option sitting next to it on the exam will say something like: it is only CI, no user is watching, so you can relax the permissions or inline the token for convenience.

Koko: And that is precisely the trap. Headless mode is not a reason to loosen the guardrails — it is the reason to keep them just as strict. No human backstop means a bad call just runs. The instinct is: automate the judgment, but keep the guardrails and the secrets handling exactly as strict as they would be with someone watching.

Chris: So the discipline is the same whether a person is watching or not. The pipeline does not earn relaxed rules just because it is automated.

Koko: That is the whole thing. Reversibility, blast radius, funnel-shaped investigation, and strict guardrails in headless mode — those are the four levers Domain Three keeps pulling on.

Koko: Alright, let's do some scenarios — real exam-style situations where you have to pick the right move. First one. A team's project memory file has grown enormous. Every deploy runbook, every rare emergency procedure, all of it pasted in inline. Now the agent feels sluggish, costs more per message, and sometimes loses the thread of what the user actually asked. What's going on?

Chris: The memory file is loaded on every single turn. So every line in it costs tokens on every message, not just when it's relevant.

Koko: Exactly. Think of it like leaving every manual for every appliance you own open on your desk, every morning, whether you're cooking or not. Most of it is just noise you have to push past. And the exam is going to offer a very appealing distractor here — 'just increase the context window.' The trap is that a bigger window doesn't fix the cost or the noise; it just means you can fit even more irrelevant runbooks in before things break.

Chris: Right, the problem isn't capacity, it's always-on loading. So the fix is moving those rare procedures out of the memory file entirely — into skills or path-scoped rules that load on demand.

Koko: That's it. Keep the memory file lean — high-value orientation, the conventions that truly apply everywhere, things the agent genuinely needs on every turn. The rare runbooks are summoned-on-demand knowledge. That's exactly what a skill or a linked scoped rule is built for.

Chris: One thing I want to make sure I have right — if you import those runbooks into the memory file instead of moving them, that doesn't help, does it? The import still loads with the file.

Koko: Correct. Imports are not lazy. If the memory file loads, everything it imports loads too. The exam will absolutely offer 'refactor the memory file to use imports' as a feel-good option. It changes nothing about the cost.

Koko: Second scenario. A team comes to you with three distinct needs. One: a reusable procedure for how the team writes database migrations — the agent should follow it whenever it touches a migration file. Two: they need to analyze a massive dependency graph, but they don't want that analysis polluting the main agent's context. Three: a nightly job that must run the same fixed sequence of steps every time, no variation. Walk me through where each one lands.

Chris: The migrations procedure is on-demand knowledge, and it's scoped — it only matters when the agent is working near migration files. That's a skill, or a path-scoped instruction. Not in the main memory file.

Koko: Good. And the dependency graph analysis?

Chris: That one wants isolation. You spin up a subagent with a narrow set of tools, it does the heavy analysis, and it hands a summary back to the main agent. The big context stays contained.

Koko: Exactly. The subagent takes the context hit so the main agent doesn't have to. Now the nightly job — what's the discriminator there?

Chris: Guaranteed order. The steps must run the same way every time — that's a workflow, driven by code, not a model deciding the sequence at runtime.

Koko: Right. The trap the exam sets is putting that nightly job into an agent loop and trusting the model to sequence it. But when order is fixed and must be reliable, you take the decision out of the model entirely. Code controls the sequence. The skill the exam is testing across all three of these is the same one — matching each need to the mechanism that was actually built for it, not reaching for the most flexible option by default.

Koko: Alright, let's make sure the instincts are sharp before you walk in. Seven of them, and they compound. The first one is the load-bearing one — it answers most of this domain by itself.

Chris: Sort the capability into always loaded, summoned on demand, or no human in the loop. Once you place it in the right bucket, the follow-on questions mostly answer themselves.

Koko: Exactly. That single sorting move is the through-line of the whole domain. And instinct two follows directly from it — because the project memory file is always loaded, what's the discipline around it?

Chris: Keep it lean. It's an onboarding one-pager, not a wiki. High-value content lives there directly, long reference material gets linked out.

Koko: Right. The trap the exam sets is a bloated memory file that front-loads everything — looks thorough, actually burns context and buries the signal. Lean and linked.

Chris: Instinct three is about what makes an instruction good — specific, actionable, names the non-obvious failure mode, scoped to the paths it actually governs.

Koko: Yes, and scoping is where people slip. An instruction that governs everything governs nothing well. Alright, four — the mechanism matchup.

Chris: Skill equals on-demand knowledge, subagent equals isolated context plus narrow tools, workflow equals guaranteed order. Match the mechanism to the need, not to what's familiar.

Koko: The trap there is reaching for a workflow when you actually need a subagent, because guaranteed order sounds like rigor. But if the need is isolation, order doesn't help you.

Chris: Five is plan versus execute — decide by reversibility and blast radius. High reversibility, small blast radius, you can execute. Low reversibility or wide blast radius, you stop and plan.

Koko: Precisely. Six — investigating a codebase.

Chris: Funnel. Find, search, read, edit — in that order. Never slurp whole directories. The exam will offer you the whole-directory shortcut and it looks efficient.

Koko: And seven ties the bow on headless CI: least privilege, hard gates on irreversible actions, secrets from the named store. Exactly as strict as when a human is watching — actually stricter, because no human is.

Chris: The version the exam will tempt you with is treating headless as lower stakes because no one's looking. It's the opposite.

Koko: Exactly right. So zoom out — this domain is a sorting exercise plus two safety habits. Least privilege and named secrets. Every question is asking you to name the bucket first. Do that, and the rest falls into place. Keep drilling with the flashcards and the quiz at KokoAI Academy — koko knows dot A I. You're building the instincts that make an agent a teammate instead of a liability.

Koko: Alright, last module — this is where we lock in the vocabulary and the exact details the exam loves to test. No new concepts, just the precise names and the distinctions that separate a pass from a near-miss.

Chris: Good. The CLAUDE.md hierarchy is probably the densest vocabulary cluster. Three named levels — user, project, and directory — plus the organisation-managed policy file sitting above all of them, and a gitignored local file that lives beside the project one.

Koko: Exactly. And the exam loves the teammate scenario — someone isn't following team standards. Where is their config almost certainly sitting?

Chris: User level. Their personal tilde-slash-dot-claude-slash-CLAUDE.md. Fix is to move it to the committed project-level file so the whole team shares it.

Koko: That's the instinct — shared means project-level, personal means user-level. Now for modular memory, the exam will name at-import. What's the alternative to a per-directory CLAUDE.md when your files are scattered across the tree?

Chris: Rules files. You put them in dot-claude-slash-rules-slash, and the YAML frontmatter has a paths glob — something like double-star-slash-star-dot-test-dot-tsx — so the rule only loads when you're editing a matching file. Much cleaner than one CLAUDE.md per directory.

Koko: Perfect. Now skills — this is where the vocabulary trap lives. Commands used to go in dot-claude-slash-commands-slash, and that still works. But new work goes in dot-claude-slash-skills-slash. Same slash command result, modern path.

Chris: And the skill frontmatter fields the exam names: context colon fork to run in an isolated sub-agent so verbose output doesn't pollute your main session, allowed-tools to pre-approve tools without a permission prompt, and argument-hint for autocomplete. What about removing tools?

Koko: Good question — the trap here is conflating allowed-tools with disallowed-tools. Allowed-tools pre-approves. Disallowed-tools actually removes a tool from the skill's reach entirely. Different jobs, different fields.

Chris: And for session management — plan mode is for large multi-file architectural changes, direct execution for small well-scoped ones, and the Explore subagent isolates a verbose discovery phase.

Koko: Right. In CI/CD, the flag that stops the job hanging is dash-p or dash-dash-print for non-interactive mode, and dash-dash-output-format json with dash-dash-json-schema gives machine-parseable output for inline comments. Plus — always have an independent instance review what the first session generated.

Chris: The slash commands people mix up: slash-memory versus slash-context. Slash-memory opens and lists which memory files are in play. Slash-context reports which files actually loaded into the session. And slash-compact reclaims context in a long session.

Koko: The exam will put those two side by side. Memory equals what files are configured. Context equals what actually loaded. Don't swap them.

Koko: So here are the instincts to carry out the door. Shared behavior belongs at project level. Scattered-file conventions belong in rules files with path globs, not per-directory CLAUDE.md files. New command work goes in skills, not commands. Allowed-tools approves, disallowed-tools removes. Non-interactive CI needs dash-p. Independent review catches what the first session missed. And slash-memory versus slash-context is almost certainly on your exam.

Chris: Clean list. That covers the whole domain.

Koko: It does. You've been thorough throughout this whole series — you're going in prepared. Keep reinforcing these with the flashcards and the practice quiz at KokoAI Academy — that's koko-knows-dot-A-I. You've put in the work. Go get it.