Your best examples already exist

You do not have to write them

People sit down to invent example inputs and outputs, and produce something clean, typical and useless. Meanwhile the useful examples are sitting in their sent folder, their ticket system, their approved documents and their spreadsheets.

Real work carries information invented examples cannot: the mess, the exceptions, the things that were argued over and settled.

Where to look, by task

Writing. Your sent folder. Specifically the messages that got the outcome you wanted: the quote that was accepted, the complaint that was resolved, the update nobody had to ask a follow-up question about.

Classification and routing. The last two hundred tickets with the labels a human gave them. You do not need all two hundred; you need the twenty where somebody re-labelled it afterwards, because those are the disagreements.

Documents. The version that was approved after review. Better still, the version before review and the version after, as a pair: that pair encodes exactly what your reviewer wants and nobody has ever written it down.

Data work. The spreadsheet somebody cleaned by hand, with the messy original if you still have it. Input and output, free.

Code. A function in your codebase that does the sort of thing you want, written the way your team writes it. This carries naming conventions, error handling and logging style that no description would have captured, and it costs one copy-paste.

Anything with a review step. If a human signs something off, the sign-off is a label. Approved and rejected quotes. Expense claims that were queried. Applications that got an interview. You are sitting on a labelled dataset and calling it a filing system.

The before-and-after archive is the gold

The single most valuable artefact in most organisations is a pair: what somebody wrote, and what it looked like after the person who knows better fixed it.

Track-changes documents. Editor comments. The pull request with review comments and the commit that answered them. The invoice draft and the corrected invoice.

Three of those pairs in a prompt will encode a house standard that has never been documented, and probably could not be. It is the closest thing to apprenticeship that a prompt can carry.

Two things to check before you use them

Permission and privacy. Real work contains real people. Redact names, contact details, account numbers, medical or financial specifics. If the material is confidential to a client or an employer, redaction is not always sufficient: check what your rules actually say before pasting. Doing this once, properly, is faster than discovering the policy after the fact.

Whether it was actually good. The email that got the outcome is not automatically the email that caused it. Do not enshrine a bad habit because it coincided with a sale. Read your samples as a set and ask whether you would defend each one.

Keep them where you will find them

A folder, a text file, a note. Named for the task, not the date. examples-refund-replies.txt, not prompt stuff v3.

Each file wants three things: the examples, one line each on why that example is in there, and the date. The date matters because an example encodes a policy, and policies change; six months on, “why is this labelled that way?” is a question you will actually have.

Why this is the durable part

Models change. Products change. The specific phrasing that works this year may not next year. The set of twelve real, labelled, awkward cases from your own work does not go stale in the same way, because it encodes decisions about your work rather than facts about a model.

If you build one thing from this course that survives, build that file. It is worth more than every prompt template you will ever be sent, and nobody else can build it for you.

Starting it this week

You do not need a project. Next time you correct an output, save two things: the input, and the version you accepted after fixing it. That is one pair, and it took ten seconds.

Do that five times over a fortnight and you have a set of examples drawn entirely from real failures, which is exactly the set the awkward-case lesson told you to build, assembled without any deliberate effort.

Most people who end up with a good example file did not sit down to write one. They kept the corrections.