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