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

Цепочка: запись -> локальная транскрипция с картинками -> список задач -> план разработки по 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, дата - дата встречи, если ее видно из имени записи, иначе сегодняшняя.

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

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

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

## Задачи

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

### 2. ...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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