CCAO-F Glossary - Prompting and Task Execution

Quick-lookup definitions for every domain, with exam context and links back to the lesson that covers each term.

System Prompt: The instruction set once, before a conversation starts, that shapes how Claude behaves for every message that follows — in claude.ai this is a Project's custom instructions field; in the Console it's a dedicated field separate from the conversation. It's the right place for a role, constraints, and output-format rules: things that should hold for the whole conversation, not just one message. The actual task-specific request (the document to summarize, the customer's complaint) belongs in the message instead.; Exam context: The exam tests the boundary between what belongs in the system prompt (constant across turns: role, tone, rules) versus the message (variable per turn: the specific task). A common distractor pastes the whole task into the system prompt or reaches for a sampling setting like temperature to fix what is really a missing-role problem.; See also: 1.1 System Prompts and Giving Claude a Role
Role Statement: A short, specific sentence in the system prompt that gives Claude a persona and perspective to write from, e.g. "You are a customer service specialist for Acme Outdoors." It anchors every later instruction to a consistent lens, which is often the single highest-leverage fix when output feels generic or inconsistent in tone from one run to the next.; Exam context: Watch for distractor answers that add more descriptive adjectives about tone ("warmer," "more on-brand") instead of a concrete role — more prose description is not more precision. A role statement fixes tone drift; it does not fix structural/format inconsistency, which calls for examples instead.; See also: 1.1 System Prompts and Giving Claude a Role
Multishot Prompting: Giving Claude a small number (three to five) of diverse, worked examples of the exact output wanted, each wrapped in its own <example> tag, rather than adding more written instructions. It is the standard fix when detailed plain-language instructions alone still produce inconsistent formatting, tone, or judgement calls, because showing a pattern is more reliable than describing one in prose.; Exam context: Diversity matters more than volume: one repeated pattern risks Claude locking onto an overly narrow rule, and a huge pile of edge cases wastes space without proportional benefit. A common distractor is "one long example that repeats the same pattern" — that is not diverse multishot prompting.; See also: 1.2 Multishot Prompting for Consistent Output
Worked Example: A single concrete instance of the desired input/output pattern, wrapped in an <example> tag, used inside multishot prompting. Worked examples show Claude a concrete pattern to match — structure, format, level of detail — which is a different fix from a role statement, which gives Claude a consistent perspective rather than a structural pattern.; Exam context: Exam scenarios often describe output that is inconsistent in structure or format despite detailed written instructions; the correct fix is adding worked examples, not writing yet another paragraph of instructions.; See also: 1.2 Multishot Prompting for Consistent Output
XML Tags: Structural markers like <context>, <instructions>, <examples>, and <input> that Claude is trained to recognise, used to separate the distinct parts of a longer, multi-part prompt so it doesn't confuse one section for another. Tag names are a convention, not a required schema — any consistent, clearly-labeled tag name (e.g. <background>, <document>, <question>) works, as long as sections are unambiguously separated.; Exam context: A classic exam scenario: a prompt mixes context, instructions, examples, and a variable query as unlabeled paragraphs, and Claude sometimes responds to a worked example as if it were the real input. The fix is wrapping each part in its own tag — not rewording the instructions or reordering the unlabeled text.; See also: 1.3 Structuring Prompts with XML Tags
Audience Framing: Telling Claude the reader's role, background, and purpose for reading (e.g. "a general donor with no statistics background who wants to know if the program worked") so it can choose appropriate vocabulary, depth, and framing. Simply asking Claude to "make it simpler" or shorten a passage often produces a version that is shorter but still technically dense, because it doesn't tell Claude who the actual target reader is.; Exam context: The exam distinguishes shortening/simplifying instructions (which can preserve jargon) from genuine audience framing (which restates findings in plain, practical language for a named reader). Expect scenarios about adapting the same technical content for a general newsletter audience versus a technical evaluator.; See also: 1.4 Adapting Prompts to Audience and Task Type
Task Type Matching: Choosing a different prompting approach depending on what kind of task is being requested, since the same generic style doesn't serve all four common task types equally well: analysis benefits from explicit criteria up front, research benefits from cross-checking and sourcing instructions, drafting benefits from examples and a clear audience/role, and brainstorming benefits from generating volume and range first, with evaluation/narrowing kept as a separate, later step.; Exam context: A frequent distractor applies tight evaluative criteria to a brainstorming request, which narrows output prematurely instead of generating the range asked for — the exam tests recognising that evaluation and generation are different modes best kept separate for brainstorming specifically.; See also: 1.4 Adapting Prompts to Audience and Task Type
Task Decomposition: Breaking a complex, multi-part request into an explicit, ordered sequence of smaller sub-tasks, either as clearly numbered steps within one prompt or as separate messages, instead of asking Claude to do everything at once. A single prompt asking for five different things at once often produces output that does all five shallowly or quietly drops one; decomposition fixes this by giving each part its own clear turn.; Exam context: The exam tests recognising the signal for decomposition — sequentially dependent sub-tasks, or a request spanning genuinely different kinds of work — versus closely related, non-dependent requests that are fine as a single prompt. A distractor is listing sub-tasks without ordering them, which doesn't solve the dependency problem.; See also: 1.5 Task Decomposition for Complex Requests
Sequential Dependency: The situation where a later sub-task genuinely needs the actual output of an earlier sub-task, not just the original input, to be done correctly — e.g. a stakeholder email that must reference the specific trends an analysis step found. Sequential dependency is the clearest signal that a request should be decomposed into ordered steps rather than handled in one shot.; Exam context: Exam scenarios describe an output (like an email) that doesn't actually reference results from an earlier part of the same undecomposed request. The fix is ordering the steps so the dependent step is built on the completed earlier output — not adding a role statement or simply reordering a single-message request.; See also: 1.5 Task Decomposition for Complex Requests
Across-Message Decomposition: One of two ways to decompose a complex task: sending each sub-task as a separate message (analysis first, then a summary based on the reviewed analysis, then an email draft) rather than numbering all the steps inside one prompt. It is slower than in-prompt numbered steps but lets you catch a wrong turn early, before it propagates into every later step — worth the extra time when an early mistake would be expensive to unwind.; Exam context: A common distractor assumes decomposition always means separate messages; numbered steps inside a single well-structured prompt are also valid decomposition and are often more efficient when steps don't need independent review between them.; See also: 1.5 Task Decomposition for Complex Requests