murphy-jutsu

name

murphy-jutsu

description

Run a pre-mortem on a project, plan, feature, or design — the pessimistic/critical twin of brainstorming. Systematically surfaces what could go wrong, ranks each risk by likelihood × blast-radius, and converts it into a concrete check or mitigation. Use when the user wants a pre-mortem, a risk review, a "what could go wrong?" pass, red-teaming of a plan, a failure-mode brainstorm, or a sanity check before committing/shipping/granting an agent autonomy. The method is domain-agnostic; for AI/LLM/agent/RAG projects it routes into specific failure-domain lenses (the murphy-* sub-skills).

Murphy-Jutsu — the art of "what could go wrong"

The pessimistic twin of brainstorming. Where brainstorming explores the space of what could work, murphy-jutsu explores the space of what could fail — before reality charges you for finding out. Named for Murphy's Law: "anything that can go wrong, will."

Use this as a process skill: run it on a plan/design/project before implementation, before a launch, or before handing an agent the keys.

The pre-mortem flip

Don't ask "what are the risks?" — that invites vague, generic answers. Instead assume the failure already happened:

"It's six months from now. This project failed / leaked data / blew the budget / got quietly abandoned. Write the post-mortem. What happened?"

Working backward from a concrete failure surfaces specific, plausible causes that a forward "risk list" misses. (Research backing: prospective hindsight increases the accuracy of identifying reasons for future outcomes.)

Workflow

1. Frame the target. Restate the project/plan in one or two sentences, and name what "success" and "catastrophe" each look like concretely.
2. Pick the lenses. Scan the project against the failure-domain checklist below and the AI lenses table. Pull in every lens that plausibly applies — over-include rather than under-include.
3. Pre-mortem each lens. For each, do the flip: imagine it caused the failure, then enumerate concrete failure modes (mechanism + warning signs). Load the matching murphy-* sub-skill for its catalog.
4. Score & rank. For each failure mode, rate likelihood (how probable) and blast radius (how bad if it happens — reversible vs permanent, contained vs company-ending). Sort by likelihood × blast radius. A low-probability / unrecoverable risk still ranks high.
5. Convert to checks. Every surviving risk becomes one of: a check to run now, a mitigation to build, a guardrail to add, or an explicit accepted-risk decision. A risk with no owner and no action is just a worry — make it actionable or consciously drop it.
6. Output a risk register (see format below), top risks first.

Domain-agnostic failure-domain checklist

Prompts that apply to almost any project — ask the pessimistic version of each:

• Scope & assumptions — which load-bearing assumption, if false, sinks this? What "obviously true" thing has nobody verified?
• Reversibility & blast radius — which actions are irreversible? What's the worst single command/deploy/click, and what does it reach?
• Dependencies — what do we rely on that we don't control (vendor, API, data source, one person)? What happens when it's down, slow, or gone?
• Data & state — what's the most valuable/irreplaceable data, and could this corrupt or delete it? Is there a recent, tested, restorable backup?
• Security & trust boundaries — where does untrusted input enter? What's the leak path for secrets/credentials/PII?
• People & operations — who understands this at 3 a.m.? What's the bus factor? What silently rots when the original author leaves?
• Cost & limits — what runs unbounded (spend, retries, storage, tokens)? Where's the meter, and who watches it?
• Time & second-order effects — what looks free on day one but sends an invoice on day 60? What does success itself break (scale, load, lock-in)?

AI / LLM / agent failure lenses (sub-skills)

When the project involves models, agents, retrieval, or generated code, load the matching lens for its concrete failure catalog and pre-mortem questions:

Lens (sub-skill)	Load when the project involves…
murphy-agent-blast-radius	Autonomous agents with real tools — shell, filesystem, DB, deploy, write access, CI loops
murphy-context-rot	Long agent sessions, growing codebases, long chat histories, big context dumps, multi-day work
murphy-retrieval-trust	RAG, vector search, embeddings, citations, document Q&A, knowledge bases, grounding
murphy-hallucinated-output	AI-generated code, copilots, AI-suggested dependencies/APIs/citations trusted by reading
murphy-model-hype	Picking/trusting a model, reading benchmarks or launch claims, model upgrades/swaps, sim-trained agents
murphy-complexity-invoice	Vibe coding, fast prototypes, high AI-generated code volume, "ship it now" pressure, second-brain/note systems

Multiple lenses usually apply to one project — agent-blast-radius and context-rot, or model-hype and hallucinated-output, frequently travel together.

Risk register output format

## Pre-mortem: <project>

### 🔴 High (act before proceeding)
- **<risk>** — likelihood: <H/M/L>, blast radius: <H/M/L>
  - How it happens: <mechanism>
  - Warning signs: <leading indicators>
  - Mitigation / check: <concrete action + owner>

### 🟡 Medium (mitigate or schedule)
- ...

### 🟢 Low (monitor / accept)
- ...

### Accepted risks
- <risk> — accepted because <reason>, owner <who>

Stance & cautions

• Be specific or be silent. "Security could be an issue" is noise. "The agent has the prod DB connection string and runs DELETE statements it composes itself — one missing WHERE drops the table" is a finding. If a risk could apply to any project, sharpen it or cut it.
• Pessimism is the mode, not the verdict. The job is to surface failures so they can be mitigated, not to talk the user out of the project. End with the path forward (mitigations), not just the wreckage.
• Rank by blast radius, not just probability. Rare-but-unrecoverable beats common-but-trivial.
• A worry without an action is incomplete. Push every risk to a check, a guardrail, or an explicit accepted-risk decision.

Provenance

The AI failure-domain lenses are mined from the ec1-dev video essays (one transcript + mining-notes set per video under ../../transcripts/). Recurring channel motifs worth internalizing: "complexity always sends an invoice," "more is not better," "AI is an overconfident intern," and "would you let an intern do this unsupervised, with your keys?"