Reference Card — Designing a Use Case

Choose the task first: something you did more than three times last month and did not enjoy. Don’t pick it because it sounds like a good AI task — pick it because it is tedious, then find out. Every step below works on the task’s structure, so nothing confidential has to be written down to use this.

The seven steps

Describe the task as it exists today. Inputs, outputs, who consumes it, what “good” looks like, how you’d know it had gone wrong. Structure, not contents.
Run the fit test — argue both sides. Write the case for and the case against before you decide. See the block below.
Decide the shape. One-off chat or a Project? What should the output rest on? At what scope should context persist — everywhere, this body of work, or accumulating on its own? Does the output want to be an Artifact?
Build it. Instructions, knowledge, prompt.
Write the test set before you look at any output. Three cases, one of them deliberately hard or an edge case, with pass criteria fixed in advance. Criteria written after seeing output is how people talk themselves into mediocre results.
Run, diagnose, iterate — at least twice, written down. Classify each failure with the taxonomy card and apply the matching repair. No documented iteration means it isn’t finished, however good the output looks. The iteration is the skill.
Write the handoff note. What this is for, what it is bad at, what a user must check before relying on it.

Step 2 · The fit test

Anti-criteria — any one of these is a reason to stop

Facts Claude can’t reach. The task turns on information that is private, unpublished, or in no source you are able to supply.
Wrong is expensive and hard to detect. Either alone is manageable. Cheap-to-be-wrong is fine; expensive-but-obvious is fine. The pair together is the combination that hurts.
Mostly judgement you can’t articulate. If you cannot say what makes a good one good, you cannot specify it and you cannot test it.
Checking costs more than doing. If every line has to be verified before you’d trust it, and verifying takes longer than writing it yourself, the task has already answered you.

Argue both sides in writing. The case for is easy and you will write it anyway; the case against is the one that has to be forced, which is why this step gets skipped and why skipping it is expensive.

The answer this card exists to permit

“This doesn’t fit” is a legitimate and complete answer. State why, pick another task, start again at step 1.

What finished looks like

A one-page design record covering all seven steps, with at least two documented iterations and a handoff note naming at least two real limitations. Nothing published — a design record describes a task’s structure, and it can be excellent without containing a single real fact about your work.

Where this comes from

Module 8, the capstone. The process — not any individual module — is the part of the course meant to still be useful a year later, which is why it is on a card rather than in a lesson. The lesson that teaches it, with worked examples and the anti-criteria argued out at length, is Lesson 8; the design specification behind both is in the curriculum.

When It Gives You Garbage — the other card Lesson 8 — the capstone Three worked design records Curriculum · Module 8 Glossary All contents

Ask me things. Most useful of all: a task that failed the fit test — which anti-criterion caught it, and whether you agreed. Next most useful, a task that passed and went badly anyway, because that means the list above is missing one.