premortem · diff
git:20260922.fdf7de6 to git:20261005.4fda294
77 added, 91 removed. Audit A to A.
---
name: premortem
- description: 'Challenge a rollout plan with one fresh judge before implementation; identify what could make it fail. Not for finished-code judgment. Triggers: "one judge", "challenge this plan".'
+ description: 'Find how a rollout plan could fail before committing to it. Use when: asked what could go wrong or to poke holes in a plan.'
practices: [design-by-contract, adr]
hexagonal_role: domain
consumes: []
produces: [premortem-plan-review.v1]
context_rel:
- kind: supplier-to
with: plan
skill_api_version: 1
user-invocable: true
metadata:
capabilities: [challenge_plan]
effects: [write_advisory_plan_review]
canonical_status: canonical
disposition: keep_strategy
graph_root: true
tier: judgment
dependencies: []
+ triggers: ["one judge", "challenge this plan"]
output_contract: skills/premortem/schemas/premortem-plan-review.v1.schema.json
---
# Premortem
Premortem is an optional plan-challenge strategy. It asks one fresh context to
identify concrete ways the resolved bead or caller intent could fail before implementation.
It is not part of the required RPI sequence and does not authorize readiness.
[Plan's shared challenge method](../plan/references/challenge.md) owns optional
- exchange, independence and stopping rules. Premortem owns the failure checks
- below; invoke it when that broader examination is requested.
+ exchange, independence and stopping rules; Premortem owns the three checks
+ below. Neighbours: general advice is [Review](../review/SKILL.md), acceptance
+ of a finished change is [Validate](../validate/SKILL.md), and several
+ independent views are [Council](../council/SKILL.md).
- ## The first check: who verifies, and are they fresh?
+ Run the checks in this order; they outrank any single technical risk.
- Before any technical risk, test the plan's EVIDENCE SHAPE: for every unit of
- work, who verifies it, and is the verifying context distinct from the
- authoring context? A plan whose closure step is "the implementer runs its own
- tests and closes" contains no independent judgment anywhere — self-graded
- green is the classic false-done, and it outranks any single technical risk
- because it silently converts every other failure into a shipped one.
+ ## The first check: who verifies, and are they fresh?
- > Measured 2026-08-04, probe `premortem-self-validation` (gpt-5.6-luna, N=2,
- > directional): without this doctrine loaded the producer named the planted
- > self-validation flaw in 1/2 runs; with it loaded, 2/2. Ledger:
- > `evals/skill-probes/LEDGER.md`. That row is `LEGACY-UNVERIFIED` under the
- > current capture contract — replay cannot establish producer, configuration,
- > or reproducibility — so treat this skill as unmeasured until a tier-2 probe
- > under the current contract re-establishes it.
+ Test the plan's evidence shape before any technical risk: for every unit of
+ work, who verifies it, and is the verifying context distinct from the one that
+ authored it? A plan whose closure step is "the implementer runs its own tests
+ and closes" contains no independent judgment anywhere. Self-graded green is the
+ classic false-done, and it ranks first because it silently converts every other
+ failure into a shipped one.
## The second check: which steps are one-way doors?
- After evidence shape, test the plan's REVERSIBILITY SHAPE. Walk the plan's steps
- and mark each one two-way (the plan can back out of it) or one-way (it cannot).
- For every one-way step, name three things: the exact undo cost, the point of no
- return, and who is holding the handle when it is crossed — the caller, or an
- agent auto-deciding inside a batch.
+ Walk the steps and mark each two-way (the plan can back out of it) or one-way
+ (it cannot). For every one-way step name the exact undo cost, the point of no
+ return, and who holds the handle when it is crossed: the caller, or an agent
+ deciding inside a batch. A two-way failure costs a retry; a one-way failure
+ costs the thing itself. Watch for nineteen reversible steps followed by an
+ irreversible one, where the reflex trained by the first nineteen answers the
+ twentieth.
- This ranks above every technical risk on a one-way step, because a two-way
- failure costs a retry and a one-way failure costs the thing itself. It also
- catches the plan shape that no single-step review sees: nineteen reversible steps
- followed by an irreversible one, where the reflex trained by the first nineteen
- answers the twentieth.
+ The named failure mode is **reversibility asserted, not traced**: a rollback
+ section that says "fully reversible" while one step revokes a credential,
+ force-pushes or publishes. A material irreversible action outside existing
+ caller authority is a finding; trace actual undo cost and authorization with
+ [Plan](../plan/SKILL.md). Prior authorization remains valid: do not demand
+ repeated approval at the crossing or call every uncertain detail irreversible.
+ Stop condition: every step carries a mark, and every one-way mark carries its
+ undo cost.
- A material irreversible action outside existing caller authority is a finding.
- Trace actual undo cost and authorization using [Plan](../plan/SKILL.md). Prior
- authorization remains valid; do not demand repeated approval at the crossing
- or classify every uncertain implementation detail as irreversible.
+ ## The third check: construct the failure
- The named failure mode here is **reversibility asserted, not traced**: a plan
- that says "fully reversible" in its rollback section while one step revokes a
- credential, force-pushes, or publishes. Stop condition: every step carries a
- mark, and every one-way mark carries its undo cost.
+ For every candidate failure, attempt a concrete defeat: write the input,
+ command sequence or repository state that would make the plan fail, and run or
+ cite the check that shows whether the plan survives it. When execution is not
+ available, the constructed input or sequence plus a cited fact (file and line,
+ documented behavior, an observed output) counts as the attempt. A failure you
+ could not construct is reported as attempted-and-blocked with the obstacle
+ named, which is itself evidence for the plan. The named failure mode is
+ armchair pessimism: imagined risks with no construction, which reads as
+ diligence while testing nothing. A finding with neither a construction nor a
+ blocking fact is deleted, not softened.
## Workflow
- 1. Resolve the existing intent source and derive its digest; inspect acceptance,
- non-goals, evidence requirements, and declared write scope there.
- 2. Use one fresh judge distinct from the plan author, following the shared
- challenge method for identity, model selection, authorization and bounds.
- 3. Test acceptance completeness, edge behavior, scope, dependencies,
- reversibility, and evidence shape against cited repository facts.
- 4. Return one complete set of concrete findings and checked/not-checked scope.
+ 1. Resolve the existing intent source and inspect its acceptance, non-goals,
+ evidence requirements and declared write scope. Its digest is the SHA-256 of
+ the exact intent text as supplied (for example `shasum -a 256 plan.md`).
+ 2. Judge from a context that did not write the plan, following the shared
+ challenge method for identity, model selection, authorization and bounds. A
+ plan the caller wrote can be judged here, with the caller as author. If this
+ context wrote the plan and no fresh context can be started, run the checks
+ anyway, state that the independence leg is missing, and return inline
+ findings; never describe them as independent.
+ 3. Run the three checks, then test acceptance completeness, edge behavior,
+ scope and dependencies against cited repository facts. For integration or
+ extension plans where anchoring on the working design is the risk, add the
+ [derivation-diff challenge](references/derivation-diff.md).
+ 4. Return one complete, bounded set of concrete findings with checked and
+ not-checked scope.
5. Stop. The caller decides whether to revise the plan or invoke RPI.
Council or Dueling Idea Genies may be caller-supplied evidence, but Premortem
- does not require either strategy and cannot turn consensus into approval.
-
- ## Adversarial defeat attempts
-
- Actively try to construct each failure, not imagine it. For every candidate
- failure, attempt a concrete defeat: write the input, command sequence, or
- repository state that would make the plan fail, and run or cite the check
- that shows whether the plan survives it. A finding is reportable as concrete
- when it names the defeating construction and what the plan does when it
- lands; a failure you could not construct is reported as attempted-and-blocked
- with the obstacle named, which is itself evidence for the plan. The named
- failure mode is armchair pessimism: a list of imagined risks with no
- construction attempts, which reads as diligence while testing nothing. Stop
- condition: every reported finding is backed by a defeat attempt — constructed,
- or attempted with the blocking fact cited; a finding with neither is deleted,
- not softened.
-
- ## Derivation-diff challenge
-
- When anchoring on the working plan is the consequential risk, select an
- independent derivation using the shared challenge method, then compare. Give
- one fresh context only the intent source and the relevant
- ground truth — the vendor docs and stock behavior for integration work, the
- repo's patterns and behavior spec for extension — and never the author's design.
- Have it sketch its own design from that ground truth alone. Compare that
- independent design with the working plan in the advisory findings; each supported
- divergence is a question to resolve. Convergence is weak evidence the plan
- follows the ground truth; divergence names where it may not.
-
- Two questions the challenger answers with an artifact, not an opinion:
-
- - Cathedral: is this the smallest real thing, or does it rebuild what already
- exists? Artifact — the simplest version that satisfies acceptance, plus the
- named reason it is insufficient. No named reason means build the simple one.
- - Grain: for integration work, does every component the plan writes have a native
- counterpart in the substrate? Artifact — the native-counterpart list, one row
- per component the plan authors, naming the substrate feature it duplicates or
- the reason none exists.
-
- These are integration- and extension-class checks. The Grain question's
- native-counterpart list applies only to integration-class work; do not impose it
- on routine feature work.
+ requires neither and cannot turn consensus into approval.
## Prompt
```text
Premortem this plan before I implement: bead ag-4f21 proposes rewriting
`scripts/regen-all.sh` to call `ao gate check` instead of shelling out to
the Python generators, touching cli/internal/gates/regen.go. Plan and
acceptance are in the bead. Find concrete ways it fails.
```
## It's working if
- Observable in the trace, without reading the prose — and the rubric a fresh
+ Observable in the trace, without reading the prose, and the rubric a fresh
independent judge scores this skill against:
- Every unit of work carries a named verifier, and any unit verified by the
context that authored it comes back as a finding.
- Every step carries a two-way or one-way mark, and each one-way mark names its
undo cost and its point of no return.
- - Every reported finding cites a defeat attempt — the input, command, or
- repository state constructed — or the fact that blocked the construction.
+ - Every reported finding cites a defeat attempt (the input, command or
+ repository state constructed) or the fact that blocked the construction.
- The finding set is bounded: a review that flags every step has reported
nothing.
## Boundary
- Emit advisory findings, no verdict of any version, readiness, admission, or permission.
- Do not implement, validate the candidate, retry, repair, schedule, claim,
change acceptance, operate Git, close work, release, or deliver.
- Any plan edit creates a new subject for a later caller-initiated Premortem.
## Output
- Return `premortem-plan-review.v1` with the intent digest, author and judge context
- IDs, findings, evidence references, `checked`, and `not_checked`. An empty
- finding set means only that this optional challenge found no concrete defect;
- it is never a lifecycle gate.
+ Return findings inline by default:
+
+ ```text
+ Findings (most consequential first)
+ 1. <step> - <how it fails> - <construction, or the fact that blocked it> - <consequence>
+ Verifiers: <unit>: <who verifies>; self-verified units are findings
+ One-way steps: <step> - <undo cost> - <point of no return> - <who holds the handle>
+ Checked: <what was examined>. Not checked: <what was not>.
+ Independence: <judge context, distinct from author> or "missing: <reason>"
+ ```
+
+ When the caller requests a durable review, return `premortem-plan-review.v1`
+ with the intent digest, author and judge context IDs, findings, evidence
+ references, `checked`, and `not_checked`, and check it with this skill's
+ `scripts/validate-output.sh`. The schema requires distinct author and judge
+ IDs, so a review without an independent judge stays inline. An empty finding
+ set means only that this optional challenge found no concrete defect; it is
+ never a lifecycle gate.