grit-77/done-is-a-claim

Define executable acceptance for a bounded task before work or dispatch. Use when writing a worker brief, selecting success checks, or repairing an acceptance contract that cannot test the intended outcome.

Verify an artifact at its actual delivery destination and distinguish send attempts, acknowledgements, publication and consumer checks. Use when reporting a file, message, export or deployment as delivered; creating a local draft alone does not imply delivery.

Inspect a stopped worker's returned work and evidence before accepting it, retrying it or handing it to an integration owner. Use when a worker finishes, records disagree, or a green result has no visible change. Collection does not authorize merging.

Diagnose unexpected behavior with a reproduction, competing explanations and experiments that separate them before fixing. Use for bugs, failed checks or repeated unsuccessful fixes; attribute branch failures only with suitable comparison evidence.

Bind a check or action to the input snapshot it actually used. Use before relying on cached verification, consuming a reviewed batch, acting while inputs may change, or retrying an operation with an ambiguous result.

Carry an actionable change plan through implementation, checks, review and an evidence-backed report. Use when executing several planned steps or integrating bounded worker returns, within existing authorization.

Prepare a compact, executable plan for a substantial change with acceptance, file ownership, dependencies and expected observations. Use when several steps or collaborators need coordination; tiny clear edits can proceed directly.

Write and fact-check public copy so that every figure, credential, promise and command has a receipt - a source with a locator, a command that re-derives it, or the author's own words - and remove any claim without one instead of softening it. Use when drafting or reviewing a README, release notes, a launch post or thread, slides, or a website page; and whenever a draft states a number, a ranking, a credential, a promised result or a command.

Read a number without being fooled by it: an exit code, a passing result file, a test count, a list size, a control run, a red or a green. Use before reporting any figure, before turning a test run into a verdict, before acting on 'N items are broken', and whenever two outputs or two counts of the same thing disagree.

Resume a saved task after a session, context or machine change by checking its checkpoint, artifacts and current ownership. Use when receiving unfinished work or reconciling a stop; ordinary uninterrupted edits do not need a handoff.

Review an actual candidate against the user's acceptance and scope, then carry findings through fixes, affected checks and rereview. Use before claiming a substantive change complete or accepting a worker's implementation.

Choose an evidence-first path for a development task, from acceptance through execution, review and completion. Use when starting substantive work or deciding the next step; clear tiny edits can proceed directly.

Investigate whether a failing test run is caused by a change, was already broken on main, or is inconclusive, using matched branch and clean-main runs. Use when tests fail on a branch or PR, when an agent says 'this failure is pre-existing', or before retrying or reverting a fix.