Lab 1 · Domain 1 · 14%

Prompting & Task Execution

Most people who use Claude badly are not using it wrong; they are asking wrong. This lab is about the gap between a request that sounds clear to a colleague and one that is actually specific enough to act on. You'll rewrite a weak prompt into a strong one, break a task too big to answer into steps that can be answered, and learn to iterate on purpose rather than by rerolling.

Exam objectives covered

Create effective prompts for business and technical tasks
Apply task decomposition techniques to structure complex requests
Iterate prompts to improve output quality
Adapt prompting strategies based on task type (analysis, research, drafting, brainstorming)

What you need: a Claude account (claude.ai) and about 40 minutes. No installation, no API key, no code.

1. What Makes a Prompt Effective

A prompt is effective when Claude could not reasonably produce the wrong thing. That means it removes the guesses Claude would otherwise have to make. In practice, four elements do most of the work:

Task — the specific verb. Not "look at this data" but "identify the three months with the largest month-over-month decline."
Context — who this is for, what has already been tried, what constraints exist. Claude cannot see your org chart or last quarter's decision.
Format — the shape of the answer. A table, five bullets, a 200-word summary, a draft email.
Criteria — what makes the answer good. "Prioritize by revenue impact" turns an arbitrary ordering into a defensible one.

A prompt missing any of these forces Claude to invent it. Sometimes it invents well. That is the problem: you cannot tell the difference between a lucky guess and a correct one.

The same request, twice

Weak

Can you help me with our customer churn? Here's the data.

Claude has to guess: help how? Diagnose causes? Predict who leaves next? Write a summary for a VP? Every one of those is a different deliverable, and Claude will pick one.

Strong

I'm a customer success manager preparing for a quarterly business review with our VP of Revenue. Using the churn data below, identify the three customer segments with the highest churn rate this quarter, and for each one give the most likely driver based only on what the data supports. Format: a table with columns Segment, Churn Rate, Likely Driver, Confidence (High/Medium/Low). If the data is insufficient to support a driver for a segment, say so explicitly rather than speculating.

Note the last line. Telling Claude what to do when it cannot answer is one of the highest-leverage sentences you can write, and it is the seed of everything in Lab 2.

Specificity is not length. A long prompt full of pleasantries and background nobody needs is still vague. The strong prompt above is short. It is specific because every sentence removes a decision Claude would otherwise make on your behalf.

Try it in Claude

Open a new chat and paste this deliberately vague prompt: "Write something about our new product launch."
Read what comes back. Notice every assumption Claude had to make: audience, channel, tone, length, what the product even is.
Now rewrite it with all four elements: task, context, format, criteria. For instance: "Write a 150-word LinkedIn post announcing our new expense-tracking app for small-business owners. Tone: plain and confident, no hype words. Lead with the problem it solves, not the features. End with a single call to action."
Compare the two outputs side by side. Write down which of the four elements produced the biggest jump in quality. It is usually criteria.

2. Task Decomposition

Some requests fail not because they are vague but because they are compound. "Analyze this contract, flag the risky clauses, and draft a redline memo" is three tasks. Asked at once, Claude does all three shallowly, and errors in step one silently poison steps two and three.

Decomposition means splitting a request into steps where each step's output becomes the next step's input, and you can inspect the handoff.

Signal the task needs decomposing	What to do instead
The request contains "and then" or multiple verbs	Make each verb its own turn
Output is consistently shallow across every part	Split; depth returns when scope narrows
You cannot tell which step introduced an error	Split so each step is independently checkable
Later steps depend on a judgment you'd want to approve	Split and review the judgment before continuing

The contract example, decomposed:

Extract. "List every clause that assigns liability, with the clause number and a one-sentence summary." → You verify the list is complete.
Assess. "For each clause below, rate the risk to us as buyer: High / Medium / Low, and state why." → You sanity-check the reasoning.
Draft. "Using the High-risk clauses below, draft a redline memo to counsel." → Built on verified inputs.

Three turns take longer than one. They also produce an answer you can defend, and they let you catch a missed clause at step one instead of discovering it in a memo already sent to legal.

Try it in Claude

Pick a compound task from your actual job, something with at least three verbs in it.
Ask Claude to do the whole thing in one prompt. Save the output.
Start a fresh chat. Break it into three sequential prompts, feeding each result into the next and correcting anything wrong before continuing.
Compare. Ask yourself the diagnostic question: in the one-shot version, would I have noticed if step one was wrong?

3. Iterating on Purpose

When output disappoints, the instinct is to regenerate and hope. That is rerolling, not iterating. Iteration means changing a specific variable and observing what it changed.

Diagnose before editing. Is the output wrong (a facts problem), off-target (a task problem), or right-but-unusable (a format problem)? Each has a different fix.
Change one thing. If you add criteria and tighten format simultaneously, you learn nothing about which mattered.
Correct in the same conversation. Claude can see the previous attempt. "Closer, but the tone is too formal for a customer email, and cut it to half the length" is more efficient than restarting.
Restart when the thread is poisoned. If you have corrected three times and it keeps drifting back, the early turns are anchoring it. Start fresh with everything you have learned folded into the first prompt.

Your best prompt is usually your fourth one. When you finally get output you like, copy the prompt that produced it and save it. The exam expects you to treat prompts as reusable assets, not disposable messages. Lab 5 will have you promote the good ones into Project instructions.

4. Adapting to the Task Type

The blueprint names four task types, and each rewards a different prompting posture. Recognizing which one you're in is most of the skill.

Task type	What Claude needs most	Prompting move
Analysis	The data, and the criteria for judging it	Supply the evaluation standard. Demand that conclusions cite the specific data supporting them.
Research	Scope boundaries and a stance on uncertainty	Say what's in and out of scope. Require explicit flagging of anything unverified.
Drafting	Audience, tone, length, and a model of "good"	Name the reader. Give an example of the voice you want, or one you don't.
Brainstorming	Room to range, plus constraints that force novelty	Ask for volume first, judge later. Add a constraint ("none may require new headcount") to break obvious answers.

The most common mistake is applying a drafting posture to an analysis task: asking for something that reads well, and getting something that reads well and is wrong. Analysis prompts should make it easy for Claude to say "the data doesn't show that."

When to escalate. If solving your problem well would require calling Claude programmatically over thousands of records, wiring it into an application, or building a tool that Claude invokes on its own, you have crossed out of Associate territory. That is work for a Claude Architect or Developer. Knowing where that line sits is itself an exam objective: recognizing limitations and escalating appropriately.

5. Lab Exercise: Rebuild a Prompt You Actually Use

Objective: convert a real, mediocre prompt from your own work into a specific, decomposed, iterated one, and be able to explain what each change bought you.

Baseline. Find a prompt you have genuinely used that produced so-so output. Run it again. Save the result.
Classify. Which of the four task types is it? Analysis, research, drafting, or brainstorming? Write it down before you edit anything.
Rebuild. Rewrite it with task, context, format, and criteria all present. Run it.
Decompose. If it contains more than one verb, split it into sequential steps and run those, inspecting each handoff.
Iterate once, deliberately. Change exactly one variable. Record what changed in the output.
Add a failure instruction. Append a sentence telling Claude what to do when it cannot answer confidently. Run it against a question the source material genuinely cannot answer, and confirm it declines instead of inventing.
Save the winner somewhere you'll find it again. You'll reuse it in Lab 5.

Step 6 is the one people skip, and it is the bridge to the heaviest domain on the exam. A prompt that never admits uncertainty produces confident nonsense, and Lab 2 is entirely about catching it.

Check Yourself

Exam-style items. Commit to an answer before expanding.

An associate needs Claude to review 40 vendor contracts, flag non-standard payment terms, and produce a summary memo for the finance director. The first attempt, asked as a single prompt, returns a shallow memo that misses several contracts. What is the best next step?

A. Regenerate the response until the memo improves.
B. Decompose the request: extract payment terms per contract, verify the extraction, assess which are non-standard, then draft the memo from the verified list.
C. Ask Claude to try harder and be more thorough.
D. Switch to a more capable model and resubmit the same prompt.

Correct: B. The failure is structural, not stylistic. A compound request across 40 documents produces shallow coverage in every part, and an omission at the extraction step silently propagates into the memo. Decomposing creates an inspectable handoff where you can confirm all 40 contracts were processed before any summarizing happens.

A is rerolling, which changes the output without addressing why it failed. C adds no information Claude can act on. D may improve fluency but does not fix a request that is asking for three deliverables at once, and it would mask the omission rather than surface it.

Which single addition most improves this prompt: "Review the attached survey results and tell me what customers think about our onboarding."

A. A polite opening and a thank-you.
B. An instruction to be thorough and detailed.
C. Explicit criteria and format: which themes to rank, by what measure, and to cite the responses supporting each theme.
D. A request that Claude state its confidence level.

Correct: C. The prompt names a task but supplies no standard for judging the answer and no shape for it. Criteria plus format turn an open-ended impression into a defensible, checkable deliverable, and requiring citations back to specific responses makes verification possible.

A changes nothing about the output. B is the illusion of specificity: "thorough" is not a criterion Claude can measure itself against. D is closer to useful, but self-reported confidence is not a reliable accuracy signal, a point the exam tests directly in Domain 2.

An associate is brainstorming cost-reduction ideas. The first ten suggestions are all obvious (reduce travel, renegotiate vendors). Which adjustment is most likely to surface novel options?

A. Ask for twenty more ideas.
B. Add a constraint that rules out the obvious category, e.g. "none may involve reducing headcount, travel, or vendor spend."
C. Rephrase the request more formally.
D. Ask Claude to rank the ten ideas it already gave.

Correct: B. Brainstorming rewards constraints that foreclose the obvious answer space and force Claude to search elsewhere. Removing the categories that produced the generic output is what generates novelty.

A likely yields more of the same, since nothing has changed about what the prompt permits. C is cosmetic. D is a useful next step once you have ideas worth ranking, but it does not produce new ones; in brainstorming, volume comes first and judgment second.

Key Takeaways

An effective prompt removes guesses: task, context, format, criteria. Specificity, not length.
Decompose compound requests so each step is independently checkable, and errors surface where they happen rather than downstream.
Iterate by changing one variable and observing the effect. Rerolling is not iteration. Restart when a thread is anchored to a bad early turn.
Match posture to task type. Analysis needs criteria; research needs scope and uncertainty handling; drafting needs audience and voice; brainstorming needs constraints.
Always tell Claude what to do when it cannot answer. That single sentence is your first defense against the hallucinations you'll hunt in Lab 2.