5.2 Writing Effective System-Level Instructions

System-level, or Project, instructions set the standing behavior for Claude across an entire workspace. That single fact is why getting them right matters so much more than getting one individual prompt right: a good prompt helps one conversation; a good system-level instruction helps every conversation that will ever happen in that Project, today and for as long as the Project exists. This is the same discipline as good prompting (the craft covered in Domain 1) — just applied at a larger scope, once, instead of re-applied by hand in every message.

Because the payoff compounds across every future conversation, it's worth being deliberate rather than dashing off a quick sentence. A rushed, vague instruction costs you a little bit of quality on every single chat in the Project, forever, until someone notices and fixes it.

Effective system-level instructions consistently share four traits. Specific about role and goal means naming who Claude is acting as and what it's trying to accomplish — "You are a support-reply assistant for our billing team" gives Claude an actual identity to operate from, instead of leaving it to guess. Explicit about format and tone means stating exactly how the output should look and sound — "Reply in under 120 words, warm and professional, never promise refunds" removes the guesswork about length, register, and hard limits. Clear on boundaries means spelling out what Claude should and shouldn't do, and when it should defer to a human rather than answer on its own. Concise and high-signal means every one of those rules is stated plainly, without burying it in filler.

Notice that these four traits are really answers to four separate questions a vague instruction leaves open: who is Claude supposed to be, how should the output look, where are the lines, and is any of this actually going to survive being read. An instruction that nails all four leaves very little room for Claude to improvise its way into an inconsistent or unwanted response.

There are exactly two ways an instruction fails, and they sit at opposite ends of the same spectrum. The first is writing vague instructions — "be helpful" sounds reasonable and is completely useless, because it doesn't actually constrain any behavior. Claude has nothing specific to check its output against; every response technically satisfies "be helpful," which means the instruction did no work at all.

The second failure mode is the opposite instinct taken too far: overloading instructions with so much detail that the handful of rules that really matter get buried in a wall of text. It feels responsible to specify everything, but a instruction with forty edge cases and three genuinely critical rules is, in practice, an instruction where those three rules are easy to miss — length is not the same thing as signal. Concise and high-signal beats exhaustive.

Anthropic's Agent Skills concept extends this exact same idea in a different direction. A Skill is a reusable instruction set that packages how to do a recurring task, authored once and reused every time that task comes up again — conceptually, that's the identical move as a system-level Project instruction: durable, reusable guidance instead of re-explaining the task from scratch every time. The difference is scope, not idea. A system-level instruction governs an entire workspace; a Skill packages one specific recurring task, potentially usable across many workspaces.

Seeing the parallel matters for the exam because a question might describe either scenario — "we keep re-explaining how to format this weekly report" or "we keep re-pasting the same tone guidance" — and both point at the same underlying fix: capture the recurring guidance once, durably, instead of restating it by hand each time it's needed.

The previous note draws a parallel between Skills and system-level instructions: both are reusable guidance instead of re-explaining a task from scratch every time. The exam expects more than the analogy, though — it expects you to know what a Skill concretely is. A Skill packages a repeatable procedure. Anthropic bundles ready-made Skills for common document work: spreadsheet construction, Word drafting, slide-deck assembly, and PDF handling. Ask Claude to turn a messy data dump into a formatted workbook, and you're invoking one of these built-in Skills whether or not you'd ever use that term for it.

That last row is the detail worth memorizing: a Skill isn't switched on per workspace the way instructions and knowledge are. It's simply available everywhere the account is used, the moment it's relevant, with no setup step inside any individual Project.

Custom Skills are where this gets genuinely useful for a team, and it's worth working through why a team would build one instead of just writing a sharper system-level instruction. The dividing line is procedure versus behavior. A system-level instruction is well suited to broad behavioral guidance — tone, role, boundaries, format defaults — the kind of thing you can state in a sentence or two. A custom Skill earns its keep when the task is a repeatable, multi-step procedure with its own internal logic, one that's awkward to compress into a paragraph of instruction text without burying the rules that actually matter (the exact bloat problem from note 5.2.3).

Take a finance team closing the books every month. Their Project's system-level instruction might read: "You are a financial-close assistant. Be precise, flag any unreconciled variance over $500, and never finalize a number without a cited source." That's behavior — a standing rule that governs everything in the Project. The actual close procedure is a different kind of thing entirely: pull the trial balance, reconcile it against three named subledgers in a fixed order, apply a specific rounding convention, and produce a standardized handoff memo. Cramming that sequence into the instruction would bloat it well past high-signal. Packaging it as a custom Skill instead keeps the instruction lean and makes the procedure available automatically, in any Project the team touches — not just the one workspace where someone happened to paste the steps.

From a learner's seat, a Skill and Project knowledge can look identical — you ask, Claude delivers correctly, and both feel like "Claude just knows how to do this." The way to tell them apart: would the same behavior still happen in a brand-new, empty Project with nothing uploaded? A Project with a style guide uploaded, where Claude drafts memos in house style, is project knowledge — ask the same thing in a different Project with no upload, and the house style vanishes. Claude reliably turning a messy paste into a formatted Excel workbook, in that Project and in a completely unrelated plain chat, is a Skill — it travels with the account, not with any one workspace.

Task Statement 5.3 questions tend to present either a badly written instruction (too vague or too bloated) and ask what's wrong with it, or a well-written one and ask which trait it demonstrates. The reliable habit is to check a candidate instruction against all four traits — role/goal, format/tone, boundaries, conciseness — and notice which one is missing rather than reacting to how confident or thorough the instruction sounds.

• •Vague instructions ("be helpful") that sound reasonable but don't constrain behavior — always wrong when the question asks what makes an instruction effective.
• •Overloaded, detail-heavy instructions that bury the key rules — more detail is not the same as more effective; concise and high-signal wins.
• •System-level instructions are the same prompting discipline as Domain 1, applied at workspace scope — don't treat them as an unrelated skill.