Premortem skill

Overview

Скилл = советник, не риск-аудитор. Показывает что юзер не видит → предлагает варианты → юзер выбирает → агент потом исполняет. Четыре фазы: pre-flight (синхронизация контекста), silent scan (3 параллельных помощника находят 5–8 дыр), live диалог (краткие решения по каждой дыре, расширение топа), запись (<plan-name>.md + история в history/).

Цель — лёгкая 10–15-минутная сессия, не тяжёлый аудит.

Главный принцип: скрипты делают всю детерминированную механику (I/O, schema, ID, sort, dedup, classifier-switch). LLM — только семантика.

Триггеры

Включаем:

• «премортем», «premortem», «premortem this», «run premortem»
• «найди дыры в плане»
• «посмотри со стороны на план»
• «что я упускаю в <конкретный план>»
• «future-proof this <plan/launch/decision>»
• «what could kill this <plan/launch>»

НЕ включаем (слишком широкие):

• «should I», «what could go wrong», «stress test», «what am I missing», «devil's advocate this» — конфликтуют с базовым поведением модели.

Когда применимо

• Конкретный план / запуск / решение с обратимым выбором.
• Юзер готов потратить 10–15 минут.
• Есть минимум контекста (предмет / аудитория / успех).

Когда НЕ применимо

• Идея без формы — сначала помочь оформить план.
• Вопрос с одним правильным ответом — просто ответить.
• Уже принятое необратимое решение — премортем не вернёт назад.
• Творческая правка черновика — это редактирование, не премортем.

Phase 1: Pre-flight — синхронизация контекста

Цель: установить 5 минимумов: предмет / аудитория / критерий успеха / горизонт оценки / reference class.

Действия:

1. Прочитать контекст. Просканировать текущий разговор и доступные файлы (Read / Glob). Извлечь то что уже сказано — не спрашивать заново.

2. Найти пробелы. Сравнить с пятью минимумами. Записать что есть, что нет.

3. Задать максимум 2 вопроса за раз. Если не хватает 4 элементов — спросить 2, получить ответ, спросить ещё 2. Не делать «анкету» из 5 вопросов сразу.

4. Reference class — отдельный вопрос. «На что это похоже из уже сделанных проектов? Назови 1–2 примера — твоих или известных тебе». Если юзер говорит «не знаю» — двигаться дальше с пустым reference_class, помощники получат сигнал.

5. Горизонт оценки — выбор из меню.

   Через сколько оценим что план провалился?
   А) через 30 дней
   Б) через 3 месяца
   В) через 12 месяцев
   Г) после первого пилота
   Д) после запуска
   Е) после привлечения первых N клиентов
   Ж) иное (напиши своё)
   

6. Неясности → assumption. Если после 2 раундов вопросов что-то остаётся туманным — пометить как assumption и передать в Phase 2 в составе угла «Допущения». Не блокировать сессию.

7. Resolve plan-name. Спросить или вывести из контекста. Прогнать через CLI:

   uv run scripts/cli.py slugify "<plan name from user>"
   

   Запомнить slug — он будет именем файла.

8. Существует ли файл? Запустить:

   uv run scripts/cli.py find docs/premortem --name "<plan_name>"
   

   Если файл уже есть — это повторный запуск, перейти к секции «Rerun logic» ниже. Если нет — продолжать новый сценарий.

Phase 2: Silent scan — взгляд с разных сторон

Цель: 3 параллельных помощника находят 5–8 уникальных дыр.

Действия:

1. Классифицировать тип плана и выбрать углы. Запустить:

   uv run scripts/cli.py classify "<plan_text>"
   

   Получить JSON: {profile, angles, confidence, matched_keywords}.

   Если confidence < 0.4 — fallback: задать одному LLM-помощнику вопрос «какие 6 углов лучше всего видят дыры этого плана» (одной строкой, без объяснений). Использовать его ответ.

   Юзеру показать только список выбранных углов одной строкой:

   Смотрю с углов: Клиент, Исполнитель, Противник, Допущения, Конкурент, Будущий поддерживающий.
   

2. Установить premortem-фрейм.

   «Представим что к [горизонту] этот план провалился. Не "может провалиться" — провалился, факт. Что произошло?»

   (См. references/frame-language.md.)

3. Запустить 3 параллельных помощника одним сообщением.

   Каждый получает свой промпт из references/helper-prompt-template.md плюс назначенные углы (по 2 угла на помощника). Распределение: 6 углов на 3 помощника = (2,2,2). Один помощник получает «Будущий поддерживающий» с обязательным WYSIATI-микрошагом.

   Модель: Opus 4.7 по умолчанию. Если юзер запустил скилл с флагом --model sonnet — Sonnet. Если флага нет, скилл может предложить выбор перед stage 2 одной строкой:

   «Запускаю на Opus ($1–2). Sonnet будет дешевле ($0.50–1) — переключить?»

   Параллельно: ВСЕ 3 в ОДНОМ сообщении с тремя Task tool calls.

4. Получить 6 сырых ответов (3 × до 2). Прогнать каждый через валидатор:

   uv run scripts/cli.py validate-helper < helper_response.json
   

   Retry policy. Максимум 3 attempts на помощника. Классификация ошибок:

   Тип ошибки	Retryable?	Сообщение для retry
   Невалидный JSON / extra prose	да	«Верни ТОЛЬКО JSON, без преамбулы»
   Schema fail (отсутствует поле)	да	«Не хватает поля X в дыре N»
   maxItems >2	да	«Максимум 2 дыры; верни лучшие 2»
   Generic risks без привязки к плану	да	«Дыры слишком общие; привяжи к деталям плана»
   Empty holes ({"holes": []})	НЕТ	принять как валидный пустой ответ
   Low confidence на всех дырах	НЕТ	принять как есть, пометить assumption

   Если после 3 attempts всё ещё ошибка — отбросить ответ помощника, продолжить с тем что есть. Не чинить вручную.

5. Hash-дедуп. Прогнать все валидные дыры через:

   uv run scripts/cli.py dedup < all_holes.json
   

   Убирает явные дубли по нормализованному описанию (sha256). Оставшиеся дубли (одна дыра, разные слова) обработает шаг 6.

6. Семантический дедуп (LLM clustering). Если после hash-дедупа осталось >8 дыр — попросить LLM сгруппировать близкие в кластеры. Промпт:

   Вот N сырых дыр от трёх помощников. Какие из них на самом деле ОДНА И ТА ЖЕ дыра,
   видимая с разных углов? Верни JSON:
   [
     {
       "merged": [индексы дыр объединённые в одну],
       "title": "новое объединённое название",
       "merged_from_angles": ["Клиент", "Допущения"],  // углы-источники
       "merged_descriptions": ["исходное описание 1", "исходное описание 2"]
     },
     ...
   ]
   
   ПРАВИЛА:
   - Не теряй нюансы: если две дыры близки но имеют разный угол атаки — оставь обе.
   - Если все 8+ — действительно разные дыры, верни пустой массив (ничего не объединять).
   - Объединение допустимо только если ≥80% совпадение по сути.
   

   Применить кластеры: для каждой объединённой дыры в Hole.merged_from записать ID исходных дыр (после назначения ID на шаге 8), в Hole.углы — все исходные углы, в описание — выбрать самое богатое исходное описание.

7. Лимит на 8. Если после семантического дедупа всё ещё >8 — ранжировать по важность × уверенность × novelty (где novelty = 1 для новых, 0.5 для похожих на ранее найденные при rerun) и взять топ-8. Не отбрасывать assumption-дыры приоритетно — они часто и есть самое ценное.

8. Назначить ID. Каждой уникальной дыре дать ID через:

   uv run scripts/cli.py next-id --existing "H-001,H-002"
   

   На первом запуске стартуем с H-001. Сохранить порядок: первая дыра → H-001, вторая → H-002, и т.д.

9. Сохранить промежуточный snapshot in-memory (объект Plan). На диск пока не пишем — это произойдёт в Phase 4.

Phase 3: Live диалог — выбор решений

Цель: юзер быстро принимает решения по 5–8 дырам в кратком режиме. Топ 1–3 + high-impact дыры расширяются до полного режима постфактум.

Per-hole loop (краткий режим по умолчанию):

1. Презентация дыры.

   ### H-NNN: <title>
   <описание (1 абзац)>
   Почему важно: <одна фраза>
   Угол: <угол>
   Уверенность: <маркер>
   

2. Варианты решения. Сгенерировать 2–3 стратегических варианта (LLM, не скрипт). Каждый = направление с +/–, не задача.

   А: <направление 1> (+быстро, –не масштабируется)
   Б: <направление 2> (+глубоко, –долго)
   В: <направление 3> (+качество, –теряем момент)
   

3. Юзер. Выбирает / просит ещё / откладывает / отвергает / просит «расширь H-NNN» (тогда сразу полный режим для этой дыры).

4. Если выбрал — фиксация в краткий режим:

   • что выбрали (одна строка)
   • почему (одна фраза)
   • первый шаг (одна задача)
   • исполнитель: агент / человек / оба

5. Переход к следующей дыре.

После всех дыр — финальная приоритизация:

1. Проверка: есть ли принятые дыры?

   Если 0 принятых дыр (все ОТЛОЖЕНО / ОТВЕРГНУТО) — спросить юзера явно:

   «Ты не принял ни одного решения. Возможны варианты: А) сохранить как обзор без действий (юзер увидел дыры, решил пока ничего не делать) Б) вернуться к 1–2 дырам и принять решения В) пересмотреть — может я плохо предложил варианты

   Что делаем?»

   Если А — переходим к шагу 5 (session_recommendation), пропускаем топ и bias. Если Б — возвращаемся к Phase 3 per-hole loop для выбранных юзером дыр. Если В — перегенерируем варианты решений для названных дыр.

2. Топ 1–3. Скилл сам отбирает из ПРИНЯТЫХ по важность × обратимость × уверенность. Если ПРИНЯТЫХ < 3 — берём все.

3. Авто-расширение до полного режима. Для каждой дыры из топ 1–3 ИЛИ для любой ПРИНЯТОЙ дыры с (важность=высокая И уверенность ≠ предположение) — задать недостающие поля одним проходом:

   • 2–3 первых шага (prevent)
   • сигнал успеха (detect)
   • стоп-условие
   • что делать если уже случилось (limit damage)
   • открытые вопросы

   Пометить эти дыры режим: полный.

4. Bias-проверка топа (1 вопрос юзеру).

   Скилл сам прогоняет топ через 6 биасов в системном промпте (см. references/bias-checklist.md), выбирает наиболее вероятный риск искажения и показывает юзеру:

   «Какой биас мог сильнее всего исказить твой топ? Я думаю — <биас>. Коррекция: <конкретное действие>. Согласен или другой?»

   Юзер подтверждает или меняет. Записывается одна строка в bias_проверка.

5. Session recommendation — явный шаг.

   Скилл предлагает рекомендацию по сессии (один из 4 enum-значений) на основе паттерна принятых решений:

   • continue — большинство решений идут вперёд, нет дыр со статусом ОТЛОЖЕНО среди топа
   • reduce_stake — топ содержит решения вида «пилот / меньше / медленнее»
   • delay — есть ОТЛОЖЕНО в топе или явно сказано «доделать позиционирование / подождать»
   • abort — все или большинство критических дыр ОТВЕРГНУТЫ, или решения = «отказаться»

   Скилл показывает свою предварительную рекомендацию + причину, юзер подтверждает или меняет:

   «Моя рекомендация по сессии: delay — есть отложенные дыры в топе. Ты подтверждаешь эту общую рекомендацию или предпочитаешь: continue / reduce_stake / abort?»

   Записывается в Plan.session_recommendation.

6. Reverse премортем (условный). Запускается только если session_recommendation in {reduce_stake, delay, abort}. Если continue — пропускается.

   «Прошёл [горизонт]. Не сделали (или сделали меньше). Оказалось зря — почему?»

   LLM генерирует 3 сильные причины + одну строку «что перевешивает». Записывается в reverse_премортем.

Phase 4: Запись с итерациями

Цель: один main-файл + история снимков. Любая последовательность запусков оставляет файл валидным.

Действия:

1. Собрать Plan dataclass. В памяти на основе данных из Phase 3.

2. Атомарная запись.

   uv run scripts/cli.py write --plan-json <plan.json> --path docs/premortem/<slug>.md
   

   CLI: валидирует → пишет во временный файл → fsync → os.rename. Lock через fcntl.

3. Снимок в history/.

   uv run scripts/cli.py snapshot docs/premortem/<slug>.md
   

   Создаёт history/<slug>-<YYYY-MM-DD-HHMM>.md.

4. Финальное сообщение юзеру.

   Премортем сохранён: docs/premortem/<slug>.md (запуск N).
   Топ 1–3:
   1. H-XXX — <title>. Первый шаг: ...
   2. H-YYY — ...
   3. H-ZZZ — ...
   
   История: docs/premortem/history/<slug>-<ts>.md
   

   Не пересказывать всё содержимое файла — юзер сам прочитает.

Rerun logic (повторный запуск)

Триггерится в Phase 1 шаг 8: файл уже существует.

Действия:

1. Прочитать существующий файл. Скрипт plan_io.py read.

2. Показать сводку. Запустить:

   uv run scripts/cli.py stats docs/premortem/<slug>.md
   

   Юзеру:

   Нашёл прошлый премортем по «<plan_name>» от <дата>.
   <всего> дыр: <принято> ПРИНЯТО, <в_работе> В РАБОТЕ, <отложено> ОТЛОЖЕНО, <закрыто> ЗАКРЫТА.
   Что хочешь сделать?
   А) обновить статусы существующих дыр
   Б) найти новые дыры
   В) и то и другое
   Г) начать заново под новый этап проекта
   

3. А или В: обновить статусы. Пройти по всем активным дырам (не ОТВЕРГНУТО / не ЗАКРЫТА), спросить «Что с H-NNN: <title>? Не изменилось / в работе / закрыто (опиши как) / отвергнуто (причина)». Обновить статус и история_статуса.

4. Б или В: новые дыры. Запустить Phase 2 заново, передать помощникам список существующих дыр в формате:

   Уже найденные дыры (не повторять):
   H-001: <title>
   H-002: <title>
   ...
   

   Помощники возвращают находки + статус каждой: same / worse / resolved / new / new-aspect.

5. Г: начать заново. Юзер уточняет — это новый этап того же плана (тогда продолжаем в тот же файл, увеличиваем запусков) или новый план (тогда спрашиваем новое имя, создаём новый файл, оставляем старый нетронутым).

6. Обновить frontmatter. обновлён = сегодня, запусков += 1.

7. Снимок и запись. Как в Phase 4.

Что скилл НЕ делает

• Не предлагает численные вероятности — LLM не калиброван.
• Не использует 12-вопросный bias-чеклист как фазу — только 6 биасов в системном промпте.
• Не генерит HTML / Slack / Notion — только md файл.
• Не пытается заменить decision journal или OKR.
• Не запускает reverse premortem если рекомендация = продолжать.