# Robisie Acceptance Bench > Learn the acceptance-bench procedure — how to submit finished work for review with evidence, and how a reviewer confirms it is really done. Use this when you (an AI agent) move a task to review, or when you are asked to accept or reject work another agent finished. - Skill: `chuppa12/robisie-acceptance-bench` (Agent Skill) - Install (CLI): `npx skillmds@latest add chuppa12/robisie-acceptance-bench` - Raw SKILL.md: https://api.skillmd.com/api/skills/chuppa12/robisie-acceptance-bench/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - Author: chuppa12 (https://skillmd.com/u/chuppa12) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/chuppa12/robisie-acceptance-bench --- # Robisie acceptance-bench — evidence-based acceptance for AI agent work You are reading this because you are about to hand finished work to a reviewer, or because you were asked to review work an agent says is finished. Either way the question is the same: **how does anyone know this work is actually done?** This skill is the answer — a small, strict procedure called the acceptance-bench. It separates *work that is claimed done* from *work that is confirmed done*, and it applies to **any** delegated work: code, prose, data, designs, decisions. The mechanics run on robisie (the agent-readable kanban board this domain serves over MCP) and need exactly three tools — `append_detail`, `update_task`, `get_task` — and three statuses. If you can call those tools, you can run the whole procedure. ## The one rule An agent finishing a task **claims** it is done. A human — or a designated reviewer — **confirms** it is done. Those are two separate, provable facts, and the second never happens automatically just because the first happened. Skip that separation and you don't have an acceptance procedure, you have a rubber stamp. Everything below is machinery for keeping those two facts separate and checkable. The agent submission loop is: Call `get_next_task`, then `reserve_task`; do the work; call `append_detail` with evidence; call `get_task` and verify the evidence is present; only then call `update_task` with `status: "in_review"`. ## The protocol of proof A claim needs evidence before it can be reviewed. Evidence is **whatever a skeptical reviewer needs to check the claim without redoing the work**: - **Code** — a link to the diff or pull request, plus test output (ideally failing → passing). - **Text** (an email, a report, documentation) — a link to the document, plus a one-line summary of what changed against the brief. - **Data or numbers** — the before and after values, and where they came from. - **UI or anything visual** — a screenshot of the result. The rule is always the same; only the form of the evidence changes. "I fixed it" is a claim, not evidence — a submission without evidence is not reviewable, it is just a request to be trusted. Attach the evidence to the card, then submit it: ``` append_detail(taskId, { evidence: "PR #42 — checkout test: failing → passing" }) get_task(taskId) // verify the evidence is present update_task(taskId, { status: "in_review" }) ``` ⚠️ **Always attach evidence with `append_detail`**, which merges new fields into the card's `details` without touching the rest. Calling `update_task` with a `details` object **overwrites the entire field** — including evidence attached earlier. That is the fastest way to destroy the very proof this procedure depends on. ## The lifecycle (three states, not two) A submitted card moves through three states — these are the literal `status` values: - **`in_review`** — *submitted*: the agent claims the work is finished, evidence attached. Nothing is confirmed yet. - **`delivered`** — *delivered*: the output exists where it is supposed to — the email went out, the feature is deployed, the document is filed. But nobody other than the agent has confirmed it is **correct** yet. - **`done`** — *confirmed*: a reviewer checked the evidence and it holds up. This is the only state that means "done". Why the middle state exists: **"delivered" and "actually correct" are different facts.** An email can be sent and wrong. A feature can be deployed and broken. A report can be filed with an error in its central number. Collapsing "delivered" into "done" is exactly how a broken thing gets marked finished before anyone has looked at it. And the closing rule: **only the reviewer moves a card to `done` — never the agent that did the work.** Even when one person plays both roles, the move to `done` must be its own deliberate act, performed after looking at the evidence — not a reflex bundled into the submission. ## Reviewing beyond the code/PR frame — two worked examples Most review tooling assumes the work is code and the evidence is a diff. This procedure does not. **Example A — code.** Task: *"Fix the checkout error."* The agent fixes it, then attaches evidence and submits: ``` append_detail(taskId, { evidence: "PR #87 — repro test added; before: 500 on submit, after: order created. CI green." }) get_task(taskId) // verify the evidence is present update_task(taskId, { status: "in_review" }) ``` The reviewer opens the PR link, reads the test output, and confirms the failing case now passes. Once the fix is live and behaves, the card moves through `delivered` to `done`. **Example B — not code.** Task: *"Draft the onboarding email for new customers."* There is no diff and no test suite. The agent attaches the draft itself, plus what changed: ``` append_detail(taskId, { evidence: "Draft: . Summary: rewrote the opening to lead with the 30-second setup, per the brief; dropped the feature list." }) get_task(taskId) // verify the evidence is present update_task(taskId, { status: "in_review" }) ``` The reviewer reads the actual email — not a diff — and checks it against the brief: right audience, right claims, right tone. If it holds up, they confirm it and move the card to `done`; if not, it goes back with a note saying what to change. The point of Example B: the exact same two-role separation and the exact same evidence requirement applied, and **nothing about this procedure assumed code or a pull request**. If your delegated work is contracts, spreadsheets, or slide decks, the bench works unchanged. ## Common failure modes - **The agent flips its own card straight to done.** No separate confirming act happened — that is the rubber stamp from the first section. The claim and the confirmation must be two distinct acts, and whenever possible come from two distinct parties. - **Evidence too vague to check.** "I fixed it", "looks good now", "done as requested" — none of these let a reviewer check anything without redoing the work. Attach the thing itself: a link, test output, before/after values, a screenshot. - **Evidence silently erased.** Somebody called `update_task` with a full `details` object and wiped the evidence attached earlier. Use `append_detail` for every addition; reach for `update_task`'s `details` only when you mean to replace everything. - **Treating `delivered` as the finish line.** It is the still-open middle state. The output exists, but until a reviewer confirms it, the card is not done — it is merely out in the world. ## Quick reference ``` 1. Finish the work. 2. append_detail(taskId, { evidence: "" }) 3. get_task(taskId) and verify the evidence is present. 4. update_task(taskId, { status: "in_review" }) 5. (delivery happens) → status becomes "delivered" 6. Reviewer opens get_task(taskId) and checks the evidence. 7. Reviewer moves it to "done" — only after checking, never on the agent's word alone. ``` ## Troubleshooting - **A card sits in `in_review` with no movement** — nobody has reviewed it yet. That is not a bug; the procedure is *waiting for a reviewer*, which is the whole point. Nudge whoever reviews — do not "unblock" the card by moving it forward yourself. - **I'm both the reviewer AND the one who did the work** — still perform steps 6–7 of the quick reference as a distinct, deliberate act: reopen the card with `get_task`, read the evidence the way a stranger would, then move it. Do not fold the review into the submission. - **How much evidence is enough?** — ask: could a skeptical reviewer check the claim without redoing the work? If they would have to redo it, attach more. - **Evidence I attached earlier is gone** — something called `update_task` with a full `details` object, which replaces the whole field. Re-attach what was lost with `append_detail`, and use `append_detail` going forward. ## How this fits with delegation-loop This skill is the companion to the delegation-loop skill (`/SKILL.md`) — that one gets an agent connected to the board and taking work on its own; this one governs what happens when the agent says a card is finished. If you are not connected to a board yet, start there.