LULUSKILL ARTICLE
How to check what an AI assistant made for you
Turn your acceptance check into a short test session: what to try, how to write down what failed, how to describe it back to the assistant, and when to stop and re-plan.
This is LuluSkill's own writing. It does not quote, mirror or summarise any third-party Skill, and it recommends none. Reading it builds, publishes and runs nothing: what an AI tool does with your text is for you to check.
A first version that looks finished still has to pass your check
When an assistant hands back a first version, it usually looks finished: the pages have headings, the buttons have labels, and there may be a note saying that everything is done. None of that tells you whether the person you wrote the brief for can do the job you wrote it for. Only trying it does.
You do not need to read code for this. You are checking behaviour: what a person does, and what they see back. The acceptance check you wrote into the brief is where the session starts, because it is the test you already agreed would decide whether the result is worth keeping.
Three words this article uses
In plain words
- Test sheet
- Your acceptance check, rewritten as numbered steps, each with what you do and what you expect to see.
- Failure note
- A few lines about one thing that did not match what you expected: where it was, what you did, what you expected, and what happened.
- Re-plan
- Going back to the brief and changing a decision in it, instead of asking for yet another fix to the same result.
Before the session starts
- Use invented test data — made-up names and dates — rather than the real details of the people who will use it.
- Leave the version you are testing unchanged until the session ends, so that every note describes the same thing.
- Do not share it with the people it is for yet. A first version that has not passed its check is still yours to test.
- If it asks for a password, a payment or a real address, stop and check whether the brief asked for that at all.
Turn your acceptance check into a test sheet
An acceptance check is usually one sentence, such as "two volunteers sign up for the same shift from two phones, and both names appear". That is the goal of the session, but not yet something a helper can follow without asking you questions. A test sheet is the same sentence, unfolded into the steps a person actually takes.
Write it so that someone who has never seen the project could follow it. If a helper gets stuck on the sheet itself, the problem is in the sheet, not in what the assistant made.
Write each line of the sheet like this
- Number the step, so a note can say "failed at step 4" instead of describing the whole path again.
- Say what the person does, with the exact input: "type the name Mei and tap the first Saturday", not "sign up".
- Say what they should see afterwards, in words you could hold up against the screen: "Mei appears under the first Saturday".
- Mark the step that is the acceptance check itself, so everyone knows which failure matters most.
- End with a step that checks the result is still there: close the page, open it again, and look.
At the top of the sheet, write down
- Which version you are testing, and on which device — starting with the one your people will actually use.
- The invented test data you will type, so that a second session uses the same names and dates.
- What is out of scope, so a helper does not report a missing feature you chose not to ask for.
A blank test sheet
Example
Copy these lines into a note and fill the brackets, then delete the brackets. Five steps are usually enough for a first version.
- Version and device: [which version, and the device your people actually use]. Out of scope: [the list from the brief].
- Test data: [the invented names, dates and values you will type, the same ones every round].
- Step 1: [what the person does, with the exact input]. Expect: [what they should see, in words you can hold up against the screen].
- Step 2: [the next action on the ordinary path]. Expect: [the visible result].
- Step 3, the acceptance check: [the sentence from the brief, written as something two people do]. Expect: [the result the brief promised].
- Step 4, the mistake path: [one wrong or missing input]. Expect: [a message saying what to do next, and nothing saved].
- Step 5: [close everything and open it again]. Expect: [everything from the earlier steps is still there].
The brackets are the point: a sheet is finished when every one of them is gone, and a sheet that still has a bracket is a question you would otherwise answer by guessing mid-session.
What to try, and in what order
Order matters, because early failures hide later ones. If the ordinary path does not work, there is little point in testing what happens after a typo. Start with the sheet exactly as written, and widen out only once it passes.
One session, in this order
- The ordinary path, exactly as the sheet says, on the device your people use. Do not help, skip or work around anything.
- The acceptance check itself, even if it is awkward to arrange — two phones, two people, the same moment.
- The mistake path: leave a field empty, type a date in the wrong format, press the main button twice.
- Interruptions: go back in the middle, reload before saving, close everything and open it again later.
- Someone who should not see it: open the page in a private window, without signing in, and look at what a stranger would see.
- Every message, in every language the brief asked for — including error messages, which only appear when something goes wrong.
Things that look fine but deserve a second look
- A "saved" message. It is a claim, not proof: reload the page and see whether the thing is really there.
- Sample content left in place: placeholder text, example names, and numbers that look real but were made up.
- Features you did not ask for. Compare them with your out-of-scope list; each one is one more thing to check and to look after.
- Anything that says it sends a message or a reminder. Find out whether it really does, and to whom, before any real person's details go in.
How to write down what failed
Write each failure down the moment you see it. Memory smooths things over: an hour later, "the name vanished after I tapped Save on the second phone" has become "sign-up is a bit unreliable", and nobody can act on the second sentence.
A note describes; it does not diagnose. If you have a guess about the cause, add it at the end and mark it as a guess. The facts come first, because they stay true even when the guess is wrong.
The six lines of a failure note
In plain words
- Where
- The step number on the sheet, and the page it happened on.
- What I did
- The exact action, input and device: "on the second phone, typed Ana and tapped Save".
- What I expected
- The line from the sheet, copied rather than paraphrased.
- What happened
- What you saw, with the exact wording of any message. Copy it; do not summarise it.
- How often
- Every time, sometimes, or once. Try again before you decide, because each one calls for a different fix.
- How much it matters
- It blocks the key flow, it is wrong but has a way around it, or it is cosmetic. This sets the order you report in.
Keeping the notes useful
- One failure per note. Two problems written up together tend to come back with only one of them fixed.
- Leave out real personal details. If a failure only appears with real data, describe the data instead of copying it.
- Note what passed, too. A short "steps 1 to 3 passed" tells you, next round, whether a fix broke something that used to work.
Six mistakes made while checking, and what to do instead
A test session can fail without anything being wrong with the result. When that happens the notes look convincing and point at the wrong thing, which is worse than having no notes at all. Each row below is a way the session itself goes wrong, and what to do at the moment you notice it.
| The mistake | How you notice it | What to do instead |
|---|---|---|
| Testing a version that is already changing | Two notes describe the same step differently, and you cannot say which build produced either. | Stop, write down which version you are on, and start the sheet again from step 1 on that one version. |
| Helping it along | A step passed, but only after you reloaded, retyped or waited in a way the sheet does not mention. | Write the workaround into the note as part of the failure, and let the step count as failed. |
| Notes that diagnose instead of describe | The note says what you think the cause is, and nothing about what you did or saw. | Rewrite it with the four facts first — where, what I did, what I expected, what happened — and add the guess at the end, marked as a guess. |
| One note holding three problems | The note is hard to mark as fixed, because part of it still fails. | Split it into one note per problem before sending anything back, and rank them. |
| Only the failures were written down | After a fix you cannot tell whether a step that used to pass still does. | Add one line naming the steps that passed, and check those first on the next round. |
| Real details typed into the test | The notes or the result now contain something about a real person. | Stop the session, replace the data with invented values, and describe the real case instead of copying it. |
Comparison
One session, worked through: the volunteer sign-up page
The example continues the invented food bank from the article on writing a prompt. The coordinator has a first version of the sign-up page, one volunteer and two phones. It is an illustration, not a prediction of what any real result will contain.
The test sheet
Example
The coordinator's one-sentence check, unfolded into five steps. Test data: the invented names Mei, Tom and Ana.
- Version: the one that came back on Tuesday. Devices: two phones. Out of scope: passwords, text reminders, reports of hours.
- Step 1: open the page on phone A. Expect: the next four Saturdays, each with its shifts listed.
- Step 2: type Mei and tap the morning shift on the first Saturday. Expect: Mei appears under that shift.
- Step 3, the acceptance check: type Tom on phone A and Ana on phone B, and tap the same afternoon shift on both at almost the same moment. Expect: both names appear, on both phones.
- Step 4: tap Save with the name field empty. Expect: a message asking for a name, and nothing saved.
- Step 5: close the page on both phones, then open it again on phone A. Expect: Mei, Tom and Ana are all still there.
Five steps, and a helper who has never seen the project could follow every one. Step 3 is marked because it is the check the whole brief was written around.
What the session found
Example
Three failure notes written during the session, most serious first, and one line for what passed.
- Note 1, step 3, blocks the key flow: Tom and Ana tapped the afternoon shift a moment apart. Expected both names. Both phones show only Ana, even after a reload. Happened on both tries.
- Note 2, step 4, wrong but has a way around it: Save with an empty name added a blank entry to the shift, and no message appeared.
- Note 3, not on the sheet, out of scope: a "send reminder" button appears under each shift and shows "Reminder sent" when tapped. Nobody gave it a phone number, so it is unclear what, if anything, was sent.
- Passed: steps 1, 2 and 5. The page also fits the phone screen without sideways scrolling.
Note 1 goes back first, even though note 3 is more surprising: it is the acceptance check, and until it passes the page does not do its one job. Note 3 is reported as an addition to remove, not as a feature to repair.
How to describe a failure back to the assistant
"It doesn't work, please fix it" leaves the assistant to guess which part failed and what working would look like, and the guess may change parts that were fine. A useful message carries the note across almost unchanged.
Send one failure at a time, most serious first. Ask for the likely cause and the planned change before anything is changed, so you can spot a misunderstanding while it is still only words.
What to write back: a template
Example
Copy these lines, fill in the brackets from one failure note, and then delete the brackets.
- Which step: [the step number, and what the step is for].
- What I did: [the exact action, the input, and the device].
- What I expected: [the line from the sheet, or the sentence of the brief it comes from].
- What happened instead: [what I saw, with any message copied exactly]. It happened [every time / sometimes / once].
- Before changing anything: tell me what you think causes this and what you plan to change. Change only what this needs, and tell me how I can check that it is fixed.
The last line does most of the work. It turns a request for a fix into a short conversation you can stop at any point, and it asks for a way to check the fix instead of a statement that it is done.
The same template, filled in
Example
Note 1 from the session, as the coordinator sent it back.
- Which step: step 3 of my test sheet, two volunteers signing up for the same shift at once. This is the acceptance check from my brief.
- What I did: typed Tom on one phone and Ana on another, and tapped the first Saturday's afternoon shift on both, a moment apart.
- What I expected: both names on the shift, on both phones, because the brief says that both names must appear and neither may disappear.
- What happened instead: only Ana is listed, on both phones, even after a reload. It happened both times I tried.
- Before you change anything, tell me what you think causes this and what you plan to change. Please leave the rest of the page as it is, and tell me how I can check the fix.
No technical words are needed. The coordinator does not say why the name vanished, only that it did and under what conditions — which is what anyone looking for the cause needs first.
When the answer comes back
- If the explanation does not match what you saw, say so before any change is made. A fix aimed at the wrong cause can add a new problem.
- After a change, follow the whole sheet again from step 1, not only the step that failed. A fix in one place can break a step that used to pass.
- Mark a note as fixed only when its step passes on the device your people use — not when a message says it is fixed.
When to stop fixing and plan again
Fixing one failure at a time works while each round leaves fewer notes than the last. When that stops — the same failure returns, or every fix creates another — more rounds of the same kind are unlikely to help. The problem is often not in the last change but in a decision the brief never made.
Signs it is time to stop and re-plan
- The same failure comes back after two or three rounds of fixes.
- Each fix breaks a step that passed before, so the number of notes stays the same or grows.
- You cannot write the "what I expected" line, because the brief never decided what should happen.
- The failures are in features you did not ask for, and removing them keeps breaking the ones you did.
- The result has grown well beyond the one-page plan, and you can no longer say which path is the key flow.
How to re-plan without starting from nothing
- Stop asking for fixes. Keep the latest notes, and keep the last version that passed the most steps.
- Read the notes against the brief and find the answer that was missing or unclear — often who it is for, what done looks like, or what is out of scope.
- Rewrite that one answer, add the rule the failures revealed in plain words — "two people may sign up for one shift at the same moment" — and add a step to the sheet that checks it.
- Hand over the revised brief and the sheet together, and say whether to continue from the last version or begin again from the brief.
A first version passes when
- Every step on the sheet passes, on the device your people use.
- It passes twice in a row, with the page opened fresh each time.
- Someone other than you followed the sheet, and you did not help.
- Nothing from the out-of-scope list has crept in.
Passing is not a promise that nothing else is wrong. It means the person you wrote the brief for can do the job you wrote it for. Everything else you noticed goes on the list for the next version, each item with its own check.
Your next step
Three things to do with your own idea, in order. None of them needs an account, a tool or a Skill.
- Rewrite your acceptance check as a test sheet of about five numbered steps, each with what you do and what you expect to see.
- Ask someone who has not seen the project to follow the sheet on a phone while you write one note per failure, without helping.
- Send back only the most serious note, using the template, and follow the whole sheet again after the change.