Claude Code Operation
Claude Code Operation is 3.1% of the CCDV-F blueprint, one or two of the 53 scored questions. It sits below the configuration layer, covering how a session is actually driven: managing the working context, turning repeated instructions into reusable commands, wiring external connections at the right scope, and scoping work so it can be verified.
Written by Kiran Manne
3.1% of the CCDV-F blueprint, which is roughly 2 questions of 53. It sits inside Claude Code, worth 3.1% in total.
Claude Code Operation carries the whole of its domain's 3.1 percent, which is one or two of the 53 scored questions. Since the parent domain already covers where instructions and settings live and how permissions resolve, the useful way to prepare the sub-skill itself is one level down: what a person actually does during a session, and what the tool does in response.
Three operating surfaces account for most of it. The session surface governs what the model is currently holding, which is a working context that grows with every file read and command run, plus explicit controls for resetting it, condensing it, or picking a previous session back up. The command surface is how repeated work becomes reusable, through named commands stored in the project alongside the code they act on. And the connection surface is how external systems get wired in, at a scope that decides whether a teammate inherits the wiring or has to repeat it.
Underneath all three sits a habit the exam keeps rewarding: scoping the task and verifying the result, rather than issuing a broad instruction and reviewing a large diff afterwards.
What the exam tests here
- Managing the working context during a session: when to reset it, when to condense it, when to resume a previous one
- Turning a repeated instruction into a named command stored with the project
- Choosing the scope at which an external connection is registered, and who inherits it
- Whether a piece of work belongs in the current conversation or in a delegated one with its own context
- Operating with a plan-first posture on changes that are hard to review after the fact
The working context is a resource you manage
Every file read, command run and result returned accumulates in the session, and quality falls before any limit is reached. Two controls address different situations.
Resetting clears the accumulated history and starts clean, which is what an unrelated next task wants: carrying over the previous task's files hands the model plausible but irrelevant material to reason from. Condensing summarises what has happened and continues from the summary, which is what a single long task wants when it is not yet finished.
The operating tell is whether the next thing you type depends on what came before. If it does not, reset; if it does and the session is heavy, condense. Sessions can also be picked up later rather than restarted, which is worth knowing before you paste a long brief twice.
Repeated instructions become commands
Anything you have typed three times belongs in a file. A named command is a markdown file placed in the project's command directory, invoked by its filename with a leading slash, and able to take arguments from the invocation. Because it lives in the repository it is reviewed, versioned and shared, which is the difference between a team convention and one person's habit. The user-level equivalent lives in the home directory and travels with the person rather than the project.
The distinction to hold onto is that a command is a prompt you choose to run, whereas the project instruction file is loaded whether you want it or not. Occasional workflows belong in commands; standing constraints belong in the instructions.
Connections have scopes, and the scope is the decision
External systems are wired in as servers the tool can call, and the registration can be personal, project-shared, or user-wide. That choice determines who gets it.
A project-scoped registration lives in a file at the repository root and reaches everyone who checks the project out, which is right for a service the whole team needs and wrong for anything carrying a personal credential. A local registration stays on one machine.
The consequence is a security one as much as a convenience one. A shared registration is code review's business, since it tells everyone's session to talk to an endpoint, and a checked-out project can carry a registration a session will pick up on its own.
Scope the task, then verify it
The reliability difference between sessions is mostly the operator. A request naming the files, stating the constraint and saying what a finished result looks like produces a reviewable change. A broad instruction produces a large diff that is expensive to check and tempting to accept.
Two habits raise the floor further. Ask for the approach before the edit when the change is structural, which is cheap to redirect and far cheaper than reviewing the wrong refactor. And give the session a way to check itself (a test command, a type check, a build) so correctness is established by something executable rather than asserted in a summary. Push reading-heavy investigations into a separate context so the main session keeps its focus.
Where candidates go wrong
Trap: continuing a finished task in the same session
Momentum makes it natural to type the next unrelated request into the conversation you are already in, and the accumulated history then works against you. Files from the previous task stay visible and get treated as relevant, earlier decisions constrain suggestions that should be unconstrained, and every request pays for context it does not use.
The operating answer is to reset between unrelated tasks and to condense only within one. A scenario describing a session that keeps referring back to work finished an hour ago is describing this, not a model defect.
Trap: putting a workflow in the project instructions because it worked once
The instruction file loads every session, so anything added to it competes for attention on every task including those it does not apply to. A long file of situational procedure makes the important constraints harder to find and gets followed inconsistently, which then reads as unreliability.
Keep the standing rules there, short and genuinely universal, and move situational procedures into named commands invoked when they apply. Where a rule must hold without exception, the mechanism is enforcement rather than instruction.
Trap: assuming a checked-out project is inert
A repository carries operating configuration as well as code: instruction files, registered connections, hooks and commands. Opening a session inside an unfamiliar project therefore adopts whatever that project declares, which makes it a supply-chain surface rather than a documentation surface.
The habits that follow are to review those files as part of reviewing the code, to keep automated runs on a restricted permission set, and to prefer a mode that skips discovery when the checkout is not one you trust.
Common questions
How many CCDV-F questions cover Claude Code Operation?
It carries its domain's entire 3.1 percent, so one or two of the 53 scored questions. That is a small return on a tool with a very large surface, which is the argument for learning how it is operated rather than memorising its settings keys.
When should I reset the session instead of condensing it?
Reset when the next task does not depend on the last one, because leftover files and decisions will be treated as relevant and quietly steer the work. Condense when a single task is still in progress but the session has grown heavy, so the thread of what you are doing survives while the bulk of the transcript does not.
What belongs in a named command rather than in the project instructions?
Anything situational. Instructions load on every session and should hold only rules that apply to every task, kept short enough to actually be read. A procedure you follow when a specific job comes up is better stored as a command, because then it runs when you invoke it and costs nothing the rest of the time.
Is registering an external connection at project scope safe by default?
It is a shared decision rather than a personal one, so it belongs in review. Project-scoped registration reaches everyone who checks the repository out, which is the point for a service the team relies on and a problem for anything personal or credential-bearing. The same reasoning runs in reverse: a project you have cloned may declare connections your session will pick up.
Practise this
The CCDV-F bank covers every sub-skill in the blueprint, weighted the way the real paper is. Free sample questions need no account.
Free CCDV-F questions