Claude Code: Define Acceptance Checks Before Completion

For developers using the coding agent, the actionable change is to define what evidence counts as completion before work begins. A successful build, relevant test results, and a demonstrated user flow provide a clearer handoff than a confident statement that a feature is finished.

Turn requirements into acceptance checks​

Faisal’s checklist covers five areas: building the project, running relevant tests, exercising the feature end to end, checking console errors or regressions, and comparing the implementation with the original request. When a check fails, she asks Claude to fix the problem and repeat verification before declaring completion.

Those checks answer different questions. A build establishes that the project can pass its build process; it does not establish that every requested behavior works. Tests provide evidence about the cases they exercise. An end-to-end check connects the implementation to the actual sequence a user needs to complete.

The final comparison with the original request addresses another problem: a working implementation can still omit a requirement. Faisal specifically reports noticing omissions with longer prompts, making a requirement-by-requirement review part of her completion process.

A reusable instruction, adapted from that approach, is:

Before reporting completion, build the project, run the relevant tests, exercise the requested user flow, and inspect the available console output for errors. Compare the result with every requirement in my original request. Fix failures and repeat the affected checks. In your handoff, distinguish checks that passed from checks you could not perform.

Click to expand...

The final sentence is an editorial recommendation: it makes the evidence easier to evaluate without pretending that every project offers the same verification facilities. An unavailable check should remain visibly unverified.

The build command, test selection, and user flow must come from the actual project. There is no universal command that safely substitutes for all three.

Where /goal changes the workflow​

According to Faisal, Claude Code’s /goal command is useful when the desired end state is clear but the implementation steps are not. Her examples include completing a feature end to end or bringing a project to a state without failing tests. A checklist specifies known checks; a goal lets the agent work toward an outcome without the developer prescribing every intermediate action.

In separate September reporting, XDA Developers describes /goal as using a separate evaluator to assess whether the conversation demonstrates that the completion condition has been met. When the evidence is insufficient, the evaluator identifies remaining work and feeds that assessment into Claude’s next instruction. That report comes from the same outlet, so it is supporting explanation rather than independent confirmation of Faisal’s results.

A community-maintained technical reference in GitHub user yshmr’s claude-code-goal-draft-policy repository likewise describes this continuation mechanism. It says the evaluator judges the conversation and does not independently run commands or read files. This is a community summary of Anthropic documentation, rather than a directly verified primary release record.

The practical implication is straightforward: make the completion condition observable. “Make this feature good” leaves the stopping decision subjective. A condition naming the required behavior and the check that demonstrates it gives both the coding agent and its evaluator something concrete to assess.

It also explains why a second model’s approval should not be mistaken for an independent test run. If the assessment depends on evidence in the conversation, Claude needs to surface actual verification results—not merely summarize its confidence.

Give Claude feedback it can act on​

Faisal attributes her verification approach to advice from Claude Code creator Boris Cherny: give Claude a way to verify its own output. In her workflow, that means running available tests and fixing failures, or opening a UI in a browser and interacting with the feature rather than assuming the code produces the intended result.

Browser verification is conditional on the session having the necessary access and tools. Asking for it does not, by itself, establish that Claude can launch and operate the application. Where that access is absent, the browser check remains a human task rather than an automatically satisfied requirement.

The useful feedback loop is:

1. Define the behavior that must work and the evidence needed to demonstrate it.
2. Have Claude implement the change and execute the available checks.
3. Feed failures back into the implementation process and repeat verification.
4. Compare the finished behavior against the original requirements before accepting the handoff.

This organizes the technique around acceptance criteria rather than repeated requests to “try harder.” It also separates two responsibilities: the developer chooses what completion requires, while the agent performs work and gathers evidence against that definition.

What the reported improvement establishes​

Faisal says this approach produced substantially better results in her work, but the available reporting includes no controlled before-and-after comparison, defect count, or independently reproduced quality measurement. The supported finding is narrower: she reports catching more issues before they reached her, using explicit checks and a more deliberate completion process.

For a development team, the immediate adoption decision need not depend on a promised percentage improvement. Start by making the completion requirements explicit and requiring a handoff that shows which checks actually ran. Use /goal for a clearly defined end state where the command is available, while retaining human acceptance of the result.

A passing check supports the behavior it examined. Keeping that boundary visible makes Claude’s “done” a reviewable claim rather than the end of the review.