Ship or Slip
A go/no-go meeting is a decision pretending to be a discussion. This skill makes the decision typed: the release state is written down in a fixed schema, the three possible answers are defined before anyone argues, and the output is a probability for each option, not a paragraph. A program can act on the result; a person can overrule it, on the record.
Where this sits
After product-launch-checklist and launch-readiness have produced the evidence. Those skills gather; this one decides.
What This Skill Produces
- The release state — the six fields below, filled from evidence, gaps marked
unknown
- The decision —
ship / ship_reduced / slip, with a probability for each option and a confidence score
- Act or hold — whether the decision clears the thresholds (act) or goes back to the release owner (hold), and why
- The flip fact — the single unknown that, if resolved, would change the answer
- The record line — one line for the release log: decision, probabilities, who overruled (if anyone)
Required Inputs
Ask for these if not provided; never invent them:
- release — name and target date
- open_blockers — count and one line each: severity, owner, ETA
- test_status — pass rate, flaky count, when the last green build was
- rollback — tested or not, and time to roll back
- customer_commitments — who was promised what, by when
- scope_cuttable — what could be dropped without breaking the promise
Framework: A Typed Decision
The options are fixed, so the argument is about the state, not the answer.
Thresholds. Act automatically only when confidence ≥ 0.6 and the winning option's probability ≥ 0.7. Otherwise hold: present the distribution to the release owner with the two closest options and the fact that separates them.
How to get probabilities. Any calibrated decision model that answers a defined multiple-choice question with a probability per option works — the contract is the state schema and the options above. The repo ships a ready adapter: node integrations/jev/decide.mjs ship-or-slip --state state.json (contract in integrations/jev/decisions/ship-or-slip.json). Without a model, the assistant estimates the distribution itself and labels it as an estimate.
Reading the distribution. 0.55 ship / 0.40 slip is not "ship". It is a hold with one question: what makes the 0.40? A distribution that moves when one field changes tells you which field to go verify.
Output Format
Ship or slip: [release] · target [date]
State
Decision
Confidence: 0.xx · Source: [model name / assistant estimate]
Verdict: [act: option] or [hold — closest: a vs b]
Flip fact: [the one unknown; who can answer it by when]
Record line: [date] [release] → [option] (p=0.xx, conf=0.xx) · overruled by: [none / name, reason]
End every output with a short Assumptions and gaps block: two to four bullets naming what was assumed because the input did not say, and what missing information would most change this output. If nothing was assumed and nothing was missing, say so in one line instead.
Quality Checks
Anti-Patterns
- Deciding in prose — "we feel good about it" is not a decision anyone can audit
- Moving the options — adding "ship dark" at the last minute to avoid a slip
- Treating 0.55 as a yes — a close call is a hold, by definition
- Hiding the overrule — a human may overrule; the record must say so
- Letting the model own it — the release owner owns the decision; the distribution is evidence
Example Trigger Phrases
- "Should we ship on Friday or slip a week?"
- "Go/no-go for the 3.2 release — here's the state."
- "Two blockers open, rollback untested — call it."