Stress-test one-way-door plans by surfacing risky assumptions, irreversible bets, and unvalidated dependencies.
Collected from public GitHub. Every version is saved exactly as it was and never changes. Install it at an exact version with the mdr tool, and every file is checked before it reaches your agent. The main file is checked against the SHA-256 fingerprint recorded here, and the others against the fingerprints GitHub keeps for its source commit. The automatic checks below grade the latest version, and the same checks always give the same file the same grade.
What the file says
Stress-test this plan before reality does. Not to kill it, but to make it survive contact with reality.
When you surface this proactively (rather than because the user asked): only do so when a decision is genuinely hard to reverse (a public API, schema migration, framework or architecture choice, a hire) or a plan is drawing only positive feedback, and raise it after you finish the user's current request, as a one-line offer. Produce the full Challenge Report only once they confirm. When the user invokes it directly, skip the offer and run it.
The technique: imagine it is 12 months from now and this plan failed. Work backwards, find why, then harden the plan against it.
Run the five-step framework and produce the Challenge Report described in [references/pre-mortem-framework.md](references/pre-mortem-framework.md): extract the assumptions the plan needs to be true, rate each on confidence and impact-if-wrong, map the vulnerabilities (low confidence + high impact), trace the dependency chain, and test reversibility. Close with kill switches and hardening actions.
…
The line at the top of this page pins the label git:20260803.4037041, which is what most people want. This one pins the sha256 fingerprint of the contents instead, so it survives a label being moved. Either way the exact version is written to mdr.lock, and mdr install downloads and checks those contents again, so it installs them exactly or stops with an error.
GET https://markdownregistry.com/api/v1/artifacts/art_2jahdkyh4wgnckkx
GET https://markdownregistry.com/api/v1/resolve?ref=bjornmelin/dev-skills/pre-mortem
GET https://markdownregistry.com/api/v1/blob/16e405097c9c78a62fc87e49fd0bad3310afe52a3123cbba459e6ddae3e3be0d
Your AI assistant does the legwork. You hear about the deals worth your word. Hand yours the standing instructions at modelranch.com and it joins the network that reads files like this one.
bjornmelin/dev-skills · archive/skills/browser-workbench-setup/SKILL.md · Set up browser automation and UI QA for a new repository using playwright-interactive as the primary interactive tool…
bjornmelin/dev-skills · archive/skills/bun-audit/SKILL.md · Shared Bun audit/remediation router. Use when auditing a repo for Bun-first correctness, explaining findings, listing…
bjornmelin/dev-skills · archive/skills/managing-tech-debt/SKILL.md · Help users manage technical debt strategically. Use when someone is dealing with legacy code, planning refactoring…
avelikiy/great_cto · skills/pre-mortem/SKILL.md · Imagine the project has already shipped and failed catastrophically — work backwards from the failure to identify the…
rjmurillo/ai-agents · src/claude/skills/pre-mortem/SKILL.md · Guide prospective hindsight analysis to identify project risks before failure occurs. Teams imagine the project has…
rjmurillo/ai-agents · .claude/skills/pre-mortem/SKILL.md · Guide prospective hindsight analysis to identify project risks before failure occurs. Teams imagine the project has…
ysskrishna/ai-agent-skills · skills/pre-mortem/SKILL.md · Use for a pre-mortem, or before committing to a plan, launch or migration: "what could go wrong?", "stress test this…
stefanoskarakasis/product-marketing-skills · pmm-execution/skills/pre-mortem/SKILL.md · Runs a cross-functional pre-mortem on a strategic initiative (product launch, pricing change, GTM pivot, new market…
broomva/skills · skills/strategy/pre-mortem/SKILL.md · Assumes a project has already failed, works backward to identify the top causes, scores them by likelihood and impact…
