The Five Components of an Effective Prompt (1.1)
The briefing mindset: prompt Claude the way you would brief a brilliant new colleague who has no context on your company, project or standards until you supply it. A complete business prompt has five parts:
- Task: a verb plus a deliverable ("draft a one-page project update for the steering committee"), never "help with my project".
- Context: the background Claude cannot know: audience, purpose, what has been decided, constraints.
- Source material: attach or paste the actual inputs (report, notes, data). A from-memory description adds errors the real document does not have.
- Output specification: format, length, tone, structure ("three bullets per workstream, neutral tone, under 400 words").
- An example, when standards matter: one sample document in the house style (your organisation's own style rules) works better than three paragraphs describing the style.
On the exam: count the components. The right answer supplies the missing one; the wrong options improve the wording while the missing component stays missing. "Technical tasks" at this level means briefing Claude for a spreadsheet formula or a first-draft technical document; the tested skill is always the brief, never the implementation.
Role and Audience Framing (1.1)
- Role framing: opening a prompt from a named role ("as an HR communications specialist...") shapes vocabulary, tone and priorities. Even a single sentence makes a difference.
- Audience naming changes the output more than most instruction tweaks: the same analysis briefed for the board and for the project team should read differently, and Claude does that shaping when told who is reading.
- State the motivation: explaining why an instruction matters helps Claude deliver a more targeted response.
- What specificity buys: a vague prompt produces generic output that needs heavy rework. A minute spent on the brief saves a rework cycle. The recurring wrong answer is the one-line prompt offered as acceptable "because Claude will figure it out".
The Four Decomposition Techniques (1.2)
Complex work gets Claude's best output when it is structured into pieces Claude can do properly, one at a time. Four techniques, from simplest to most complex:
| Technique | Use it when |
|---|---|
| Numbered steps in one prompt | Connected parts in a known order, with no check needed between steps |
| Staged prompting, one conversation | Connected parts where you must check a result or decide before the next part: outline first, then sections |
| Plan-first prompting | The right structure is genuinely unclear |
| Separate conversations | Genuinely independent deliverables |
Choosing: independent deliverables → separate chats. Connected parts, known order, no check between steps → numbered steps in one prompt. Connected parts that you must check or decide on before the next part → one conversation, staged, with a break at each check. Unclear structure → plan first, then choose for each part of the approved plan. Both failure modes appear as wrong options: one very large prompt that asks for everything (attention spreads unevenly, some parts given little attention) and connected work fragmented across chats (each new chat has lost the outline and tone decisions the last one built). Plan-first offered where the structure is already agreed is a small unnecessary extra step, not the answer.
Carrying Context Forward (1.2)
The rule: a new conversation does not automatically contain another conversation's working material. Carrying key outputs forward is your job, not the product's.
- Memory (dated facts): cross-chat memory arrived on claude.ai on 11 September 2025 for Team and Enterprise plans. It extended to Pro and Max from 23 October 2025. As of 14 November 2026, it is on by default for Free, Pro, Max and Ultra plans. As of that date, on Team and Enterprise plans an owner decides whether memory is available. In organisations created before 31 October 2026, memory stays off for each member until that member enables it. In most newer ones, memory starts on.
- What memory holds: a set of individual topics covering your role, projects, preferences and ongoing work context. Context about you, not transcripts, drafts or attached documents.
- Chat search: on paid plans you can ask Claude to search past chats and reference relevant details. Prompted retrieval, not automatic carry-over.
- The dependable pattern: paste the needed output into the new conversation, re-attach the file, or keep it in a Project's knowledge base. Neither memory nor chat search reliably transports a specific working output (an approved outline, a tone guide) into a new chat.
Feedback Quality and Refine vs Re-Brief (1.3)
Iteration is the normal working cycle, not a failure state. First outputs are drafts; the cycle is output → specific feedback → better output.
- Specific feedback works better than vague feedback, every time. "Make it better" and "try again" reproduce the problem because no new information enters the conversation. "Cut it to 200 words, keep the pricing paragraph, lose the marketing adjectives" fixes it.
- Good feedback does one of three things: adds a missing constraint, corrects a misreading, or narrows the scope. The underlying skill is diagnosing what the gap actually is, then saying it plainly.
- Variants are iteration too: "three versions of the opening: formal, conversational, urgent" makes Claude the options generator and you the judge.
- Refine in the same conversation when the draft is close: the right task, not written for the wrong reader, and a few gaps you can name. A generic draft with no particular reader can still be close. Refine also when the draft is wrong but the brief was right, because Claude misread it: correct the misreading in a follow-up. Re-brief in a new conversation when the draft is not close and the brief itself was wrong. That covers the wrong task, the wrong framing, or a missing point that the whole draft depends on, such as the reader. Re-brief also when a long series of corrections now contradicts itself. Correcting a wrong brief across six turns works against the framing instead of fixing it. The wrong choice between refining and re-briefing happens in both directions, and the exam uses both.
- Keep the wording that worked: the feedback that fixed the draft is the instruction the original prompt was missing. Add it to the original prompt as your reusable version.
The Four Task-Type Strategies (1.4)
One prompting style does not fit all work. Name the task type, then brief in the shape that suits that type:
| Task type | Briefing shape | Classic wrong answer |
|---|---|---|
| Analysis | Attach the material; name the questions and the decision they inform; ask for findings, evidence, caveats | "Analyse this data" with no questions attached, which produces a description |
| Research | A scoped question with an angle and a purpose; expect to verify citations | A bare topic, which returns an unfocused report |
| Drafting | The full five-component brief plus an exemplar; iterate; stage anything long | A drafting prompt with no audience |
| Brainstorming | Wide first (quantity and range, judgement withheld), converge second | Constraints applied at the divergence step |
Research vs web search dividing line: web search suits straightforward factual queries answered in one or two lookups; Research suits thorough multi-source gathering, building searches on each other and delivering a cited report. Offering Research for a quick fact is over-engineering; one search for a multi-source comparison is too little searching.
Boundary note: picking which product feature or model to use belongs to Domain 3. Objective 1.4 tests how the request is briefed once the task type is clear.