Claude Code Configuration & Workflows

Koko: Here is the one instinct that unlocks almost every question in Domain 2: every capability you can give a coding agent falls into exactly one of three buckets. Always loaded, summoned on demand, or no human in the loop. If you can sort a capability into its bucket before you do anything else, the right answer usually follows automatically.

Sam: Okay, three buckets. Can you make those concrete? Because right now that sounds abstract.

Koko: Sure. Think of it like a kitchen. Always loaded is the spice rack — it is right there every single time you cook, no decision required. In a coding agent that is the project memory file, the thing the agent reads at the start of every session. It holds the context that should never be missing.

Sam: So the memory file is always in the pan, so to speak.

Koko: Exactly. Now summoned on demand — that is the specialty ingredient you pull from the back of the pantry only when the recipe calls for it. Skills, subagents, workflows — they are not loaded by default. A task comes in, the agent decides it needs them, and only then are they pulled in.

Sam: That makes sense. And the third bucket, no human in the loop?

Koko: That is the slow cooker running while you sleep. The agent is inside a CI/CD pipeline, completely headless, no one watching. It runs, it produces output, it exits. Nobody is clicking approve at two in the morning.

Sam: Right, the nightly pipeline. So when I see a question describing a need, I am just asking which bucket does this belong in?

Koko: That is the move. And once you have sorted it, you layer two habits on top. Least privilege for tools — the agent only gets the permissions the current task actually requires, nothing extra. And credentials come from named secrets, never hard-coded into the config.

Sam: Okay, I want to push on that. Why not just give the agent broad permissions up front and be done with it? Less configuration overhead, right?

Koko: That is the trap. And it is a very comfortable trap. The reasoning sounds efficient but it violates the whole point of least privilege. A coding agent with broad permissions that gets something wrong — or gets misused — can do broad damage. A support agent that only needs to read a ticket log should not also have write access to the deployment pipeline.

Sam: So the exam is testing whether I reach for the scalpel or the sledgehammer.

Koko: Perfectly put. And the same logic applies to credentials. The tempting shortcut is to paste a token directly into the configuration file where you can see it and verify it quickly. The correct move is to reference a named secret. The agent reads the value at runtime from the secret store — the literal string never lives in the config.

Sam: Because if the config leaks, the credential does not.

Koko: Exactly. So coming back up: Domain 2 is about configuring and steering an agent that lives inside a code repository, and it is about twenty percent of the exam. The questions look varied on the surface — memory files, subagents, pipelines, permissions, secrets — but underneath they are almost always asking you to do three things. Sort the capability into its bucket, apply least privilege, and keep credentials in named secrets. That sorting instinct is the thread that runs through everything else in this domain.

Sam: Always loaded, summoned on demand, or headless in a pipeline — and then least privilege and named secrets on top. Got it. That actually makes this domain feel a lot more manageable.

Koko: That is exactly the feeling we are going for. Now let us go deeper into each bucket, starting with what always-loaded memory actually means in practice.

Koko: So we just covered how Claude Code gets configured at the environment level. Now let's talk about what rides along inside every single session — the project memory file.

Sam: This is the file the agent reads at the start of every session, right? So it always knows where it is.

Koko: Exactly. Think of it as the first page of the onboarding binder you hand a brand-new contractor on day one. What this place is, the build and run commands, and the one habit they must never forget. That's it.

Sam: Short by design.

Koko: Short by necessity. Because every line in that file costs context. It loads on every session, which means it's competing for space with the actual question the developer is asking.

Sam: So I'd be tempted to just put everything in there — all the runbooks, all the procedures. One place, always available.

Koko: That's the trap. Treating the memory file like a wiki. You dump every runbook inline, the always-loaded context bloats, it crowds out the real question, and you're paying more per message for information the agent rarely needs.

Sam: So the fix is linking, not pasting.

Koko: Right. High-value, always-relevant orientation at the top. Long procedures get a link so they're pulled in only when needed. The exam instinct here: lean memory file, links to the rest.

Sam: Is there only one memory file per project, or can you have multiple?

Koko: It's layered. There's a personal user level that follows you across all projects, a shared project level that's checked in with the repo, and then directory-level files that only apply within a specific subtree.

Sam: So if I'm working on a file inside a subdirectory, the directory-level rules for that folder kick in on top of everything else?

Koko: Additive and overriding. More specific layers add to the broader ones, and when there's a conflict, the more specific layer wins. But — and this is important — it does not wipe out the layers above.

Sam: Oh, so I can't just write a nested file and assume the root file no longer applies.

Koko: Correct. The nested file overrides where they conflict, it doesn't replace. Think of it as a short onboarding one-pager that links to the full manual — not the manual stapled to the front of itself.

Sam: And imports let you pull in the longer stuff only when the session actually needs it.

Koko: That's the instinct: scope each rule to the narrowest layer that actually applies, and import long procedures rather than inlining them. You keep the always-loaded content lean and let the rest come in on demand.

Sam: What makes an instruction actually good? Like, what separates a useful rule from a useless one?

Koko: Three things: specific, actionable, and it names the non-obvious failure mode — the thing the model could not infer just from reading the code.

Sam: Give me an example. What does a bad one look like?

Koko: Something like 'be careful with deploys' or 'follow best practices.' The model has nothing to act on. That's a motivational poster, not an instruction.

Sam: And a good one?

Koko: Something like: 'A green succeeded status only means the request was sent — confirm the real result in the response's status code.' That's the symptom, the false signal, and the real check. It vaccinates every future session against re-learning it the expensive way.

Sam: The trap that bit us, written down so it can't bite again.

Koko: Exactly. And then you scope it. Not every rule is relevant everywhere. A deploy check lives in a nested memory file for the deploy subtree, not in the root file loading on every session.

Sam: Like a local rules sign on one workshop door instead of a vague poster in the lobby.

Koko: That's the analogy. The exam instinct: effective means specific plus actionable plus a stated failure mode, scoped to exactly where the agent is editing the code it governs. The blast radius of the rule should match the scope of the rule.

Sam: So vague rules anywhere, and over-scoped rules everywhere — both are traps.

Koko: Both waste context and both give the model nothing useful to act on. Get those two right and your memory files are actually doing work.

Koko: So we have been talking about how agents know what to do and what they are allowed to touch. Now let's talk about how you package the capability itself. And the first building block is a skill.

Sam: What exactly counts as a skill?

Koko: A skill is knowledge or a procedure the agent loads when a task actually calls for it. It is summoned on demand, not sitting in memory all the time. Think of it like a reference card you pull from a drawer for a specific job — you do not tape every card to your desk.

Sam: Right, because if every card is on the desk it gets crowded fast.

Koko: Exactly. And that is the instinct the exam is looking for — when you need knowledge or a procedure occasionally, package it as a skill so it loads on demand and your always-on context stays lean.

Sam: Okay, so the trap would be just — pasting that procedure into the always-loaded memory file so it rides along every single session?

Koko: That is the trap precisely. It rides along even when it is completely irrelevant, bloating the context every time. Lean always-on memory, rich on-demand skills.

Sam: What about when the capability is more than a procedure — like a whole research task?

Koko: Then you are probably looking at a subagent. A subagent is a separate worker with its own isolated context and its own least-privilege tools.

Sam: Why does the isolation matter so much?

Koko: Two reasons. First, a subagent researching one topic cannot be derailed by another's tokens flooding in. Second, the main agent gets back a clean summary rather than everyone's raw scratch work. Think of it like delegating a self-contained task to a specialist who reports back a tidy answer — not their entire desk.

Sam: And the least-privilege tools part — that is about not handing the subagent more access than its narrow job actually needs?

Koko: Exactly. The instinct is reach for a subagent when you need context isolation or specialization, and give it only the tools its specific job requires.

Sam: So I guess the trap is doing everything in one big context and just giving every worker every tool available?

Koko: You blow the context window and you widen the blast radius of any single mistake. One bad move can affect everything. Isolated workers with narrow tools keeps failures small and contained.

Sam: Okay, so we have skills and subagents. What is the third option?

Koko: Workflows. And this is where the exam really wants you to sort clearly. A workflow is deterministic orchestration — code-driven control flow with loops, branches, fan-out — where you need the sequence guaranteed, not model-chosen.

Sam: So the model does not get to decide what step comes next.

Koko: Right. When the order has to be fixed and repeatable, that is a workflow. Not a prompt, not a subagent.

Sam: Let me try to land the rule of thumb. Skill when I need knowledge occasionally, subagent when I need isolation or specialization, workflow when I need the steps to run in a fixed order.

Koko: That is the whole thing. Match the mechanism to the need.

Sam: And the trap is using one hammer for all three — like cramming a guaranteed sequence into a prompt because prompts feel easier.

Koko: Or stuffing a reusable procedure into a subagent when a skill would do it cleanly. The exam is testing whether you recognize which need you are actually facing before you reach for a tool. Each mechanism exists for a reason — respect the distinctions and you are thinking like an architect.

Koko: So here is a decision every coding agent workflow forces on you: does the agent just go edit the code, or does it propose a plan first and wait for your approval before touching anything?

Sam: My instinct is just let it execute. Faster, right?

Koko: Sometimes, yes. For a one-line copy fix — a typo in a string — direct execution is the right call. But picture a twelve-file refactor that is hard to unwind. If the agent charges in and gets the direction wrong, you are now untangling a sprawling diff instead of reading a short paragraph on a screen.

Sam: So plan-first is like sketching the blueprint before pouring the concrete.

Koko: Exactly that. A plan-first pass is a cheap checkpoint placed exactly where a mistake would be most expensive. You approve the approach in words before a single file changes.

Sam: So how do I decide which mode to reach for?

Koko: Two questions: how reversible is it, and what is the blast radius? Trivial and contained — execute. Risky, broad, or ambiguous — plan, then execute. That is the instinct the exam rewards.

Sam: And the trap is being too consistent in either direction?

Koko: Exactly. Always planning wastes time on a typo. Always executing turns a sprawling change into an expensive mess with no checkpoint anywhere in it.

Sam: Okay, new scenario. The agent is working on a big codebase and needs to fix a function. Does it just read all the files to be safe?

Koko: That is the tempting move and it is the wrong one. Reading everything burns the context window and buries the signal you were actually looking for.

Sam: So what does it do instead?

Koko: It works like a funnel. Glob filenames to find where things live. Then content-search to find which files actually mention the thing you care about. Then read only the relevant slice. Then edit. Each tool has a lane.

Sam: It is like using a library catalog and an index to find the right paragraph instead of photocopying the whole building.

Koko: That is it. Narrow before you read. Targeted reads are cheaper and more accurate than loading a whole repo into context.

Sam: So the exam instinct is: match the tool to the question and investigate as a funnel — find, search, read, edit, in that order.

Koko: Exactly. And the trap is skipping the funnel because broad reading feels thorough. It is not thorough, it is expensive.

Sam: Alright, now we are talking pipelines. The agent runs with no human in the loop at all — reviewing a pull request, generating tests, triaging an issue. What changes?

Koko: Two things change. First, autonomy has to be bounded even more carefully. Least-privilege tools, and anything irreversible still needs a gate — because nobody is watching in real time to catch a bad call.

Sam: And second?

Koko: Credentials. They must come from the pipeline's named secret store. Never hard-coded, never echoed into logs.

Sam: I mean, I can see someone thinking — it is only CI, it is internal, I will just drop the key in there for now.

Koko: And that is precisely the trap. Headless mode is not a relaxed environment — it is the one where a bad call has zero human backstop. Loosening least privilege or hard-coding a credential because it feels like a back-room pipeline is how you create your worst incident.

Sam: So the instinct is: automate the judgment, keep the guardrails exactly as strict as they would be with a human watching.

Koko: That is the line. The agent emits structured output, a script acts on it, a verdict gates a merge or opens a follow-up automatically — all fine. But the security posture does not get to relax just because the human stepped out of the room.

Koko: Alright, let's do some exam-style scenarios. These are the ones where the exam gives you a messy real-world situation and you have to pick the right fix. First one: a team's project memory file has ballooned. It started as a clean orientation doc and now it's a full wiki — deploy runbooks, rare emergency procedures, everything pasted inline. The agent has gotten noticeably slower and more expensive, and it's actually starting to miss the point of simple questions. What's your instinct?

Sam: Honestly my first thought is just increase the context window. Give it more room to hold all that information.

Koko: And that is exactly the trap. Here's why it's wrong. The memory file isn't just sitting there waiting to be called — it's loaded on every single message, every turn. So every line in that file costs tokens every time, whether the agent needs it or not. Making the window bigger doesn't fix the waste, it just lets you waste more.

Sam: Oh, so the problem isn't capacity, it's what's always present.

Koko: Exactly. Think of it like leaving every manual for every appliance you own open on your kitchen counter permanently. You don't need the dishwasher repair manual while you're making coffee. The fix is to keep only what's always relevant at the top — the high-value orientation, the critical conventions — and then link or import the long runbooks so they load on demand, only when that procedure is actually needed.

Sam: So those rare runbooks become summoned-on-demand knowledge instead of always-on memory.

Koko: Right, and that connects directly back to the sorting rule we covered. Rare procedures are exactly what skills and linked docs are for. If something only matters when you're doing a deploy, it doesn't belong in memory that loads during a routine code question. The exam will test whether you reach for more capacity or whether you reach for better structure. Better structure is always the answer.

Koko: Second scenario, and this one is a classic multi-part question. A team comes to you with three things they want to add. One: a reusable procedure for how they write database migrations — the agent should follow it whenever it touches migrations. Two: a way to analyze a large, complex dependency graph without it polluting the main agent's context. Three: a nightly job that runs the exact same fixed sequence of steps every time. Three needs. What goes where?

Sam: Okay. The migrations procedure feels like it should just live in memory since it's something the agent should always know.

Koko: Close, but there's a sharper answer. It's not always-relevant — it's relevant specifically when the agent is touching migrations. So it's on-demand knowledge scoped to a path. That's a skill, or a path-scoped instruction. It loads when migrations are in play, not on every single message.

Sam: Got it. Scoped, not global. What about the dependency graph analysis?

Koko: That one's about isolation. A big dependency graph is context-heavy and you don't want that complexity bleeding into the main agent's working memory. So you spin up a subagent — an isolated worker with narrow tools — it does the analysis and reports back a summary. The main agent gets the answer, not the mess.

Sam: Like sending someone to do research in a separate room and handing you a one-page brief.

Koko: Perfect analogy. Now the nightly job?

Sam: That one I think I've got. Fixed sequence, same every time — that's a workflow. Code-driven, not the model deciding the order.

Koko: Exactly right. The moment you need guaranteed order and repeatability, you don't want a model making judgment calls about what happens next. The steps are defined in code. The model is not the orchestrator there. So across those three: path-scoped skill, isolated subagent, code-driven workflow. One question, three different mechanisms, and the skill the exam is testing is whether you can match each need to the right one without defaulting to the same hammer for all three.

Sam: The trap being to just throw everything into memory or assume the main agent can handle it all inline.

Koko: Every time. If you walk out of this domain knowing one thing, know that the question is never just 'can it handle this' — it's 'where does this actually belong.'

Koko: Alright, we made it to the end. Before you walk into that exam, let's do one fast lap through the instincts that actually answer the questions. Ready?

Sam: Ready. Hit me.

Koko: Number one, and this is the big one: sort every capability into always loaded, summoned on demand, or no human in the loop. That single question answers most of this domain.

Sam: Sort first, then the answer basically falls out.

Koko: Exactly. Number two: the project memory file is always loaded, so keep it lean and high-value. Link the long stuff, don't paste it. It's an onboarding one-pager, not a wiki.

Sam: I keep wanting to dump everything in there, just to be safe.

Koko: That's the trap. More is not safer there — it's noise. Every token in that file is always being carried, so every weak line costs you.

Sam: Got it. Earn your place in the memory file.

Koko: Number three: a good instruction is specific, actionable, and names the non-obvious failure mode. And it's scoped to the paths it governs — not sprayed everywhere.

Sam: Scope creep in instructions is its own bug.

Koko: Right. Number four: skill equals on-demand knowledge, subagent equals isolated context plus narrow tools, workflow equals guaranteed order. Match the mechanism to the need, not just to what feels powerful.

Sam: So if I see a question about guaranteed sequencing, I'm reaching for workflow, not subagent.

Koko: Every time. Number five: decide between plan mode and execute mode by asking about reversibility and blast radius. Big blast radius or irreversible action — you stop and check before you go.

Sam: Reversibility is the trigger. I like that as a heuristic.

Koko: Number six: investigate a codebase as a funnel — find, then search, then read, then edit. Never slurp whole directories. The exam will offer you the temptation to just read everything at once.

Sam: And that's expensive and sloppy.

Koko: Expensive and unnecessary. And number seven: headless CI means least privilege, hard gates on irreversible actions, and secrets pulled from the named store — not from environment variables you set by hand, not from plain text. Exactly as strict as if a human were watching. Maybe stricter.

Sam: Because no one is watching is precisely when things go sideways.

Koko: That's the whole instinct. Now here's the through-line that ties all seven together: this domain is a sorting exercise plus two safety habits. Least privilege and named secrets. When a question describes a capability, name its bucket first. Always loaded, on demand, or no human in the loop. Once you have the bucket, the rest of the answer is almost mechanical.

Sam: Sort the bucket, apply the safety habit, done. That's a cleaner frame than I had going in.

Koko: That's what we built this whole lesson toward. You're not just memorizing rules — you're building the instincts that make an agent a teammate instead of a liability. Keep drilling with the flashcards and the quiz at KokoAI Academy on koko knows dot A I, and you will walk into that exam ready.

Sam: I feel good. Like actually good, not just hopeful.

Koko: You put in the work — go show them.