Premortem

Premortem

Imagine the plan already failed, then explain why. This "prospective hindsight" tense-shift (Klein, HBR 2007) generates ~30% more failure causes than asking "what could go wrong?" — and the causes are more specific. The skill turns that mechanism into a repeatable run that ends in a revised plan, not just a list of worries.

Workflow Routing

Default to `RunPremortem` for anything with real stakes. Drop to QuickPremortem only when the decision is small or the user explicitly wants speed.

The Mechanism (don't skip the framing)

The entire technique is one move: state that failure has already happened, with certainty, and ask what caused it. Everything else is delivery. If a step doesn't help the user inhabit "it already failed," cut it. Full evidence and citations: References/Methodology.md.

Quick Reference

• Frame in past tense. "It's [horizon]. [The plan] has failed. Here's why." Not "could fail."
• Generate causes independently first. In RunPremortem, parallel agents must NOT see each

other's output — this is the anti-anchoring safeguard, and it is load-bearing.

• Demand plan-specific causes. Reject generic risks ("timeline slips"). Ground every cause in

actual plan details.

• Always land on action. Each retained risk → a mitigation + an early-warning signal. End with

a revised plan and a pre-launch checklist. A premortem with no follow-through is theater.

• Markdown is canonical. The transcript (.md) is the record. HTML is an optional visual

artifact via Tools/GenerateReport.ts --html, never the primary output.

When NOT to run a premortem

• Vague concepts with no concrete plan — gather the plan first, or you'll generate generic risk.
• Decisions already irreversibly made — nothing to revise; value is low.
• Factual questions or creative feedback — wrong tool.
• Attacking an idea/argument in the abstract → RedTeam. Current multi-view debate → Council.

Tools

• Tools/GenerateReport.ts — turns a findings JSON (schema in References/Templates.md) into a

markdown report (default) or a self-contained HTML report (--html). Run with bun. See Tools/GenerateReport.help.md.

Gotchas

The highest-density part of this skill. Add to it after every run that surprises you.

• The "30%" stat is about quantity, not correctness. The 1989 Mitchell/Russo/Pennington study

found prospective hindsight produces ~30% more reasons generated — NOT 30% better at identifying the _correct_ reasons. Klein's HBR paraphrase ("correctly identify") overstates it. Never tell a user the premortem makes them "30% more accurate." It makes them more _prolific_ and _specific_. Citing it wrong makes the whole analysis look sloppy.

• Anchoring kills the run. If you generate causes sequentially (or let one agent see another's

output), the first failure named frames everything after it. Generate independently, then merge. This is why RunPremortem fans out parallel agents and explicitly forbids cross-talk.

• Generic risks are the #1 quality failure. "Budget overruns," "team gets distracted,"

"market shifts" apply to every plan and help no one. If a cause would survive find-and-replace of the subject, it's too generic — force it to cite a real plan detail.

• Run it BEFORE commitment. A premortem after the money is spent and the team is emotionally

bought in becomes a ritual. Its value is in _changing_ the plan, so it needs a changeable plan.

• Don't confuse it with RedTeam or Council. Premortem = imagined _future failure_ of a

_concrete plan_, ending in a revised plan. RedTeam = adversarial attack on an arbitrary idea. Council = multiple _current_ perspectives debating. Overlapping vocabulary, different mechanisms.

• Thin context → generic output. If you can't state (1) what's being premortemed in one

sentence, (2) who's affected, (3) what success means, STOP and ask one question at a time. Don't generate failures from nothing — that produces exactly the generic risk this technique exists to avoid.

• Failure ≠ pessimism. The output is specific causal stories with mitigations, not a doom mood.

If the run reads as "everything is risky," it failed.

• Likelihood and severity are different axes. The _most likely_ failure and the _most dangerous_

failure are usually not the same one. Surface both — that distinction is often the insight.

Customization

Before executing, check for user customizations at ~/.claude/PAI/USER/SKILLCUSTOMIZATIONS/Premortem/. If PREFERENCES.md exists, load and apply it (e.g. preferred default horizon, report theme, number of failure agents). These override defaults. If the directory does not exist, proceed with skill defaults. Do not put private/identity content in this skill body — it belongs in SKILLCUSTOMIZATIONS.

🚨 Voice Notification (run on invocation)

curl -s -X POST http://localhost:31337/notify \
  -H "Content-Type: application/json" \
  -d '{"message": "Running the WORKFLOWNAME workflow in the Premortem skill to ACTION"}' \
  > /dev/null 2>&1 &

Then output: Running the **WorkflowName** workflow in the **Premortem** skill to ACTION...

Examples

Example 1: Full premortem on a launch

User: "Premortem our paid-newsletter launch next month"
→ RunPremortem: gather context (what/who/success) → frame "it's 6 months out, the launch failed"
→ generate plan-specific causes → fan out 1 agent per cause (independent) → synthesize
   most-likely + most-dangerous + hidden assumption + revised plan + checklist
→ write transcript .md, optionally GenerateReport.ts --html → 3-sentence chat summary

Example 2: Quick solo gut-check

User: "quick premortem on accepting this contractor role"
→ QuickPremortem: single-pass, no agents → past-tense framing → 5-8 specific causes with
   likelihood/severity, hidden assumption, top mitigations → short markdown, no HTML

Example 3: Disambiguation from RedTeam

User: "poke holes in my argument that we should go remote-first"
→ This is attacking an ARGUMENT, not a plan-with-stakes → suggest RedTeam instead, or
   reframe: "if you want to premortem the remote-first *rollout plan*, I can do that."

Execution Log

After completing any workflow, append a single JSONL entry:

echo '{"ts":"'$(date -u +%Y-%m-%dT%H:%M:%SZ)'","skill":"Premortem","workflow":"WORKFLOW_USED","input":"8_WORD_SUMMARY","status":"ok|error","duration_s":SECONDS}' >> ~/.claude/PAI/MEMORY/SKILLS/execution.jsonl

Premortem — Methodology & Evidence

Reference material for the Premortem skill. Loaded on demand by the workflows. This file is the why behind the protocol; the workflows are the how.

---

1. Origins & Evidence

The premortem was named and popularized by cognitive psychologist Gary Klein in his September 2007 Harvard Business Review article "Performing a Project Premortem" (reprint F0709A). It rests on a single empirical foundation Klein cites:

"Research conducted in 1989 by Deborah J. Mitchell, of the Wharton School; Jay Russo,

of Cornell; and Nancy Pennington, of the University of Colorado, found that prospective

hindsight — imagining that an event has already occurred — increases the ability to

correctly identify reasons for future outcomes by 30%."

The underlying study: *Mitchell, D. J., Russo, J. E., & Pennington, N. (1989). "Back to the Future: Temporal Perspective in the Explanation of Events." Journal of Behavioral Decision Making, 2(1), 25–38* (doi:10.1002/bdm.3960020103).

⚠️ Citation-accuracy correction (important). The 1989 study measured that framing an

event in the past tense ("the event happened") rather than future/conditional

increased the number of reasons generated by roughly 30%. It did not measure that

the reasons were correctly identified. Klein's gloss ("correctly identify") subtly

overstates the finding. Use the defensible claim: "~30% more reasons generated." Never

tell a user the premortem makes them "30% better at finding the right reasons" — that is

not what the data shows, and stating it makes the whole analysis look sloppy.

Daniel Kahneman endorsed the premortem in Thinking, Fast and Slow (2011) as a partial remedy for overconfidence and the illusion of validity — which is largely why it entered mainstream business vocabulary.

Later support: Veinott, Klein & Wiggins (2010) found a premortem condition reduced overconfidence more reliably than plain critique, pros/cons, or cons-only conditions. The evidence base is still thin — be honest about that rather than overselling.

Organizations including Google, Goldman Sachs, and Procter & Gamble use premortems for major decisions.

---

2. The Mechanism — why it works

The premortem inverts the usual question. Instead of prospective foresight ("what could go wrong?"), it uses prospective hindsight: you stand at a fixed future point where failure has already happened with certainty and explain why.

Klein: "the premortem operates on the assumption that the 'patient' has died, and so asks what did go wrong."

Three cognitive effects:

• Overconfidence / planning fallacy — certainty of the outcome forces concrete causal

storytelling rather than vague hedging. Past-tense narrative is more specific than an abstract risk list.

• Groupthink & social pressure — there is "silent pressure not to surface doubts." The

premortem makes dissent the assigned task, so people compete on the quality of the problems they raise.

• Legitimizing the doubter — it gives knowledgeable skeptics permission to speak without

seeming disloyal.

This tense-shift is the entire mechanism. Every design choice in this skill serves it. If a step does not help the user inhabit "it already failed," it is decoration.

---

3. Canonical Process (Klein's facilitation)

The original group protocol, adapted in this skill for AI-assisted runs:

1. Set the scene. State explicitly: assume the project has failed — spectacularly. 2. Write independently first. Everyone lists every reason for the failure before anyone shares. This independent-then-share step is the anti-anchoring safeguard — it is load-bearing, not optional. (In the AI version, parallel agents must not see each other's output.) 3. Share round-robin. Each person reads one distinct reason until all are recorded; starting with the leader models candor. 4. Review & strengthen. Afterward, review the list for ways to strengthen the plan. 5. Revisit periodically — the list becomes an early-warning radar during execution.

Klein notes it can take as little as 20–30 minutes. Practitioner guidance: small cross-functional groups (~4–8) so every voice is heard; run it during planning, before commitment.

---

4. Variations & Adjacent Techniques

---

5. Failure Modes & Gotchas (when running a premortem)

• Anchoring on the first failure named — skipping independent generation lets the

loudest voice (or the first agent) set the frame. Generate independently, then merge.

• Sandbagging / theater — going through the motions, or producing findings nobody owns.

A premortem with no mitigation follow-through is worthless.

• Running it too late — after psychological/financial commitment it becomes ritual, not

redirection. Run it while the plan is still changeable.

• Generic risks — "the timeline slips," "budget overruns." Plan-agnostic risks signal

weak engagement. Demand plan-specific, concrete causal chains.

• Irreversible decisions — value is low when nothing can change. Best applied where the

plan can still be revised.

• Confusing it with general pessimism — the goal is specific, actionable causal stories,

not a bad mood.

---

6. Practitioner Best Practices

• Make each failure specific and grounded — a concrete causal chain, not a category.
• Score it — assign likelihood × severity to prioritize.
• Derive early-warning indicators — for each top risk, define the observable signal that

it is materializing.

• Convert to mitigations + a pre-launch checklist — every retained risk gets an owner

and a preventive/contingent action.

• Facilitation — ideally a neutral facilitator; the leader speaks first to model candor

but should not dominate.

• Document and revisit — keep the risk list live; check it at milestones.

---

Sources

• Klein, G. (2007). "Performing a Project Premortem." Harvard Business Review, Sept 2007. <https://hbr.org/2007/09/performing-a-project-premortem>
• Mitchell, D. J., Russo, J. E., & Pennington, N. (1989). "Back to the Future: Temporal Perspective in the Explanation of Events." Journal of Behavioral Decision Making, 2(1), 25–38. <https://onlinelibrary.wiley.com/doi/10.1002/bdm.3960020103>
• Klein, G. (2021). "The Pre-Mortem Method." Psychology Today. <https://www.psychologytoday.com/us/blog/seeing-what-others-dont/202101/the-pre-mortem-method>
• Veinott, Klein & Wiggins (2010). "Evaluating the Effectiveness of the PreMortem Technique on Plan Confidence."
• Kahneman, D. (2011). Thinking, Fast and Slow.
• Jason Collins — evidence critique of the "30%" claim. <https://corporate.jasoncollins.blog/premortem>

Premortem — Templates

Copy-paste scaffolds for a premortem run: the findings JSON (consumed by Tools/GenerateReport.ts), the markdown transcript, and the per-agent prompt.

---

1. Findings JSON schema (contract with GenerateReport.ts)

This is the exact shape Tools/GenerateReport.ts consumes. Field names must match.

{
  "subject": "One-line description of what was premortemed",
  "successDefinition": "What winning looks like (optional)",
  "stakeholders": "Who is affected (optional)",
  "horizon": "6 months from now",
  "timestamp": "2026-05-29T15:00:00Z",
  "failures": [
    {
      "id": "F1",
      "title": "Short failure name",
      "likelihood": "low | medium | high",
      "severity": "low | medium | high",
      "story": "2-3 paragraph past-tense narrative of how this specific failure played out, grounded in plan details.",
      "assumption": "One sentence naming the unquestioned premise that enabled this failure.",
      "warningSigns": [
        "Observable, measurable early signal #1",
        "Observable, measurable early signal #2"
      ],
      "mitigation": "Concrete, specific action that prevents or detects this failure mode.",
      "owner": "Who is accountable for the mitigation (optional but strongly recommended)."
    }
  ],
  "synthesis": {
    "mostLikely": "The probable failure scenario given the plan details.",
    "mostDangerous": "The scenario causing maximum damage, even if less probable.",
    "hiddenAssumption": "The single biggest unexamined assumption underlying the whole plan.",
    "revisedPlan": [
      "Specific, actionable modification #1",
      "Specific, actionable modification #2"
    ],
    "preLaunchChecklist": [
      "Concrete verification step #1",
      "Concrete verification step #2"
    ]
  }
}

Field notes

• subject, failures, synthesis are required. successDefinition, stakeholders,

horizon, timestamp are optional (timestamp auto-fills to generation time if absent; the others render only if present).

• likelihood / severity ∈ low | medium | high — drives the report's badges and the

most-likely / most-dangerous synthesis.

• owner is optional but strongly recommended — an un-owned mitigation rarely happens. A

premortem that ends in a prioritized, owned action list produces decisions; one that ends in a list of fears produces anxiety. Prioritize failures by likelihood × severity.

• warningSigns, revisedPlan, preLaunchChecklist are arrays of strings.

Render: bun ~/.claude/skills/Premortem/Tools/GenerateReport.ts findings.json --out report.md HTML: bun ~/.claude/skills/Premortem/Tools/GenerateReport.ts findings.json --html --out report.html

---

2. Markdown transcript template

premortem-transcript-<timestamp>.md — the canonical, human-readable record.

# Premortem Transcript — <subject>

> Horizon: <e.g. 6 months from now> · Generated: <ISO-8601>

## Context
- **What was premortemed:** <one sentence>
- **Stakeholders:** <who is affected>
- **Success definition:** <what winning looks like — failure is its inversion>

## Frame
It is <horizon>. <The plan> has failed. The following explains what went wrong.

## Raw Failure Causes (independent generation)
1. <plan-specific cause>
2. <plan-specific cause>
...

## Deep Dives
### F1 — <title>  (likelihood: <l> · severity: <s>)
**Failure story.** <2-3 paragraphs>
**Hidden assumption.** <one sentence>
**Early-warning signs.** <1-2 observable signals>
**Mitigation.** <concrete action>  ·  **Owner.** <who is accountable>

### F2 — <title> ...

## Synthesis
- **Most likely failure:** <...>
- **Most dangerous failure:** <...>
- **Biggest hidden assumption:** <...>
- **Revised plan:**
  1. <change>
- **Pre-launch checklist:**
  - [ ] <verification step>

---

3. Per-agent deep-dive prompt (for the parallel fan-out in RunPremortem)

Give each agent exactly one failure cause. Agents run independently (anti-anchoring) — never let them see each other's output.

You are analyzing ONE failure mode of this plan. The plan has ALREADY FAILED — write in
past tense, with certainty, not "could."

PLAN CONTEXT:
<subject, success definition, stakeholders, key plan details>

YOUR ASSIGNED FAILURE CAUSE:
<the single cause>

Produce, in under 300 words, no hedging:
1. FAILURE STORY — 2-3 short paragraphs showing how this specific failure played out, using
   real plan details.
2. HIDDEN ASSUMPTION — one sentence naming the unquestioned premise that enabled it.
3. EARLY-WARNING SIGNS — 1-2 observable, measurable signals that this mode is emerging.
4. LIKELIHOOD and SEVERITY — each one of: low | medium | high.
5. MITIGATION — one concrete, specific action (not "monitor closely").
6. OWNER — who should be accountable for the mitigation (role is fine if no name).

Return JSON matching the failure object schema: {id,title,likelihood,severity,story,
assumption,warningSigns[],mitigation,owner}.

GenerateReport.ts — Help

Turns a premortem findings JSON file into a report. Markdown by default; self-contained HTML with --html. Runs on the Bun runtime, no external dependencies.

Usage

bun ~/.claude/skills/Premortem/Tools/GenerateReport.ts <findings.json> [--html] [--out <path>]

Examples

# Markdown to stdout
bun ~/.claude/skills/Premortem/Tools/GenerateReport.ts findings.json

# Markdown to a file
bun ~/.claude/skills/Premortem/Tools/GenerateReport.ts findings.json --out report.md

# Visual HTML report
bun ~/.claude/skills/Premortem/Tools/GenerateReport.ts findings.json --html --out report.html

Input

A findings JSON file matching the schema in References/Templates.md §1. Required keys: subject, failures[], synthesis. Optional: successDefinition, stakeholders, horizon, timestamp. Each failure: {id, title, likelihood, severity, story, assumption, warningSigns[], mitigation, owner?}.

Behavior

• Validates the input shape; on a missing file or malformed JSON it prints a helpful error to

stderr and exits 1. Success exits 0.

• The synthesis (most-likely, most-dangerous, hidden assumption, revised plan, pre-launch

checklist) is pinned at the top; one card/section per failure with likelihood + severity badges.

• HTML output escapes all user-supplied strings.

Note

Markdown is the canonical premortem record (PAI convention). Use --html only when a user wants a visual or shareable artifact.

Workflow: QuickPremortem

The lightweight premortem — a single-pass, solo analysis with no parallel agents. Use for small or personal decisions, fast gut-checks, or when context is thin and a full fan-out would be overkill. Same mechanism (prospective hindsight), a fraction of the cost.

Voice on entry:

curl -s -X POST http://localhost:31337/notify -H "Content-Type: application/json" \
  -d '{"message": "Running the QuickPremortem workflow in the Premortem skill for a fast failure check"}' > /dev/null 2>&1 &

Then: Running the **QuickPremortem** workflow in the **Premortem** skill for a fast failure check...

---

How it differs from RunPremortem

Steps

1. Confirm the basics (fast). One sentence: what is being decided, and what does success look like? If you can't state both, ask one question — don't generate from nothing.

2. Frame in past tense. "It's [horizon, default ~6 months out]. [The decision] turned out badly. Here's why." Inhabit the certainty.

3. List every cause first, then analyze. Write 5–8 plan-specific failure causes before elaborating on any of them — this is the solo substitute for the parallel anti-anchoring step. Reject generic risks; each must cite a real detail of the decision.

4. Score and deepen. For each cause give: likelihood (low/med/high), severity (low/med/high), the one hidden assumption behind it, and one concrete mitigation. Keep each tight.

5. Synthesize in three lines. Most-likely failure, most-dangerous failure, and the single biggest hidden assumption — then the top 1–3 changes worth making now.

6. Deliver as short markdown. No HTML, no saved report unless asked. Offer to escalate to RunPremortem if the stakes turn out higher than they looked.

7. Log. Append the execution-log JSONL entry (see SKILL.md → Execution Log).

Gotcha

• If the decision is genuinely high-stakes (irreversible, expensive, reputational), don't shortcut

it — switch to RunPremortem. Quick mode trades depth for speed; spend the depth where the cost of being wrong is high.

Workflow: RunPremortem

The full premortem — parallel deep-dive agents, synthesis, and a written record. Use for any plan, launch, hire, pricing change, partnership, or strategic decision where the cost of being wrong is high and the plan is still changeable.

Voice on entry:

curl -s -X POST http://localhost:31337/notify -H "Content-Type: application/json" \
  -d '{"message": "Running the RunPremortem workflow in the Premortem skill to stress-test the plan"}' > /dev/null 2>&1 &

Then: Running the **RunPremortem** workflow in the **Premortem** skill to stress-test the plan...

---

Step 0 — Context gathering & sufficiency gate (BLOCKING)

A premortem on thin context produces generic risk — exactly what the technique exists to avoid. First, scan existing context (~30s): the conversation, attached materials, and workspace planning files (CLAUDE.md, briefs, docs). Then confirm three things:

1. Clarity — what is being premortemed? State it in one sentence. 2. Stakeholders — who is affected? (audience, customers, team) 3. Success definition — what does winning look like? (failure is its inversion)

If any is missing and you cannot infer it, ask for the single most critical gap, one question at a time. Do not make the user fill a form. Do not proceed to Step 1 until all three are known.

Step 1 — Frame the failure (the mechanism)

State the premise explicitly and in past tense:

"It's [horizon — default 6 months from now]. [The plan] has failed. We're examining what went

wrong."

This is not optional flavor — the tense-shift is the entire technique. Carry this framing into every subsequent prompt: failure is certain; we explain it, we don't predict it.

Step 2 — Generate raw failure causes (independently)

Generate every genuine, plan-specific reason the plan failed. Each cause must be:

• Specific to this plan — would not survive find-and-replace of the subject.
• Grounded in the actual plan details from Step 0.
• A real threat — not trivial, not absurdly unlikely.

Aim for comprehensive coverage (typically 5–12), not padding. Do not yet analyze them.

Step 3 — Deep-dive fan-out (PARALLEL, INDEPENDENT)

Spawn one agent per failure cause, all at once, in a single message (Agent tool, or parallel() in a Workflow). Agents must run independently — never let one see another's output. This is the anti-anchoring safeguard from Klein's protocol; sequential analysis lets the first cause frame the rest.

Give each agent exactly one cause and the per-agent prompt from References/Templates.md §3. Each returns JSON: {id, title, likelihood, severity, story, assumption, warningSigns[], mitigation, owner?} — under 300 words, past tense, no hedging.

Degrees of freedom: for very large premortems, cap the fan-out (e.g. top 10 causes by stakes)

and say so in the transcript. Never silently drop causes.

Step 4 — Synthesis

Collect all agent results. First prioritize: rank failures by likelihood × severity so the synthesis spends attention where the expected cost is highest. Then produce:

1. Most likely failure — the probable scenario given the plan. 2. Most dangerous failure — maximum damage, even if less probable. (Usually not the same as most-likely — that gap is often the key insight.) 3. Biggest hidden assumption — the single unexamined premise underlying the whole plan. 4. Revised plan — specific, actionable modifications addressing the top failure modes, each with an owner. State "test a $X pilot with N people before committing," not "be careful." An un-owned mitigation rarely happens — assign accountability or the premortem becomes theater. 5. Pre-launch checklist — 3–5 concrete verification steps, each preventing or detecting a failure mode.

Step 5 — Write the record (markdown canonical)

Assemble a findings JSON (schema: References/Templates.md §1) and the markdown transcript (References/Templates.md §2). Save:

• premortem-transcript-<timestamp>.md — canonical record (always).

Then, optionally, generate the report artifact:

bun ~/.claude/skills/Premortem/Tools/GenerateReport.ts findings.json --out premortem-report-<timestamp>.md
# visual HTML (opt-in, not canonical):
bun ~/.claude/skills/Premortem/Tools/GenerateReport.ts findings.json --html --out premortem-report-<timestamp>.html

Only produce HTML if the user wants a visual/shareable artifact — markdown is the default per PAI.

Step 6 — Chat summary

Give a three-sentence summary in chat: the most-likely failure, the biggest hidden assumption, and the single most important plan revision. Point to the saved transcript.

Step 7 — Log

Append the execution-log JSONL entry (see SKILL.md → Execution Log).

---

Gotchas (workflow-specific)

• If Step 3 agents come back with generic causes, the input plan was too thin — return to Step 0.
• Likelihood and severity are independent; sort by severity for "most dangerous," by

likelihood for "most likely."

• Don't let the fan-out balloon cost on a small decision — that's what QuickPremortem is for.

Workflow: Update

Maintain and extend the Premortem skill itself — add a workflow, fix the tool, refine triggers, or record a new gotcha learned from a real run.

Voice on entry:

curl -s -X POST http://localhost:31337/notify -H "Content-Type: application/json" \
  -d '{"message": "Running the Update workflow in the Premortem skill to maintain it"}' > /dev/null 2>&1 &

Then: Running the **Update** workflow in the **Premortem** skill to maintain it...

---

When to use

• A real premortem run surfaced a recurring mistake → add it to ## Gotchas in SKILL.md.
• A new use-case needs a dedicated workflow → add Workflows/<Name>.md and a routing-table row.
• The report tool needs a new field or format → edit Tools/GenerateReport.ts + its help + the

schema in References/Templates.md (keep all three in sync).

• Triggers over/under-fire → refine the description (see CreateSkill → OptimizeDescription).

Rules (do not break these)

1. Stay public-safe. This is a TitleCase public skill. No personal names, paths, domains, customers, or credentials in any file. User-specific tweaks go in ~/.claude/PAI/USER/SKILLCUSTOMIZATIONS/Premortem/, never the skill body. 2. Keep structure flat. Only Workflows/, Tools/, References/. Max 2 levels deep. 3. Keep SKILL.md < 500 lines. Push detail into References/; SKILL.md is a routing guide. 4. Schema is a contract. If you change the findings JSON shape, update GenerateReport.ts, GenerateReport.help.md, AND References/Templates.md together, then re-run the dry-run. 5. Citation honesty stays. Never "upgrade" the 30%-reasons-generated gotcha into a stronger claim than the 1989 study supports.

Steps

1. Make the change (workflow / tool / docs). 2. If the tool changed: bun ~/.claude/skills/Premortem/Tools/GenerateReport.ts <sample>.json in both markdown and --html modes — confirm exit 0. 3. Run the public pre-flight grep: rg -i "/Users/[a-z]+/|[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}" ~/.claude/skills/Premortem/ — expect zero personal-data matches. 4. Optionally validate with Skill("CreateSkill", "validate skill Premortem"). 5. Append the execution-log JSONL entry.