| name | premortem |
| description | Imagine the change has shipped exactly as planned and broken production; write concrete failure stories, then sweep SolTechnology.Core module checklists for what the stories missed. Produces a Go / Go-with-mitigations / No-Go verdict. Runs as the 00 gate of a plan, always in a session that did not author the plan. |
Premortem
Pre-mortem methodology (Gary Klein) adapted for SolTechnology.Core — a collection of NuGet
packages consumed by external apps (e.g. DreamTravel,
plus public consumers of SolTechnology.Core.* from NuGet.org).
Instead of asking "what could go wrong?", assume the change already shipped and failed, then
work backwards to explain why. Prospective hindsight produces concrete failure stories where a
forward-looking review produces vague worries.
When to use
Mandatory before merging exactly for the trigger list in CLAUDE.md §4. Apply forbidden-action
confirmation gates from CLAUDE.md §2 separately; they do not imply a premortem requirement.
Recommended for other high-risk changes, including public API changes and changes crossing
module boundaries (e.g. CQRS ↔ Story ↔ Logging).
Within a plan, this skill executes the 00-run-premortem.md gate
(delivery workflow), invoked by
implement-plan.
Critical rules
- Never in the authoring session. A premortem run by the session that wrote the plan is
anchored by it and rubber-stamps it. It must run in a fresh session (the
implement-plan
session satisfies this) or a spawned subagent.
- Assume the change shipped exactly as planned. A failure is not "we forgot to implement X"
— plan defects belong to the plan-reviewer, which runs
before this gate. Here: "we shipped X exactly as designed and it still broke something".
- Stories first, checklists second. Generate failure narratives before opening any checklist.
Checklist-seeded scenarios come out shallow and generic; the checklists exist to catch what
the narratives missed, not to replace them.
- No probability percentages. Plausibility + impact, not maths.
- Cite evidence. Every scenario references a file path (and line where useful) — no
speculation without code to back it. Read the real code the plan touches; a premortem against
the plan text alone produces phantom risks.
- Think second-order. Consumers of the NuGet packages (sample apps + invisible public users)
are part of the blast radius; the bug does not stop at the repo boundary.
- No user questions. Your output channels are the verdict, the mitigations, and the record —
not a question round. A decision only the user can make = a No-Go (or Go with mitigations)
stating exactly what must be decided; the planner owns the follow-up conversation.
- Pair with blue-red-team when the change is a design decision,
not just a code edit.
- Cite canonical guides directly (
ClaudeCodingGuide §3/§11,
PublicDocumentationGuide.md) — if a reference looks wrong, the reference is stale, not the
rule.
- English record; conversation mirrors the user.
Process
1. Frame the change
Record:
- Modules touched (e.g.
SolTechnology.Core.CQRS, SolTechnology.Core.Story)
- API delta — added / removed / changed public types, members, signatures, attributes
- Semver impact —
MAJOR / MINOR / PATCH, tied to concrete diff evidence
- Consumers in the workspace — search
sample-tale-code-apps/** for
using SolTechnology.Core.<Module>
- External consumers — assume public NuGet downloaders exist; their code is invisible
Read the actual source the plan touches. Delegate bulk reading to Explore subagents; end every
task prompt with:
Return ONLY: (1) file paths, (2) relevant type/member names with signatures, (3) a one-line
role for each. No file contents, no code blocks longer than a signature, max ~40 lines.
2. Imagine the failure
Pick a moment in the future (next release, next quarter). The change has failed
spectacularly. Describe the worst-credible end state in one paragraph. Examples:
- "DreamTravel API returns 500 on every request after upgrading
SolTechnology.Core.Logging."
- "A community consumer files an issue: their
dotnet build fails with NU1605 after we bumped a
transitive Microsoft.Extensions.* reference."
- "Story workflows resumed after deploy crash on deserialization."
3. Write the failure stories (narrative first — before any checklist)
Generate 5–10 concrete stories from the end state, working backward. Each story answers:
- What went wrong — one sentence.
- Trigger — the specific input, upgrade path, config, or race, anchored to file:line in the
diff/plan.
- Mechanism — the causal chain through named symbols (
Type.Member, package, config key).
- What warning signs were missed / which assumption proved incorrect.
Cover the steps individually and the plan as a whole: integration seams between steps,
ordering across PRs, partial-upgrade states at consumers.
4. Sweep the module checklists (supplementary — catches what stories missed)
Lazy-loaded — read only the references matching the modules in the diff. Every bullet is
worth one sentence of evidence before dismissing it. Add any newly surfaced scenario to the list
from §3.
If the diff touches a module without a reference file, write one (same shape as the existing
files) in the same PR so the next contributor inherits the checklist.
5. Score blast radius, severity, likelihood
For each scenario:
- Blast radius — internal-only / sample apps / public NuGet consumers / all.
- Severity —
L (cosmetic) / M (functional regression, recoverable) / H (data loss,
breaking API, broken build for consumers).
- Likelihood —
L / M / H by how easy the trigger is to hit in normal use.
Drop scenarios with no realistic trigger — the record must not be a laundry list; every entry
earns its place. Confirming an already-defended scenario is valuable output: mark it against its
existing control.
6. Map to existing controls and propose mitigations
For each surviving scenario:
- Existing control — test in
tests/SolTechnology.Core.<Module>.Tests/, guard, architecture
rule, module doc,
lint, build setting. If none: none — gap.
- Mitigation — one of: add/extend a test (link the test class); add a
Guards.*
precondition; document a breaking change in the dated feature record and current architecture
plus bump major; add a runtime check
(ModuleInstaller validation); update docs/ClaudeCodingGuide.md so the failure mode is
prevented for future contributors; defer with explicit rationale ("accepted risk").
- Every mitigation names the step file that must carry it.
- Where the failure is runtime-observable at a consumer (a log line, exception type, health
check), name that early-warning signal alongside the mitigation. For build-time failures the
existing control (test, guard, analyzer) plays this role — do not invent runtime telemetry a
library cannot own.
7. Decide
- Go — no
H severity, all M covered by existing controls, semver classification matches
the diff.
- Go with mitigations — required mitigations listed; the executing session
(
implement-plan) folds each into the named step file before
the gate flips to done.
- No-Go — at least one
H scenario with no plausible mitigation, or a decision only the
user can make. State exactly what blocks and what would unblock; the plan returns to the
planner.
Record the full output (format below) in 00-run-premortem.md under the gate's heading; the
invoking session mirrors the verdict into the summary's premortem: field.
Output format
Premortem — <change title>
Frame
- Modules touched: list
- API delta: added/removed/changed
- Semver impact: MAJOR / MINOR / PATCH
- Consumers in workspace: list
Imagined Failure
One-paragraph worst-credible end state.
Scenarios
| # | Story (what + mechanism) | Trigger (file:line) | Blast radius | Sev | Lik | Existing control | Mitigation → step |
|---|
| 1 | | | | L/M/H | L/M/H | | |
Top 3 Risks
- scenario # + one-line why
Required Mitigations Before Merge
- concrete action + file path / test name + owning step file
Accepted Risks
Decision
Go / Go with mitigations / No-Go — one-line reason
