Acceptance review
Check what was built against one spec, criterion by criterion, with the evidence from your code cited.
A readiness review asks whether a spec is ready to build. An acceptance review asks the question that comes after: was it built? Run it on one spec and Plansmith reads your code, then reports on every acceptance criterion, one row each, with the commit it read named at the top.
Type /acceptance-review and the spec's issue tracker key, or pick Acceptance review from the
skills list in the plan.
What it reads
- Give it the spec's issue tracker key and it finds the pull request or branch that mentions it. When exactly one change names the key in its title, branch or description, it reviews that one and tells you which. When the only match does not name it there, it asks you to confirm that change first. When several do, it asks you which, open pull requests first. When none does, it checks your default branch and says so.
- Give it a pull request (a number or its address) or a branch name and it uses that.
- Give it nothing else and it reads your default branch.
For a pull request it reads the change itself and any other file as it stands in that pull request, never the default branch's copy. Every report names the exact commit it read, because a branch moves.
It needs a linked repository. With none, it tells you to link one under the project's Settings → Code and writes nothing.
What the marks mean
| Mark | Meaning |
|---|---|
| 🟢 Built | The code that does this is there, and the report cites it. |
| 🟡 Partial | Some of it is there. The report says which part is not. |
| 🔴 Not found | Nothing does this, or the code does the opposite, or it could not be checked. |
| ⚪ Not applicable | Reading code cannot answer this criterion, and the row says why. |
White is not a shrug. A criterion nobody could check is red, with "Not assessed" and the reason. White means code cannot answer it at all, such as "approving 200 payouts feels instant".
The review's verdict is read off the table: Built when every row is green or white and at least one criterion is green, Not built when nothing is green or yellow, and Partial otherwise. When every row is white, the verdict is Not built and its sentence says code cannot answer any of these criteria. A spec with no acceptance criteria gets no report: write its criteria first.
What it never does
It never rewrites your spec to match what was built. When the code and the spec disagree and either could be right, it adds a question to the spec's open questions, marked as raised by the acceptance review, and you answer it the way you answer every other question. Behavior the change ships that no criterion asks for is listed as an observation, never turned into a new criterion.
Reading code shows what is there. It cannot prove the behavior is correct, and the report keeps that line visible.
Where it lands
In a file at context/acceptance-reviews/SPEC-12.md, one per spec, rewritten each time you run it,
with every earlier version kept. Its heading, its card in the chat and the agent's replies name the
spec by its issue tracker key, such as PAY-142, once the spec is in your issue tracker.
Extending it
A company or project skill can extend the acceptance review with your team's own checks. See Extending a skill. It opens three points:
| Point | What your text adds |
|---|---|
extra-checks | Checks to run on every criterion, such as "a test pins it". |
built-bar | What Built also requires. It can only raise the bar, never lower it. |
extra-rows | Rows below the criteria, with the same three cells. A team row can hold Built back, never grant it. |
An extension cannot move the report to another folder, change its shape, or ask the agent to rewrite the spec from what was built.