The word done is not the evidence

A coding agent can write files, run commands, and use a project’s existing checks. That does not mean every button works, every requirement is covered, or the result is safe to publish.

A better finish asks for visible evidence: what changed, which checks ran, what passed, what failed, and what could not be tested.

Add this before the final answer

Prompt
Before you say this task is done, verify the work.

1. Read the project instructions and find the existing tests, lint checks, type checks, build command, and any relevant browser or manual checks.
2. Run the checks you can safely run.
3. Fix failures caused by your changes, then rerun the relevant checks.
4. If browser tools are available, open the changed screen and test each active link, button, and form with safe fake data. Check a narrow phone view too.
5. In your final response, list: files changed, commands run, pass/fail results, and anything you could not verify.

Do not claim something is tested when you could not run the check. Stop and explain any blocker instead of hiding it.

Match the check to what changed

  1. For a page: open it, use the interactive parts, and check the phone layout.
  2. For a form: try valid input, invalid input, and a safe test submission if the project supports it.
  3. For a data change: run the project’s migration or test path and confirm the expected record behavior.
  4. For code: run the targeted test, then the project’s build, lint, or type checks when they exist.

Testing narrows risk. It does not remove it.

A passing test suite cannot tell you whether the product makes sense, whether the copy is right for people, or whether a hidden integration will behave exactly like production. It also cannot cover checks that do not exist.

Treat a clean report as a better handoff for your review, not permission to skip looking at the actual thing you asked it to make.

Read the last message like a checklist

  1. Look for the exact commands and results, not “tests passed.”
  2. Read every blocker and unverified item before you merge or publish.
  3. Open the key user path yourself when the change affects customers, money, private data, or a public page.
  4. Keep the test instruction in the project’s own guidance if you want every future task to follow it.
Sources2