deliver

Carry out the named charter. Its ## Success checks are the definition of done; nothing else is. Read the whole charter and the existing work first. The owner (whoever owns the work, often the user) can override this skill and any plan an agent wrote. Any kind of project uses it: for code and tests also read references/proof.md.

Prerequisites: sno deliver-proof needs bash 4+ and GNU coreutils (Linux) and prints one message and stops when they are missing; its selftest also needs python3. On macOS, install bash 4+ and GNU coreutils (for example with Homebrew) and put them first on PATH. If sno deliver-proof is not available, run scripts/deliver-proof from this skill's folder instead.

Keep the work useful

• Before adding a prerequisite, test, record or approval step, name the requested result it proves and what changes if it fails. If nothing changes, leave it out.
• Check an uncertain fact by reading or calling what exists. If checking needs something built first, building it is the first task, not a permission gate.
• Records, telemetry, formatting, identifiers, checksums and review sign-offs never block the work. Log the failed action, its place and the actual error, and continue. Do not turn such a failure into an assertion, a silent return or a swallowed error. If the main operation fails, say so with its cause; never report success. Stop only what cannot proceed and keep independent work moving.
• Time is finite and proof shares it: estimate a run from existing timings before starting, test only what changed and what directly depends on it, and by default run a full suite only when the owner explicitly asks. Do not stop a useful run just because an estimate has passed.
• By default add no security check or new gate the owner did not ask for; propose it as a question that says what it would check and what it would block.

Steps