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