Never say work is done, fixed or passing without fresh evidence: run the command that proves it, read the output, and report what it actually shows, before marking a Gryz task done, committing, opening a pull request or telling the person it works. Use whenever you are about to say "done", "fixed", "tests pass", "it works", or to move a task to done. Do NOT use for planning or exploring before any work exists, or for questions that make no claim about the state of the work.

# Check before done Evidence first, then the claim. If you have not run the check in this session, you cannot say it passes. ## When to use - You are about to say "done", "fixed", "tests pass" or "it works". - Before committing, opening a pull request, or moving to the next task. - Before marking a Gryz task done, or writing a status update or handoff that says something works. - After another agent or tool reports success. ## Do NOT use for - Planning or exploring before any work exists. - Questions that make no claim about the state of the work. ## The check Before any claim about the state of the work: 1. **Name the proof.** Which command or check would show this claim is true? 2. **Run it,** fresh and in full, in this session. 3. **Read the output:** the exit code, the count of failures, the warnings. 4. **Compare.** Does the output actually confirm the claim? - No: say what the real state is, with the evidence. - Yes: make the claim, with the evidence. Skipping a step is not verifying. ## What proves what | Claim | Proof | Not proof | | --- | --- | --- | | Tests pass | The test run, 0 failures | An earlier run, "should pass" | | Lint is clean | The linter output, 0 errors | A partial check | | It builds | The build command, exit 0 | Lint passing, logs looking fine | | The bug is fixed | The original symptom, now gone | The code changed | | A regression test works | It failed without the fix, passes with it | It passed once | | Another agent finished | The diff shows the changes | Its report says "success" | | The requirements are met | Each one checked against the spec | The tests pass | ## Warning signs Stop and run the check when you notice: - "should", "probably", "seems to"; - saying "Great!" or "Done!" before you have looked; - trusting a report you did not check; - wanting to finish because the session has been long. ## Reporting - Say what you ran and what it showed: "Ran the test suite: 214 passed, 0 failed." - When something did not pass, say so first, plainly, with the failing part. - When you could not run the check (no access, no test setup), say that instead of claiming success: "I couldn't run the tests here, so this is untested." ## In Gryz - Mark a task done with `update_task` only after its check passes, and add the evidence to the task's description: the command and its result. Read the task with `get_task` first and send the existing description plus the new line, because `body` replaces the whole description. - A status update, handoff or changelog published with `publish_document` says only what was verified. Anything unverified is labeled as such. - If a task's check fails, leave the task open or set it to `blocked`, and say why. ## When Gryz is not connected The check itself needs no Gryz tools. If `update_task` is not available, tell the person once: "I can't reach your Gryz tasks here, so I can't update them. Connect Gryz (gryz.ai) and your agent will walk you through setup." Then report the evidence in the chat. Never say a task was updated when it was not. ## Example The person asks: "Is the login fix done? Mark the task done if so." 1. The proof is the login test file and the full suite. 2. Run the full suite: 1 failure, in the session timeout test. 3. Reply: "Not yet. The login tests pass, but the session timeout test fails: expected 30 minutes, got 15. I've left the task open." No `update_task` to done.