---
name: meeting-to-tasks
description: "Полный цикл от записи встречи до планов разработки: локальная транскрибация с разбором экрана и скриншотами, извлечение списка задач, отдельный план разработки по SDD на каждую задачу, которой нужен код. Используй ВСЕГДА, когда пользователь дает путь к записи встречи или созвона и хочет получить задачи, план, поручения или разбор - даже если слово транскрибация не прозвучало. Триггеры: разбери встречу, что по итогам созвона, какие задачи со встречи, сделай план по записи, переговоры в задачи, meeting to tasks. НЕ для простой расшифровки речи без задач - там достаточно скила transcribe."
argument-hint: "<путь к записи встречи>"
---

# Встреча в задачи и планы разработки

Цепочка: запись -> локальная транскрипция с картинками -> список задач -> план разработки по SDD на
каждую задачу, которой нужен код.

Смысл разделения на два артефакта: список задач читают люди (заказчик, команда, трекер), а план
разработки нужен только тому, кто будет писать код. Смешивать их в один документ вредно - список
перестает быть обозримым, а план тонет в организационных пунктах.

## Шаг 0. Уточнить постановку и сразу приступить

Прогони исходную просьбу пользователя через скил `prompt-enhancer` - он развернет короткую формулировку
в явное задание с шагами и граничными случаями. Это дешевая страховка от того, что половина сказанного
на встрече будет разобрана, а половина потеряна.

Улучшенный промпт не выноси на одобрение. Пользователь просит улучшить и **приступить**, а не улучшить
и ждать. Одобрение нужно позже - перед реализацией планов, не перед их составлением.

## Шаг 1. Транскрибировать локально, с картинками

Вызови скил `transcribe`:

```
"<путь к записи>" --engine local --diarize
```

Почему именно так:

- `--engine local` - записи встреч конфиденциальны, в облако они не уходят. Для видео этот режим и дает
  картинки: нарезку scene-кадров в `screenshots/` плюс разбор экрана локальной моделью зрения. Без флага
  видео ушло бы в Gemini, а это прямой запрет.
- `--diarize` - без разделения по спикерам не восстановить, кто что поручил и кто за что отвечает, а
  ответственный в задаче важнее формулировки.

Скил transcribe не модифицируй - он самодостаточен и конфигурируется своим `.env`.

Транскрибация локального видео идет десятки минут. Запускай фоном (`run_in_background`) и не опрашивай
статус: харнесс уведомит о завершении. Пока идет фон, можно готовить структуру папок и выяснять
конвенции проекта, но выдумывать содержание задач до готового транскрипта нельзя.

Картинки нужны всегда, когда в записи есть видеоряд: скрипт нарезает scene-кадры в `screenshots/` и
разбирает экран моделью зрения. На встречах показывают формы, документы, конфигурации, и половина
постановки часто живет именно на экране, а не в словах.

Пропасть картинки могут в двух случаях, и путать их нельзя:

- **На входе чистое аудио** (m4a, mp3, wav и подобное). Видеодорожки нет, нарезать нечего. Работай по
  речи и скажи пользователю, что запись была без видео.
- **Модель зрения недоступна.** Кадры все равно нарезаются и лежат в `screenshots/`, теряется только
  текстовое описание экрана. Это не повод считать визуальную часть потерянной: открой нужные кадры сам,
  глазами, отталкиваясь от таймкодов спорных мест в транскрипте.

Транскрибация деградирует по частям: может не подняться модель зрения, может отвалиться сервер. Это не
повод останавливаться. Прочитай `<имя>.status.json`, возьми что есть и честно перечисли, что осталось
неразобранным. Неполный результат с явным перечнем дыр полезнее отказа.

Для анализа читай `- саммари.md` и `- со спикерами.md`, а `- детальный.md` подключай там, где нужен
контекст экрана (показывали форму, документ, конфигурацию). Кадры из `screenshots/` смотри выборочно, под
конкретный вопрос: в получасовой встрече их бывает под сотню, читать подряд бессмысленно.

## Шаг 2. Список задач

Пройди транскрипт и вытащи все, что кто-то должен сделать. Задача - это не всякая произнесенная мысль:
нужен адресат действия. Обсуждение без вывода задачей не становится, но если по теме явно нужно решение
и его не приняли, это открытый вопрос - его тоже фиксируй, отдельно от задач.

Сохрани список в проект, в `Documents/Разработка/` (или в аналогичную папку рабочих документов проекта,
если структура другая). Имя файла: `<ГГГГ-ММ-ДД>_Задачи_со_встречи_<тема>.md`, дата - дата встречи, если
ее видно из имени записи, иначе сегодняшняя.

Структура файла:

```markdown
# Задачи со встречи <дата>, <тема>

Участники: <кто был слышен>
Запись: <путь>, транскрипт: <путь>

## Задачи

### 1. <Короткое название>
Что сделать: <формулировка>
Ответственный: <кто, если назван>
Срок: <если назван>
Требуется разработка: да / нет
Источник: [MM:SS] <короткая цитата или пересказ>

### 2. ...

## Открытые вопросы
- <вопрос> - [MM:SS], кто должен ответить

## Решения
- <принятое решение> - [MM:SS]
```

Таймкод и цитата - обязательная часть. Через неделю никто не вспомнит, откуда взялась формулировка, а
спор о том, что именно просил заказчик, разрешается только возвратом к записи.

Выведи список задач в чат целиком, а не ссылкой на файл. Пользователь просит именно показать его -
скорее всего, чтобы сразу занести в трекер или переслать.

Признак "требуется разработка": задача меняет код, метаданные, настройки, которые правятся в исходниках.
Не требуют разработки: организационные (запросить документ, назначить встречу, уточнить у смежников),
настроечные в пользовательском режиме, а также задачи чужой зоны ответственности - вендора или смежной
команды. Зоны ответственности смотри в CLAUDE.md проекта: попытка запланировать чужую работу как свою
создает ложное ощущение объема и потом всплывает как срыв.

## Шаг 3. План разработки на каждую задачу

Для каждой задачи с признаком "требуется разработка" сделай ОТДЕЛЬНЫЙ план. Не один общий на встречу:
задачи живут своей жизнью, у каждой свой срок, свое согласование и своя судьба, а общий план на пять
задач невозможно ни закрыть, ни отдать в работу по частям.

Планы клади в `~/.claude/plans/<имя-проекта>/`, где имя подпапки - последний каталог рабочей директории.
Подпапки нет - создай. Имя файла: `План_разработки_<номер задачи в трекере или слаг названия>.md`.

План делается по SDD-workflow, фазы 0-4: оценка сложности, требования, исследование кодовой базы,
уточняющие вопросы, архитектура с инвариантами и этапами. Фазы 5 и дальше (ревью плана, реализация) -
не здесь: реализация начинается только после явного одобрения пользователем.

В шапке каждого плана обязательна привязка к встрече:

```markdown
# План разработки: <название задачи>

Источник: встреча <дата>, задача N из <путь к файлу списка задач>
Постановка на встрече: [MM:SS] <цитата>
Ответственный: <кто>
```

Без этой привязки план через месяц выглядит как задача из ниоткуда, и первым делом приходится
восстанавливать, кто и зачем ее просил.

Содержание плана - текст, а не код: что сделать, где, каким подходом. Фрагменты реализации в план не
вставляй, если пользователь не попросил отдельно.

Исследование кодовой базы (фаза 2) делай по-настоящему, а не формально: без него архитектурная часть
плана будет фантазией. Если по задаче не хватает данных для проектирования, так и напиши в плане, в
разделе уточняющих вопросов, вместо того чтобы придумывать недостающее.

## Что показать в конце

- Список задач - полностью в чате.
- Пути: транскрипт, папка скриншотов, файл списка задач, каждый файл плана.
- Задачи, по которым план НЕ делался, и почему (не требуют разработки, чужая зона, слишком мало данных).
- Что осталось неразобранным в транскрипции, если стадии деградировали.

Последние два пункта важнее, чем кажется. Молча пропущенная задача выглядит как несуществующая, и всплывет
она уже как претензия.