Definition-of-Done & Acceptance-Criteria Checker

The problem this kills

"Done" is the most overloaded word on your team. Someone drags a card to the Done column — but were the tests actually run? Did the docs get updated? Did anyone review it? Did the product owner actually sign off? Half the time the answer is "probably," and the other half it's a bug that ships, a doc that never gets written, or a release that bounces back into the sprint.

You already have a Definition of Done. You already have acceptance criteria on your stories. The problem is nothing enforces them. They live in a wiki page nobody opens and a story description nobody re-reads before clicking the button. There's no gate between "I think it's done" and "it's marked done."

This plan builds that gate. Nothing gets marked done until every acceptance criterion and every Definition-of-Done item is checked off by a real person — and you get a permanent record of who confirmed what.

What you'll build

A small, login-protected web app for your team:

• A work-item queue — pulled from your CSV or Google Sheet (or your tracker later) showing everything waiting to be confirmed done.
• A per-item review screen — the item's acceptance criteria on one side, your team's Definition-of-Done checklist on the other, each as a checkbox a reviewer ticks.
• A hard "done" gate — the Approve button stays locked until every box is checked. No skipping, no "we'll fix it later."
• An editable DoD checklist — different checklists per team or per work-type (a bug fix has different gates than a new feature), maintained inside the app.
• A full audit trail — who confirmed each criterion, and exactly when.
• A clean CSV export — the confirmed done-statuses, in the exact columns your tracker or spreadsheet expects.

What's inside the Implementation Plan

The plan is a single markdown file you paste into Claude Code. It walks the AI through building the whole tool, step by step, with a ready-to-copy prompt at the end of each step.

The most important part: the plan opens by interviewing you about your business — your current "done" process, what tracker or spreadsheet you use, how your acceptance criteria and item IDs are actually named, your real DoD items, your typical and peak volumes, and your messy edge cases (partial done, reopened items, items with no criteria). It reflects a short tailored spec back to you and waits for your thumbs-up before it builds anything. You get a tool shaped around how your team works, not a generic template.

The governance it includes (this is the point)

This isn't a toy checklist — it's a control. Built in from the start:

• Login so only your team can use it.
• Row-level security so each team or organization only ever sees its own work items and checklists.
• A complete audit trail — every criterion confirmation is stamped with who and when.
• A hard human-in-the-loop approval gate — the tool never marks anything done on its own. A reviewer confirms each criterion and approves; only then does the status change and the export update.
• Duplicate guards — an item is matched on its ID so it can't be "done-confirmed" twice.

Who it's for

Scrum masters, team leads, QA leads, and product owners who are tired of "done" meaning five different things. If you own the quality bar for a team and want it to actually hold, this is for you. No coding experience needed — you'll describe how your team works, and the AI builds it.

You've got this — paste the first prompt and let the agent interview you.