/ship

The agent reports done, but part of the requested behaviour was never verified.

Nothing to install. Copy this into a conversation that is already underway, and see whether the idea is useful before you commit to it.

Before calling this done, check it against the evidence. List everything that was actually asked for, and for each part say whether it has been verified and by what — a test that ran, output you observed, a path you exercised. Mark anything supported only by reading the code as unverified. Then give a verdict: READY, or NOT READY with the specific missing evidence and the smallest thing that would close it.

A short, portable version. The installed skill carries the fuller behaviour — when to stay quiet, how to report, what not to flag — and neither needs your AI to be able to read this page.

/ship is allowed to find nothing.

One canonical skill, packaged for wherever you work.

A few choices that change how /ship behaves. Everything here happens in this browser — nothing is sent anywhere, and nothing is saved.

The whole skill, and the same file every download is built from. Nothing downloadable here should be less inspectable than the page explaining it.

---
name: ship
description: Decide whether the evidence actually supports calling the work complete.
license: MIT
metadata:
  version: "0.2"
  source: https://weindie.com/ship
---

# /ship

**Does the evidence support calling this done?**

"Done" is a claim about evidence, not a feeling about code. Work is most often
reported complete when the main path has been demonstrated and the rest has been
reasoned about. This skill separates what has actually been verified from what is
being assumed, and gives a verdict either way.

## Useful when

- Work is about to be reported as finished, merged or handed over.
- Several requirements were requested and only some are visibly exercised.
- The cost of being wrong is higher than the cost of one more check.
- An agent has said "done" without saying how it knows.

## Probably not needed when

- The change is trivial and its effect is directly visible.
- Verification has just happened and nothing has changed since.
- The work is explicitly exploratory and not being claimed as finished.

READY is a legitimate verdict. If the evidence is there, say so without inventing
a caveat to look thorough.

## How to run the check

1. **List what was asked for.** Every distinct requested behaviour, including the
   ones mentioned in passing.
2. **Attach evidence to each one.** What specifically demonstrates it works — a
   test that ran, output observed, a path exercised. Name it.
3. **Mark the gaps.** Anything supported only by reading the code is unverified,
   however confident the reading is.
4. **Check what else moved.** Was anything else changed or broken along the way?
5. **Give a verdict:** READY, or NOT READY with the specific missing evidence.

## Reporting

- Distinguish "verified" from "believed" in plain words.
- Do not hedge. "Should work" reads as verified without being verified.
  A reader cannot tell which a hedge means, so resolve it: verified, or believed.
- Quote real evidence — a failing test's output beats a summary of it.
- Name the smallest thing that would close each gap.
- Never report a check as passing if it was skipped, or did not run.

## Defaults you can change

These are the adjustable lines of this skill. A customised copy from
<https://weindie.com/ship> replaces them and records what changed.

- **Evidence level.** Require each requested behaviour to be demonstrated by something that actually ran; reasoning about the code is not evidence.
- **Fixing failures.** When a check fails, fix it, re-run it, and report both the failure and the fix.
- **Manual verification.** Where a behaviour cannot be checked automatically, say so and describe the manual check the human should run.
- **Unresolved issues.** A known unresolved issue does not block READY, provided it is listed explicitly and is unrelated to the requested behaviour.