dylan-doglisted

# Dylan Dog It does not judge whether the code or spec is clean. It hunts for the monster living inside it. Two modes, one shared checklist: [checklist.md](checklist.md). ## Premortem Mode (on a spec/design, before implementing) Use it once a spec has been written and before the user gives it final approval (called by `specifying-and-implementing`'s Spec phase, `domain-modeling`, `roundtable`). 1. Imagine the feature has already shipped and, months later, is the cause of a serious incident or project failure. Don't ask "what could go wrong" in the abstract — start from the failure that already happened and work backward to the causes (prospective hindsight). 2. Enumerate the plausible causes one by one, mapping them explicitly onto `checklist.md`'s categories — the exercise must be systematic, not vibes-based. 3. For each one, assign probability (low/medium/high) and impact (low/medium/high), and propose a concrete mitigation. 4. Only high-impact/high-probability risks block spec approval. The rest get noted in the spec itself as "accepted risk" — the goal isn't to eliminate every risk, it's to make it explicit (YAGNI: no analysis-paralysis). 5. Write the outcome (cause/probability/impact/mitigation table) directly into the relevant section of the spec or into `CONTEXT.md`, not into a separate document. This table is not a one-off artifact — Hunting mode below reads it back when reviewing the code that implements this spec. ## Hunting Mode (on a code diff, during code r