Seven lessons handed you the material. This one doesn't. You pick the task, you decide whether Claude fits it, and you prove the answer either way — including when the answer is no.
Everything so far has been scaffolding for this. You have a model of what generation is, an account of what reaches a response, six components to specify with, six failure classes to diagnose with, a question to ask of any claim, a scope to persist things at, and a surface to produce work on. None of that is worth much if it only fires when someone hands you an exercise. The skill is starting from a problem you already have, and reasoning forward from it. So this lesson supplies no template, and the first decision is yours.
Pick a task you personally did more than three times in the last month and did not enjoy. Do not pick a task because it sounds like a good AI task. Pick it because it is tedious, and then find out whether AI helps.
The second sentence is the entire capstone. Everything else here is procedure.
Here is why it's there. Ask a room of people to pick a task for an AI exercise and you get summarising documents and drafting emails, over and over. Not because those are the best fits, but because they are the tasks that have been described as good AI tasks often enough to come to mind first. Choosing that way is template-matching wearing a different hat — you've retrieved a solution and then gone looking for a problem shaped like it, which is the exact reflex the last seven lessons were built to remove.
Tedium is a better selector because it is a fact about your week rather than a fact about the tool. It doesn't know what Claude is good at, so it can't quietly pre-select for it. Some of what it surfaces will fit well. Some won't fit at all, and finding that out carefully is worth as much as building something.
The instinct at this point is to pick something you're fairly confident will work, because a capstone that succeeds feels like a capstone that passed. It isn't. What's being assessed is whether you can reason from a problem to a verdict and show your working. A carefully argued this is the wrong tool for this scores full marks. A build that works and was never in any doubt scores less, because nothing was tested but your ability to pick a safe question.
How to actually generate a candidate. Don't reach for one. Write a list first. Everything you did three or more times in the last month that you would rather not have done — five items, no filtering, including the ones that look nothing like AI work. Then pick the most tedious, not the most promising. If the most tedious one turns out not to fit, you'll have found that out on purpose in step 2, which is a result and not a setback.
Task selection is real. What you feed the thing is entirely your call, and nothing in this lesson requires you to use anything from your actual job.
Real task, discretionary data. Pick a task you really do. Whether you build it on your own material, on redacted material, or on a supplied synthetic stand-in is your decision and it is never the price of admission.
A synthetic analogue exists for every shape this capstone commonly takes. Six of them are here, each built to the same structure as the real thing and each convincingly untidy. Nothing is withheld from the synthetic path — you can complete every step and score full marks on it.
The graded thing describes structure, not
contents. The design record says what the inputs are, what the output has to be,
who reads it, what good looks like, how you'd know it went wrong. A record in which every
figure is written [amount] and every client is written [client]
can be excellent. Detail about the shape of a task is what earns marks; detail
about its contents earns none.
You demonstrated Publish in Lesson 7, and it is deliberately absent here. Publishing an Artifact makes it reachable by anyone holding the link. That was a fine thing to practise on a supplied spreadsheet. It is a poor thing to practise at the one moment in the course when you are working with material closest to your actual job, on your own initiative, at the end of a long session, with nobody checking what went into it.
So: produce the design record as an Artifact, and do not publish it. The Artifact is for the iterating-in-place and for having one object you can hand to the grading prompt at the end. It stays in your account.
This process is the durable object of the whole course. Not any single lesson — this. It's on a printable card, and it is meant to be run again on the next tedious task, and the one after that.
It's grouped into four checkpoints below. Each one ends somewhere you can stop, save, and come back the next day without losing the thread. Take them over several sittings if that's what it takes — a capstone finished over four evenings is finished.
Step 1 — Describe the task as it exists today. Before any mention of Claude. Five things, written down:
| Inputs | What arrives, in what form, from whom, how consistent it is between occurrences. |
| Outputs | What leaves, in what form, at what length, on what schedule. |
| Consumer | Who reads it, and what they do next as a result. "Nobody reads it" is an answer, and an interesting one. |
| Good | What separates a good instance from an adequate one — specifically enough that somebody else could apply it without asking you. |
| Wrong | How you'd know it had gone wrong, what it would cost, and how long it would take you to notice. |
Structure, not contents. You are describing the shape of the job, not doing it.
The last row is the one people skip and the one that does the most work later: it feeds the fit test in step 2 and becomes your test set in step 5. If you can't say how you'd know it had gone wrong, you will not be able to tell whether the thing you build is any good, and you'll end up grading it on whether it reads nicely.
The "good" row has its own tell. If you find you can only define good by pointing at an example — I'd know it if I saw it — note that down. It isn't fatal, but it's evidence for one of the anti-criteria you're about to meet.
Step 2 — Run the fit test, and argue both sides. Write the case for and the case against, in that order, both in full. Not a feeling about it. The case against is where the work is, because you already want the answer to be yes.
Four anti-criteria. Any one of them, unrepaired, is a genuine no:
| Anti-criterion | The question to ask | Is it repairable? |
|---|---|---|
| Needs facts Claude can't reach | Does doing this well require something unpublished, private, in a colleague's head, or locked in a system you can't get an export out of? | Sometimes. If you can supply the facts, it isn't fatal — it's a step-3 decision about what the output rests on. If you can't, it's fatal. |
| Wrong is expensive and hard to detect | Both halves, together. What does an undetected error cost, and what would actually catch it before it lands? | Often. Expensive-and-obvious is workable, because you'll catch it. The repair is usually to build in the detection — demand the supporting line, route it past someone who'd spot it. |
| Mostly judgement you can't articulate | Try writing the rule down. Three attempts. Could another person apply what you wrote and land where you'd land? | Rarely, whole. Often in part — the articulable half can be handed over and the tacit half kept. |
| Checking costs more than doing | How long does it take you to verify the output against its sources, versus producing it yourself from scratch? | Sometimes, by narrowing the output so there's less to check, or by making the claims traceable so checking is a scan rather than a re-derivation. |
"This doesn't fit" is a complete, full-marks answer to step 2 — provided the reasoning holds and both sides were argued. A record that rejects a task on a clearly stated anti-criterion is worth more than a record that forced a yes and then produced something nobody will use.
It does not, however, end the capstone. Steps 3–7 still need a task. So: keep the rejected analysis in the record, pick the next item off your list of five, and run steps 1–2 again on that one. Rejecting two in a row is unusual but it is not a problem — it's four anti-criteria doing their job, and the record is more interesting for it.
The fit test is not all-or-nothing. The common result isn't yes or no for the whole task — it's yes for part of it. Half of a weekly report might be mechanical assembly from things you can supply, and half might be a judgement about what to escalate that you couldn't write down if you tried. Split it, hand over the first half, keep the second. That's the Lesson 4 decomposition move applied one level up: not this task is too big but this task is two tasks, and only one of them is a fit.
You should now have, written down: a five-row task description, a case for, a case against, an explicit verdict against all four anti-criteria, and either a task to build or a second candidate already described. Start the Artifact now, paste this into it, and stop if you need to. The rest of the capstone iterates on this object rather than replacing it.
Step 3 — Decide the shape. Four questions, one per lesson, and each one has a defensible answer in both directions. Write the answer and the reason.
Step 4 — Build it. Instructions, knowledge, prompt. This is Lesson 3 with the training wheels off: task, context, input, output shape, constraints and non-goals, examples. The two components that go missing under time pressure are the two that do the most work — non-goals and an example — so put them in first.
Build the smallest version that could possibly work. You are about to test it, and a small thing that fails a test tells you where it failed. An elaborate thing that fails a test tells you nothing.
Four shape decisions with reasons, and a built thing you have not yet run. Resist running it. Step 5 has to happen first and it only works once.
Step 5 — Write the test set before you look at any output. Three cases. At least one of them deliberately hard. Pass criteria fixed in advance and written down where you can't quietly edit them.
Criteria written after seeing the output are criteria the output passes. This is not a warning about dishonesty and you will not catch yourself doing it. It doesn't feel like lowering the bar — it feels like realising what the bar actually was. You read a competent, plausible draft, and the standard you had vaguely in mind reshapes itself around what's in front of you, and you conclude it passed.
The only reliable defence is sequence. Write the criteria while you still have no idea what the output will look like, then don't touch them. If you decide afterwards that a criterion was wrong, that's allowed — but record the change and the reason as part of the iteration log, rather than editing it silently.
What a hard case looks like. Not a longer version of the easy one. Pick from the ways your real inputs actually misbehave: one where a field is missing, one where two sources contradict each other, one that's twice the length you ever normally get, one that arrives in a different format from the rest, or — the most useful of all — one where the correct output is "I can't do this from what's here." That last case is how you find out whether your build fabricates when it's short of material, and it is worth including in almost every test set.
What a usable pass criterion looks like. Something a colleague could apply to the output without asking you what you meant.
| Not this | This |
|---|---|
| Reads well | Under 200 words, four headings in the fixed order, no bullet longer than one line |
| Accurate | Every figure appears verbatim in the supplied source, and every one is attributable to a named line of it |
| Covers the right things | Names all six workstreams; says nothing about any workstream that sent no update |
| Sounds like us | No sentence opens with a participle; no superlatives; second person throughout |
Your three cases and their pass criteria are written down, and the timestamp on them is earlier than the first output you looked at. Yes or no. This one is easy to be honest about and hard to fake, which is the point.
Step 6 — Run, diagnose, iterate. At least twice, documented. Run your three cases. For everything that misses a criterion, name the failure class from the Lesson 4 taxonomy before you change anything, then make the change that class calls for, then run again.
Log it as you go, four columns: what missed · which class · what I changed · what happened next. The fourth column is not optional and it is allowed to say "no difference" — a repair that didn't help is a finding, and it usually means the class was misdiagnosed.
Two things that are not iterations. Rerolling is not an iteration — running an unchanged prompt again draws from the same place, and if the specification was the problem it is still the problem. Rewriting the prompt from scratch is not an iteration either, because you've changed everything at once and learned nothing about which change did the work. An iteration is a named failure, a specific change, and a re-run.
A capstone with no documented iteration is incomplete regardless of how good the final output looks. The output is not the deliverable; the ability to look at a miss, name what kind of miss it is, and apply the matching repair is the deliverable. An excellent output with an empty log demonstrates that you chose an easy task.
If everything passes on the first run — and it might — your test set is too easy, and that is itself a finding worth writing down. Don't manufacture a failure and don't reroll hoping for one. Write a fourth case that's genuinely harder than the three you had: take the input that misbehaves most in real life, or the one where the right answer is a refusal, and run that. If it still passes, record that plainly, and note what you'd have to feed it to break it. Knowing where the edge is counts; pretending you found it doesn't.
Three cases with pre-written criteria, results for each, and an iteration log with at least two rows, each naming a failure class. This is the longest checkpoint and the one most worth splitting across two sittings.
Step 7 — Write the handoff note. Three paragraphs, and it is the shortest step and the one that proves the most.
The test: hand the note and the setup to someone who wasn't there, and they can use it without asking you a question. You in six weeks is that person, and you will have forgotten more than you expect.
The criteria below are the whole rubric. They're published here rather than held back, because a rubric you can read while you work is a specification, and a rubric revealed afterwards is a lottery.
| Criterion | 0 | 1 | 2 | 3 |
|---|---|---|---|---|
| 1 · Task description | Absent, or describes the AI solution rather than the task | Inputs and outputs only | Four of the five rows, specific | All five, including how you'd know it went wrong and how long that would take |
| 2 · Fit test | Not attempted, or one side only | Both sides, but the case against is token | Both sides argued; all four anti-criteria addressed | As 2, plus a verdict that changed something — a rejection, a split, or a constraint added because of an anti-criterion |
| 3 · Shape decision | No decisions recorded | Decisions with no reasons | All four decided with reasons | As 2, and the reasons reference what the output rests on and at what scope context persists |
| 4 · Test set | None, or written after seeing output | Cases but no fixed criteria | Three cases with criteria fixed in advance | As 2, with one genuinely hard case and criteria another person could apply unaided |
| 5 · Iteration | None documented | Changes recorded, no failure classes named | Two iterations, each with a named class and a specific change | As 2, with the outcome of each change recorded — including any that didn't help |
| 6 · Handoff note | Absent | Present but generic | Two limitations specific to this task | As 2, and at least one limitation was discovered in step 6 rather than anticipated |
All seven steps present · at least two documented iterations · a handoff note naming at least two real limitations · and no criterion scored at zero. That last clause is doing real work. An aggregate threshold on its own lets someone pass with a beautiful build and no evaluation at all, which is precisely the failure this course exists to prevent.
Paste your design record into a fresh chat under this. It works on a structure-only record, so it never needs your real content.
Do not take the grade. By Lesson 5 you have been told not to accept a claim on the strength of its tone, and a score out of eighteen is a claim with an unusually confident tone. Three moves, and all three are repetitions of things you already know how to do:
One long exercise, in two parts, and the first part is the one that makes the blank page less blank. As with every lesson: record what actually happened, including "it passed everything first time." An outcome that's better than this lesson led you to expect is a finding to write down, not a broken exercise.
First, read one worked record. Three are supplied — a delivery manager, an analyst and a marketer. Read the analyst's, which rejects its first task, and answer two questions before you start your own: which anti-criterion did the rejection turn on, and which single row of the iteration log would you have argued with? Both answers are on the page, at the bottom, so don't scroll first.
Then build yours. Seven boxes below, one per step, closing four checkpoints:
1 · Describe. Five rows. Structure,
not contents.
2 · Fit test. Both sides, all four anti-criteria, explicit verdict.
Closes checkpoint 1.
3 · Shape. Four decisions, each with a reason.
4 · Build. Smallest version that could work.
Closes checkpoint 2.
5 · Test set. Three cases, one hard, criteria fixed before you run
anything.
6 · Iterate. At least twice, each row naming a failure class.
Closes checkpoint 3.
7 · Handoff note. For, bad at, must check.
Closes checkpoint 4.
Then run the grading prompt, then argue with the result. Using a synthetic analogue instead of your own material counts identically.
Seven boxes, one per step. Tap as you go — it saves in this browser only, so use the same browser across sittings.
From memory, without scrolling up: name the seven steps in order, and the four anti-criteria.
The seven steps: describe the task as it exists today · run the fit test arguing both sides · decide the shape · build it · write the test set before seeing output · run, diagnose and iterate at least twice · write the handoff note.
The four anti-criteria: needs facts Claude can't reach · wrong is expensive and hard to detect · mostly judgement you can't articulate · checking costs more than doing.
Anthropic, Define success criteria and build evaluations — the platform documentation on deciding what "good" means before you measure it. platform.claude.com/docs/en/test-and-evaluate/define-success
Read the first half only — Define your success criteria, and the eval design principles at the top of the second section. That's step 5 of this lesson written by people who do it at scale, and the part on making criteria specific and measurable is worth more than anything else linked in this course. Skip everything from the code samples onward. It's written for people building software against the API, which is explicitly out of scope here, and none of the seven grading methods apply to a three-case test set you check by reading. Take the discipline, leave the machinery.