Stop saying 'it's done' on feeling: a task-acceptance checklist for agents in vibe projects

Why "it's done" is the least trustworthy sentence

You hand a task to an agent, and half an hour later it says "done." You open it up: the page does have a new button, and the feature seems clickable, but you do not know whether it really fixed the bug, or what else it quietly broke along the way. You ask it "are you sure," and it confidently says "done" a second time. The agent is not lying. You simply have two different definitions of done: yours is "the user's problem is solved, and no new problem was introduced," while its is "the code is written, and it runs." When definitions differ, every acceptance becomes an argument.

This guide fixes the definition problem: before a task starts, write down what counts as done in an acceptance checklist that anyone can tick off. When the task ends, ignore the agent's self-assessment and check only whether each item on the list has evidence and meets its pass bar. If the list passes, the task is done; if it does not, send it back. No arguing, no going by feel.

First, the boundaries, because several neighbouring guides on this site are easy to confuse. The regression-verification baseline guide is about how to systematically regression-test a change after it has been made; this guide is about setting the acceptance standard before work starts. The AI-review second-check guide is about re-checking an AI review's conclusions; this guide does not review anyone's review, it accepts your own task. The agent handover pack is about how people and rounds hand work to each other; this guide is about how a single task is judged complete. The agent-damage rescue guide is about what to do after the agent has already broken code; this guide is about stopping breakage before it happens. The agent spend hard cap is about how much money triggers a stop; this guide ignores money and asks only "is it done." The AI-feature fallback and degradation guide is about keeping a degraded feature alive when it fails; this guide is about the completion standard for ordinary tasks. The agent data-access guardrails and agent permission contract are about what an agent may and may not touch; this guide assumes permissions are already settled and asks only whether the output is good enough. The last-hour launch runbook is about the execution flow on launch day, and the release-notes writing guide is about explaining an update to users; neither is this guide, which applies at the end of every task, not only on launch day.

The core method: acceptance first, in five steps

An acceptance checklist is not a summary written after the task. It is a contract written before the task, and the order cannot be reversed: write the list first, then let the agent touch code. The five steps are as follows.

Step one: write the result the user can see. Do not write developer-only phrases like "optimise the login module." Write "when users forget their password, they receive a reset email within 60 seconds and complete the reset." Results must be written in the user's language, because the user is the one who pays for the result, not the code. If a sentence has no subject, no action, and no observable phenomenon, it is not good enough — rewrite it.

Step two: break the result into verifiable items. One result usually maps to three to six items. The test for a good split is that each item can be answered with a yes or a no, with no room for "basically done" or "mostly fine." For example, "users can complete a reset" splits into four items: the reset email goes out; the reset link opens within its validity window; an expired link shows a clear error instead of a blank page; the old password stops working immediately after a successful reset. Every item is a yes-or-no question, not an essay question.

Step three: attach evidence to each item. Evidence is what the agent must hand over when the task ends, and the next section spells out the five kinds and what each one must look like. An item without evidence is an item without acceptance: "I tested it" is not evidence; pasting the command output, the API response, or a screen recording is.

Step four: set a pass bar for each item. A pass bar is a number, not an adjective. "The page loads faster" is not a pass bar; "the list page shows its first content within 3 seconds on a simulated weak 4G connection" is. "The bug is fixed" is not a pass bar; "20 historical failing inputs reproduce zero times, and 5 boundary inputs raise no errors" is. The more specific the bar, the fewer arguments at acceptance time.

Step five: write the return rules in advance. State up front which items, if failed, send the whole task back, and which items, if failed, may pass with issues provided they are logged as follow-ups with a next task named. Without return rules, acceptance turns into haggling: the agent will say "only this one item is missing, let's do it next time," and you will nod under pressure. Rules written beforehand are executed, not negotiated.

Five kinds of evidence, each with a picture of "good"

There are five kinds of evidence. Different tasks need different combinations, but "what good looks like" must be written down in advance, or you still will not be able to judge what the agent hands over.

The first kind is command output: the full output of test, build, or check commands. Good looks like this: the command itself is visible, the exit code is visible, and the key lines are not truncated. Just the words "tests pass" is not good enough, and neither are the last three lines alone, because you cannot tell which cases actually ran or whether failures were skipped.

The second kind is page evidence: before-and-after screenshots or recordings of the same page along the same operation path. Good looks like this: before and after appear as a pair, the operation path is written out (which entry point, what was clicked, what was typed), and abnormal states are included too — empty data, an overlong title, a network failure. Screenshots of only the success state are not good enough, because success states are the easiest to fake.

The third kind is API responses: example requests and responses for the key endpoints. Good looks like this: request parameters are visible, the key fields of the response body are visible, and there is at least one error case (not logged in, missing parameter, quota exhausted). A success response alone is not good enough, because real users will definitely hit the error cases.

The fourth kind is data evidence: a real row in the database or admin panel. Good looks like this: you can point to which record it is, what its key field values are, and whether its relationships are correct. For an "order status flow" task, the evidence should be one test order's timestamps at every status from placed to completed, not the sentence "the flow works."

The fifth kind is a human walkthrough record: you, or another collaborator, walking the list in person. Good looks like this: who did it, when, with which account, along which path, and with what result. A walkthrough is not "having a feel of it"; it is ticking the list item by item and signing it. Critical tasks must include this item, because automated evidence only proves "the machine thinks it is right," while a walkthrough proves "a human finds it right in use."

The acceptance matrix template: copy it as-is

Put the five steps into one table and you have the acceptance matrix. One table per task, placed at the top of the task brief, signed by you before the agent starts. The template:

Task name: ________________ Proposer: ________________ Date: ________________

The result the user can see (one sentence): ________________________________________________

Item one: ________________ Evidence type: ________________ Pass bar: ________________ Actual result: ________________ Verdict: pass / pass with issues / return

Item two: ________________ Evidence type: ________________ Pass bar: ________________ Actual result: ________________ Verdict: pass / pass with issues / return

Item three: ________________ Evidence type: ________________ Pass bar: ________________ Actual result: ________________ Verdict: pass / pass with issues / return

Item four: ________________ Evidence type: ________________ Pass bar: ________________ Actual result: ________________ Verdict: pass / pass with issues / return

Return rules: these items, if failed, return the whole task: ________________; these items, if failed, may pass with issues but must be logged as follow-ups: ________________.

Accepted by: ________________ Acceptance time: ________________

The table looks clumsy, and that clumsiness is exactly its value: it drives "you think" and "I think" out of the room and leaves only "the evidence says" and "the pass bar says." A solo team needs this table most, because you have no colleague to double-check you — the table is your second pair of eyes.

Three worked examples: a bug fix, a feature, a style change

Example one: fixing a bug. The task is "fix a coupon-stacking calculation error." The user-visible result: at checkout, coupons stack by the rules and the amount the user pays matches a hand calculation. Items include: 20 reproduction cases all pass (evidence: test command output; bar: 20 out of 20, zero failures); 5 boundary cases (expired coupon, exhausted coupon, amount exactly at the threshold) raise no errors and compute correctly (evidence: API responses); old orders are unaffected (evidence: data evidence, 10 historical orders sampled with amounts unchanged); the checkout page's breakdown matches the amount paid (evidence: paired before-and-after screenshots). Return rule: any reproduction case failing returns the whole task; a page-display issue may pass with issues but must be logged the same day.

Example two: adding a feature. The task is "add favourites to the article list." The user-visible result: a logged-in user can favourite an article, find it later in their favourites, and keep it after logging out and back in. Items include: favouriting and unfavouriting take effect immediately (evidence: page recording); the state survives a refresh (evidence: API response plus data evidence); an logged-out user who taps favourite is guided to log in instead of failing silently (evidence: page screenshot including the error state); an empty favourites list shows an explicit message instead of a blank page (evidence: page screenshot). Return rule: any data-loss issue returns the whole task; a copy issue may pass with issues.

Example three: changing a style. The task is "make the homepage title one size smaller on phones." The user-visible result: on phones the homepage title no longer wraps and overflows, and the reading order is unchanged. Items include: no overflow at three common phone widths (360, 390, and 430 pixels; evidence: one screenshot per width); the desktop title style is unchanged (evidence: paired before-and-after screenshots); long titles, short titles, and missing subtitles all render correctly (evidence: page screenshots). Return rule: overflow at any width returns the task, because for a style task the bar itself is "correct at every width" — there is no room for passing with issues.

The three examples share the same shape: no more than six items, concrete evidence, a bar with a number or a crisp condition, and return rules written in advance. You can swap in your own task's content using the same sentence patterns without inventing a new format.

Running acceptance: self-check, re-check, three verdicts

Once the list is written, execution has three steps. First, the agent self-checks: it works through the list item by item, hands over the evidence, and ticks its own boxes first. The point of self-checking is not to trust the agent; it is to force it through the list before it reaches you, so many basic problems get caught by the agent itself and you stop being the first line of defence.

Second, you re-check. You do not need to redo every item — that is too expensive. Use sampling: re-check every critical item (anything involving money, data, login, or deletion) in full, and sample one third of the non-critical items. When sampling, look for two things above all: whether the evidence really belongs to this task (no screenshots borrowed from another task), and whether it has been truncated, beautified, or cherry-picked to show only the successful parts.

Third, give a verdict. There are only three: pass, pass with issues, or return. Passing with issues requires all three of these conditions at once: the issue does not involve money, data loss, or security; the issue is logged as a follow-up with a next task named; and you personally sign off on it. If any condition is missing, the verdict can only be return. There is no fourth verdict, and in particular no "more or less passed": once a verdict goes fuzzy, the next acceptance will go fuzzier.

Return scripts: argue with the list, not the person

Returns turn into arguments most easily, because the agent — and the part of you it has talked around — hears a return as rejection. The scripts exist to move the argument's target from the person to the list. One script for each of the three situations:

When evidence is missing, say: "Item two requires the full command output; right now there is only a conclusion and no output. Please attach it and re-submit for acceptance." Do not say "you didn't test properly." Say only what the list requires and what is currently missing.

When the pass bar is missed, say: "The bar is 20 cases with zero failures; right now 2 of 20 fail. Please fix them and re-run all 20." Do not say "how could you get even this wrong." Say only what the bar is and what the current number is.

When scope creeps, say: "This task's items do not include changing the login page. Please open a separate task with its own list for the login-page change, and revert that change here for now." Scope creep is the most common "helpful breakage," and the rule is: never accept it casually inside the current acceptance. A separate task, a separate list.

Three sentences are banned: "good enough" turns the pass bar into a rubber band; "use your judgment" turns the list into scrap paper; "we'll add the evidence later" means the evidence will never be added. A list's authority comes from being enforced without discount every single time. Discount it once, and every later acceptance will ask for a discount.

Seven anti-patterns: seven ways to write a list and still get nothing

First, items written as adjectives: "improve the experience," "optimise performance," and "more stable" cannot be accepted. Rewrite them as numbers and conditions.

Second, evidence covering only success states: a list that never asks for error states or boundary states accepts only half the world.

Third, writing the list after the task is done: a list written afterwards will always be shaped to fit what was already built, with a one-hundred-percent pass rate — which is the same as no acceptance at all.

Fourth, a list signed only by the agent: without your re-check signature, the list is self-certification, with zero binding force.

Fifth, passing with issues but never logging them: a verbal "next time" will be forgotten. Issues passed with must land in the follow-up list the same day.

Sixth, a list that keeps growing: nobody executes a list longer than eight items. Split it into two tasks and two lists instead.

Seventh, using the list as a substitute for conversation: the list governs "is it done," not "is the direction right." If the direction is wrong, passing every item is still wrong — direction must be discussed before the task starts, not at acceptance time.

Rollout for a solo team: running in a week

The first week needs no new system, just three actions. First, save the acceptance-matrix template as a fixed file; every new task copies it to the top of the task brief, and the agent's first instruction is "read the acceptance matrix before touching anything." Second, retrofit lists onto history: pick your three most recent completed tasks, reconstruct their acceptance items using this guide's method, and you will immediately find at least one task that was actually not good enough — that discovery is itself proof of the list's value. Third, set one personal iron rule: no task starts without an acceptance matrix, and no task ships without a re-check signature. Hold the rule for three weeks and it becomes a habit; after that, a list costs under ten minutes per task, while the rework it blocks is worth far more than ten minutes.

Back to the opening sentence: when the agent says "done," you neither need to doubt it nor believe it. Open the list and ask three questions, item by item: where is the evidence? Did it meet the pass bar? Did any return rule trigger? Once those three questions are answered, the verdict writes itself. An acceptance checklist is not distrust of the agent; it moves trust from "feeling" to "evidence" — and evidence is the one thing that never changes its story at midnight.

Appendix: the acceptance checklist (tick before every task)

Is the result written as one sentence in the user's language? Are there three to six items, each a yes-or-no question? Does each item name an evidence type? Does each item have a numeric pass bar? Are the return rules written in advance? Are critical items fully re-checked and one third of non-critical items sampled? Is the verdict one of the three, with a signature? Were pass-with-issues items logged as follow-ups the same day? Only when all eight answers are yes may the list be used; if any answer is no, fix the list first, then start work.