AfterDesk
EN
Apply

Working with AI

Prompting past the first draft

You wrote a prompt on Tuesday, it produced something usable, and on Thursday the same prompt produced mush. This course teaches the tier above basic prompting: examples instead of adjectives, a fixed output shape, long tasks broken into checked steps, constraints an operator could verify, and a personal prompt library you version. By the end a good prompt stops being a lucky night and becomes a tool you own.

8
lessons
~62
minutes
12
exam questions

Free · No paid tier · No certificate fee

After this course

Everything, and what is in it.

A prompt is not a process

~7 min

One good answer proves nothing

On Tuesday you asked for a summary of a 12-page policy and got something you could almost paste. On Thursday you asked again, worded slightly differently, and got four paragraphs of nothing. Nothing changed except your typing. That is the whole problem with treating a prompt as a conversation: the good result lived in a chat window, and the chat window is gone. A process is different. A process is a written instruction you can hand to yourself next week, run on a different task, and get output within the same narrow range. Getting an answer is a Tuesday event. Building something you can run again is the work this course is about.

Save the exact words you sent

The moment a prompt works, the useful object is not the output. It is the input. Copy the exact text you sent, every word of it, into a plain file before you close the window. People rewrite it from memory later and lose the part that was doing the work, usually a small clause like list only the rows where the amount is blank. Memory smooths prompts into something reasonable and useless. Alongside the text, save one line saying what task it was for and what the output looked like when it went well. Two minutes of copying on a good night saves an hour of rebuilding on a bad one.

Three parts survive, one does not

Look at any prompt that worked and you will find four things in it: the situation, the job, the rules, and the material. The first three are reusable. The fourth is not. The situation, the job and the rules are your asset, and they should be written once and kept. The material is whatever you were working on that night: the 60 rows, the meeting notes, the draft. It changes every task and it never belongs in the saved version. Separating them is the single move that turns a prompt into a process. What you keep is a form with a hole in it. What you paste in each time is the thing that fills the hole.

Where the material is allowed to go

That hole is exactly where the confidentiality rule bites. Client material does not go into third-party or consumer AI tools: not a chat assistant you signed up for yourself, not an online transcription site, not a document summarizer, not an image tool. AfterDesk provides its own assistant inside a task you have claimed. It is sanctioned. It cannot see the task record, the client identity, the files or the price; it sees only what you type, and what you type is scrubbed for personal data before storage. So ask it method questions freely. A brief can also grant written permission to use a named external tool for a named purpose, and that permission is real. Silence in a brief is not permission.

Remember

  • A result you cannot reproduce next week is luck, not method.
  • Save the exact text you sent, not a remembered version of it.
  • Situation, job and rules are reusable; the material never is.
  • Client material stays out of outside tools; the in-product assistant is sanctioned.
  • A brief can grant named permission in writing. Silence cannot.

Show examples instead of adjectives

~8 min

Adjectives are opinions, examples are specifications

Ask for a professional summary and you will get whatever the model averaged professional to mean. Ask for a concise one and you may get 40 words or 400. Adjectives are opinions and every reader holds a different one. An example is a specification. If you paste two finished summaries that look exactly like what you want, length, tone, ordering, and the way numbers are written, you have removed the argument. The model does not have to guess your taste; it can see it. This is the difference between describing a house and showing a photograph of it. On a 40-item task, that difference is the difference between one pass and three.

Two or three, paired input and output

The format matters. An example is a pair: the raw input on one side, the finished output on the other, so the model can see the transformation rather than only the destination. Two pairs is usually enough. Three is better when the task has a wrinkle, and one is risky because a single example gets copied too literally, including its subject matter. Keep the pairs short. A 300-word example teaches no more than a 60-word one and buries the pattern. If your task has an obvious edge case, spend your third example on it: an input where a field is missing, and an output showing exactly how you want the gap handled.

Where your examples come from

The best examples are the client's own approved past work, because they encode a house style nobody wrote down. Read the previous delivery that passed review and lift the shape of it: the ordering, the phrasing of headings, the level of detail. But that material is the client's, and it does not leave for an outside tool. If you are working inside the sanctioned assistant, or under a brief that names an external tool in writing, you have a lane. Otherwise, build the example yourself. Invent a fictional company, fictional numbers, fictional names, and write the input and the finished output by hand. An invented example teaches the same shape and carries none of the client.

Your examples are also your trap

Examples are copied, which is the point and also the danger. If both of your examples happen to be about restaurants, expect restaurant vocabulary to bleed into a task about dental clinics. If both examples run to three bullet points, expect three every time, even when the source only supports two. Vary what should vary and hold constant only what you actually want held. When output starts coming back subtly wrong in the same way every run, suspect your examples before you suspect the model. The fix is usually one word in one example. Read your examples the way an operator will read your delivery: assume everything in them is an instruction, because to the model it is.

Remember

  • Adjectives are opinions. An example is a specification the model can copy.
  • Pair raw input with finished output so the transformation is visible.
  • Two examples is usually enough; spend a third on the edge case.
  • Client work stays in sanctioned lanes; otherwise invent a fictional example.
  • Everything in an example is an instruction, including its subject matter.

Demand the same shape every time

~8 min

Prose costs you the rework

You asked for a competitor summary and received four paragraphs. The delivery template wants six columns: company, product, price, currency, source URL, date checked. Now you spend 25 minutes reading prose and retyping it into cells, which is the exact work you were trying to avoid, plus a fresh chance to mistype. The problem was never the model. You asked for information and got information; you needed a shape. Naming the shape in the prompt costs one extra sentence and removes the retyping entirely. Specify the columns, their order, the format of dates, the format of currency, and what goes in a cell when the answer is missing. Then the output pastes in.

Name the columns and their order

Write the header row into the prompt exactly as it appears in the delivery file, in the same order, spelled the same way. If the template says Date checked, do not write Date verified and reconcile later. Order matters more than it looks: a sheet whose columns arrive in a different sequence every run cannot be pasted, only rebuilt. State the separator too, whether you want tab-separated rows you can paste into Google Sheets or a plain table. And state one rule for missing values, such as writing the word unavailable rather than leaving a blank, because blanks and spaces and the word none in the same column will cost you a sort later.

Pin the formats that drift

Some fields drift on their own unless you nail them down. Dates are the worst: 03/04/2026 means two different days depending on who reads it, so say the format you want and give an example of it, such as 2026-03-04. Currency drifts next: decide whether you want 1250 or 1,250 or PHP 1,250.00, and say so. Then names, phone numbers, and anything with a country code. Percentages need a decision about the sign. Say it once in the prompt and the whole run comes back consistent; leave it unsaid and you will be find-and-replacing at four in the morning across 200 rows. A column that is consistently wrong is fixable in one pass. A column that is inconsistently right is not.

Forbid the friendly extras

Left alone, a model likes to open with here is the table you requested and close with let me know if you want changes. It likes to add a summary row you did not ask for, or a footnote explaining its reasoning. All of it is polite and all of it breaks a paste. Say what you do not want as plainly as what you do: no introduction, no closing sentence, no summary row, no commentary, output the rows and nothing else. It feels rude to write. It is not rude, it is a specification, and it saves you deleting the same two sentences 30 times a week. Check the first run to confirm the ban held.

Shape is not accuracy

A perfectly shaped table is still a table of claims. Structured output makes checking faster, because a fixed column order means your eye knows where to look, but it also makes wrong output look finished. That is a real risk on a night shift at hour six. Treat the shape as a delivery convenience and nothing more. Every value in every cell still needs the same verification it needed when it arrived as prose: the source checked, the figure traceable, the unavailable earned. Polish proves nothing. If anything, budget more checking time on well-shaped output than on messy output, because messy output warns you and neat output does not.

Remember

  • Ask for a shape, not just information, or you retype the answer.
  • Copy the template header row into the prompt, same words, same order.
  • Pin dates, currency and missing values explicitly; they drift on their own.
  • Ban the greeting, the closing line and the unrequested summary row.
  • A neat table is still unverified. Polish proves nothing.

Break long tasks into checkpoints

~8 min

One giant request fails silently

You paste 60 pages of transcript and ask for a themed summary with quotes and action items in one go. What comes back is coherent, and you have no idea where it went wrong. Long requests fail in the middle, quietly. The model loses the thread around item 30, invents a theme to cover the gap, and finishes confidently. Nothing in the output flags the seam. If you find the error at all, you find it after delivery, and you cannot repair one step without rerunning everything. A decomposed task fails loudly and locally instead. Step three comes back wrong, you fix step three, and steps one and two are still good. That is the entire argument.

Put a checkpoint where a mistake compounds

Checkpoints are not evenly spaced. They go at the joints where one step's output becomes the next step's input, because that is where an error stops being an error and starts being a foundation. Extracting a list of themes is a joint: if the theme list is wrong, every quote you sort under it is wrong too. Grouping 200 rows into categories is a joint. Deciding which of 45 vendors are in scope is a joint. Formatting the final table is not a joint, because a formatting mistake is visible and cheap. Ask one question of each step: if this comes out wrong, does the next step multiply it? If yes, you stop and look before continuing.

A checkpoint means you actually look

A checkpoint is not a pause. It is you reading the intermediate output against the source with your own eyes, then deciding to continue, correct, or restart the step. Ten themes came back; open the transcript and confirm that theme seven appears in it at all. Forty-five vendors were classified; check five by hand, chosen from different parts of the list, not the first five. If the check fails, fix the step and rerun from there, not from the top. Write your correction into the step's instruction so the same failure does not return next task. Checking three intermediate outputs for two minutes each is cheaper than one correction request, and far cheaper than a delivery an operator sends back.

Do not chop what does not need chopping

Decomposition has a cost. Five steps means five prompts to write, five outputs to read, and five chances to mistype something between them. A task that takes one clean pass should stay one clean pass. Rewriting a single 200-word paragraph does not need a pipeline. The signal to break a task up is scale or dependency: many items, or a step whose result the next step relies on. Below that, splitting is ceremony. The honest test is whether you could check the whole output in one sitting without losing your place. If you can, run it whole. If you cannot, that is not a bigger prompt problem, it is a decomposition problem, and the fix is steps.

Remember

  • One giant request fails in the middle, quietly, with nothing marking the seam.
  • Checkpoints belong at joints where one step feeds the next.
  • A checkpoint means reading the intermediate output against the source yourself.
  • Fix and rerun the failing step, not the whole chain.
  • Small single-pass tasks do not need a pipeline. Splitting costs time.

Write constraints somebody can check

~7 min

Concise is not a constraint

Concise, professional, thorough, natural: none of these can be checked. Two people reading the same paragraph will disagree about whether it is concise, and you will disagree with yourself at hour seven. A checkable constraint has a number, a list, or a rule that produces the same verdict from any reader. Under 40 words is checkable. Exactly three sentences is checkable. Only the five categories named below is checkable. No adjectives before the company name is checkable. The test is simple: could an operator who has never spoken to you hold your output against the constraint and get a yes or a no without asking your opinion? If not, rewrite the constraint until they could.

Closed lists beat sensible judgement

Categorize these 200 support tickets sensibly produces categories that shift halfway down the file, merge, and multiply. You end up with Billing, Billing issue, and Payments as three separate buckets. Name the list instead: use exactly these five categories, billing, access, bug, feature request, other, and put anything that does not fit into other. Now the output is countable and the disagreements are visible. A closed list also gives you an escape hatch that is honest, which is what other is for. Without one, ambiguous items get forced into the nearest category and the error hides. With one, they collect in a pile you can look at and ask the operator about.

Say what to do with the gap

Most constraint failures are not about the normal case. They are about the row where the information is not there. Say in advance what should happen: if the price is not published, write unavailable, do not estimate. If the transcript does not name a speaker, write speaker unknown rather than guessing from context. If a quote would exceed 25 words, cut from the end and mark it with an ellipsis. Unstated, a model will fill the gap with something reasonable, and reasonable is exactly how invented data enters a file. The rule from your research training holds here without change. Nothing goes in a cell that no source put there. Write that rule into the prompt itself.

Then check the constraint yourself

A constraint in a prompt is a request, not a guarantee. Under 40 words comes back at 46 often enough that you should count. So build the check into your own routine: run the output, then verify the constraint on a sample before you look at anything else. If you asked for five categories, sort the column and see how many distinct values appear. If you asked for 40 words, check the three longest entries. This takes a minute and it catches the failure that would otherwise reach the operator. Writing checkable constraints is only half the value. The other half is that you can now check them in a minute instead of rereading everything.

Remember

  • If two readers can disagree, it is not a constraint.
  • Numbers and closed lists produce the same verdict from any reader.
  • Name the categories, including an honest other, before you ask for sorting.
  • State what to write when the information is missing, or invention fills it.
  • A constraint is a request. Verify it on a sample yourself.

Know when to start clean

~7 min

You are now arguing with a machine

The pattern is familiar. The first answer was close, so you said no, shorter. It got shorter and lost a column. You said keep the column. It came back with the column and the old length. Twenty minutes and eleven messages later, you are negotiating. Notice what has happened: every wrong answer is still in the conversation, and the model is weighing all of it, including its own mistakes. You are no longer giving instructions, you are correcting a moving target. That feeling of being in an argument is a real signal, not frustration to push through. When you notice it, stop replying. The next section is what to do instead.

Three corrections, then rewrite

Give yourself a rule you can follow when tired, because judgement is the first thing a night shift takes. Three corrections is a good limit. If the output is still not right after three, do not send a fourth. Open a fresh conversation and write a new prompt that includes everything you learned from the failed one. The three corrections were not wasted; they told you which instructions were missing. Fold them in as constraints at the start rather than as complaints at the end. A clean start with a better prompt usually lands in one try, and it takes less time than the fourth correction would have. Counting to three is easier than deciding each time.

When staying in the thread is right

Iterating in place is not always wrong. It is the right move when the output is fundamentally correct and you are adding, not repairing. Now do the same for the remaining 30 rows. Now add a column for the date checked. Those build on a good foundation and the accumulated context helps you. The distinction is direction. If your messages are additive, stay. If your messages are corrective, and especially if you are correcting the same thing twice, the context is now working against you, because the wrong version is sitting in it as an example. Additive means the thread is an asset. Corrective means the thread has become the problem.

Harvest the thread before you close it

Before you abandon a bad conversation, take one minute and write down what it taught you. Usually it is one or two sentences: the model kept including the header row, so say exclude the header. It kept expanding abbreviations, so say leave abbreviations as written. Those sentences are the improvement, and they belong in your saved prompt, not only in the fresh conversation you are about to start. Most people restart, get a good result, and never update the file, so the same argument happens again next week. The whole point of a bad thread is that it is diagnostic. Pay yourself for the twenty minutes by keeping what they bought.

Remember

  • A bad thread carries its own wrong answers forward as examples.
  • Three corrections is the limit. After that, start clean.
  • Additive messages justify staying; corrective messages mean the thread is the problem.
  • Fold the corrections into the opening prompt, not the end of the argument.
  • Write down what the failed thread taught you before closing it.

Build a prompt library you own

~8 min

A folder beats a memory

Your library does not need software. One folder, one plain text file per prompt, named for what it does: vendor-table-from-notes, meeting-recap-6-bullets, invoice-fields-to-columns. Inside each file, four things: the prompt text, one line saying what it is for, one line saying what good output looks like, and the date you last changed it. That is the whole system. People skip this because a chat history feels like a library, but chat histories are unsearchable, unlabeled and eventually gone. Twelve well-named files beat 300 conversations. After three months you will reach for the folder before you reach for a blank prompt box, and that is when the compounding starts.

Client-free is the whole discipline

This is the rule that makes the library safe to keep: no client material inside it. No real company names, no real contacts, no numbers lifted from a delivered file, no fragment of a brief pasted in for context. Your saved prompt holds the situation, the job, the rules and your invented examples. It never holds the material. Written this way, the library is yours, it travels with you across every client you will ever serve, and there is nothing in it you would mind an operator reading. Written the other way, it is a copy of confidential work sitting in a folder on your laptop for a year. Same folder, entirely different object.

Version by keeping the old one

Versioning sounds technical and is not. When you change a prompt meaningfully, do not overwrite it. Copy the file, add v2 to the name, and edit the copy. Keep v1 until v2 has survived a few real tasks. At the top of v2, write one line: what you changed and why, such as added the no-summary-row rule after the operator flagged an extra line. Six weeks later, when v2 turns out to be worse in a way you did not anticipate, v1 is still sitting there and you lose ten seconds instead of an evening. The note matters as much as the file. A prompt with no history of changes cannot be reasoned about, only rewritten.

Write down what it is not for

The line people never write is the most useful one. Under each prompt, note the boundary: this works for meeting notes under 2,000 words, not for full transcripts. This handles vendor lists where the source is a table, not free text. Six months on, you will not remember why the summarizer produced nonsense that one night, and without the note you will assume the prompt is broken and rewrite it. It was not broken. It was used outside its range. Scope notes also stop you from stretching a prompt onto a task it half fits, which is where most bad output comes from. A prompt that says what it cannot do is a prompt you can trust.

Prune the library twice a year

A library that only grows becomes a pile. Twice a year, open the folder and read every file. Delete the ones you have not used in six months, because a prompt you never reach for is noise between you and the three you actually need. Merge near-duplicates into one prompt with a variable line. Promote the two or three you use weekly to the top by renaming them so they sort first. Twenty files you know cold beat sixty you have to search. This half hour also does something quieter: rereading your own prompts shows you the habits you have picked up, and usually one of them is worth removing.

Remember

  • One folder, one file per prompt, named for what it does.
  • No client material in the library, ever. Invented examples only.
  • Copy to v2 rather than overwriting, and note what changed.
  • Record what each prompt is not for; scope notes prevent false blame.
  • Prune twice a year. Twenty known files beat sixty searched.

Prove the change with frozen tests

~9 min

Better is a feeling until you measure

You edited a prompt at two in the morning, ran it once, liked the result, and saved it. That is the whole basis for calling it better. Two things could have happened: your edit improved the prompt, or that particular input was easy. You cannot tell from one run. Worse, the edit that fixed the length may have quietly broken the date format, and you will not find out until an operator does. This is the point where prompting stops being a knack and becomes work you can defend. Not because measurement is virtuous, but because you will keep editing prompts for years and you need a way to stop making them worse.

Freeze five inputs and their right answers

Build a test set once. Five invented inputs is enough, and they must be invented, because this file lives outside any task. Make them cover the range: two ordinary cases, one with a missing field, one that is unusually long, one with an edge you have been burned by before. For each, write the output you would accept, by hand, once. That hand-written answer is the known-good. It takes about an hour to build and you never build it again. Freeze it, meaning you do not quietly edit an input because the new prompt struggles with it. The moment the test set moves to suit the prompt, it stops measuring anything.

Change one thing, then rerun all five

Edit one thing at a time. Add the missing-value rule, or tighten the word limit, or replace an example, but not all three in one sitting. Then rerun all five test inputs, not the one that prompted the change. Score each against your known-good answer with a plain pass or fail, and write the result next to the version number. Now you can see the shape of the edit: four passes and one new failure is not an improvement, it is a trade, and you should know which trade you took. One thing at a time is slower on the night and much faster over a month, because when something breaks you know exactly which change did it.

The same input can give different answers

One thing to expect: run the same prompt on the same input twice and the wording will differ. That is normal and it is why you score against a standard rather than comparing the two outputs letter by letter. Your known-good answer is not a target the model must match exactly. It is a description of what an acceptable answer contains: these six columns, this date format, under 40 words, unavailable where the source is silent. Score whether the run satisfies that description. If a change makes results pass on some runs and fail on others, that is not a pass. Reliability is part of what you are testing, and an unreliable prompt is a prompt you will babysit forever.

Testing does not replace checking

A prompt that passes five frozen tests is a prompt you can start with. It is not a prompt you can deliver from unchecked. The test set proves the instruction behaves on inputs you already understand; the task in front of you is an input you have never seen, and it is real. Every row still gets the verification the standard requires, and the operator still reviews the work against a written standard before the client sees any of it. What testing buys you is a better first draft and fewer surprises, not permission to stop looking. The specialist who tests prompts and still checks output is the one whose deliveries pass review the first time.

Remember

  • One good run is not evidence. It may have been an easy input.
  • Five invented inputs with hand-written known-good answers, built once and frozen.
  • Change one thing, then rerun every test, not just the failing one.
  • Score against a description of acceptable output, not word-for-word matching.
  • A tested prompt is a better first draft, never an unchecked delivery.

Sit the exam

The courses are free. The work is real.

Twelve scenario questions. Pass at ten. Three attempts a day. The bar is the point.

No paid tier. No certificate fee. No upsell. Not now, not later.

Create a free account

You can start the first course tonight.

The curriculum

Everything, and what is in it.