executing-plans
executing-plans
Use when executing an implementation plan in the current session as the implementer yourself — your human partner chose inline execution, or no subagent tool is available
ship-or-slipTurn a release-readiness argument into one typed decision — ship, ship reduced, or slip — with a defined state, defined options, and a probability for each. Use when asked should we ship Friday, are we ready to release, do we slip the date, go/no-go for the release, or when a launch checklist is done and someone still has to call it. Produces a filled relea…
Independent GitHub snapshot · Automated classification · Original documentation governs
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.
After product-launch-checklist and launch-readiness have produced the evidence. Those skills gather; this one decides.
unknownship / ship_reduced / slip, with a probability for each option and a confidence scoreAsk for these if not provided; never invent them:
The options are fixed, so the argument is about the state, not the answer.
| Option | It applies when |
|---|---|
ship | No open severity-1 blocker, rollback tested, tests green — the date holds and the residual risk is named |
ship_reduced | The promised core is ready but a non-core item is red — ship without it and say so to whoever was promised it |
slip | A severity-1 blocker, an untested rollback, or a red core path — the date moves, because slipping is cheaper than a bad release |
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.
State
| Field | Value |
|---|---|
| open_blockers | … |
| test_status | … |
| rollback | … |
| customer_commitments | … |
| scope_cuttable | … |
Decision
| Option | Probability |
|---|---|
| ship | 0.xx |
| ship_reduced | 0.xx |
| slip | 0.xx |
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.
unknown — no invented test numbers