kodu 2.1.2 → 2.2.0

package/skills/post-call-task-builder/SKILL.md

@@ -0,0 +1,419 @@
+---
+name: post-call-task-builder
+description: Create structured technical specifications and development tasks from meeting transcripts OR refine and organize user-provided task lists (optionally enriched with transcript context). Use after team meetings, planning sessions, architecture discussions, or when user provides a raw task list that needs structuring, prioritization, and validation against the codebase.
+---
+
+# SKILL: Создание и доработка задач
+
+## PURPOSE
+
+Этот скилл работает в двух режимах:
+
+**Режим A — Из созвона:**
+
+- прочитать транскрипцию разговора;
+- понять решения, проблемы и договорённости;
+- изучить кодовую базу текущего проекта;
+- задать уточняющие вопросы;
+- предложить Парето-оптимальное решение;
+- подготовить понятное ТЗ и список задач.
+
+**Режим B — Из готового списка (с возможным контекстом из созвона):**
+
+- принять список задач от пользователя;
+- если пользователь также дал транскрипцию — извлечь из неё контекст, причины, приоритеты;
+- изучить кодовую базу;
+- проверить реалистичность, полноту и связность задач;
+- доработать: добавить контекст, критерии готовности, порядок выполнения;
+- указать риски, зависимости и скрытую сложность.
+
+Главная цель — превратить входные данные (разговор или список) в практичный план работ, написанный простым языком, как
+для джуна.
+
+## CRITICAL CONSTRAINTS (НАРУШИТЬ НЕЛЬЗЯ)
+
+**1. Полное исследование кодовой базы — ОБЯЗАТЕЛЬНО перед любыми формулировками задач.**
+
+- Прежде чем писать хоть одну задачу, ТЗ или пункт плана — ты ОБЯЗАН провести полное исследование текущего проекта.
+- Исследование включает: структуру проекта, стек, архитектуру, ключевые модули, точки входа, зависимости, тесты, конфиги, README.
+- Никаких исключений. Нет исследования → нет задач.
+
+**2. НЕ СПРАШИВАЙ у пользователя «что анализировать?» или «какие модули смотреть?».**
+
+- Ты сам определяешь область исследования и проводишь его автоматически.
+- Твоя задача — изучить весь проект досконально. Пользователь не должен подсказывать, куда смотреть.
+- Если проект большой — начинай с корня (package.json, tsconfig, README, структура src/), затем углубляйся в модули, связанные с темой задач.
+
+**3. Формулировка задач — ТОЛЬКО после завершения исследования.**
+
+- Начинай формулировать задачи только когда у тебя есть полная картина проекта.
+- Каждая задача должна опираться на конкретные файлы, модули и архитектурные решения, которые ты видел в коде.
+- Если ты не изучил проект — вернись к исследованию, а не придумывай задачи «от балды».
+
+## ACTIVATION
+
+Используй этот скилл, если пользователь:
+
+- прислал транскрипцию созвона или указал файл с ней;
+- просит разобрать итоги созвона;
+- просит составить задачи, ТЗ, план реализации или backlog по результатам обсуждения;
+- предоставил свой список задач и просит его доработать, структурировать или проверить;
+- предоставил и список задач, и транскрипцию — чтобы задачи были составлены с учётом контекста разговора;
+- хочет, чтобы ты сначала изучил кодовую базу проекта, а потом оформил задачи.
+
+## DO NOT USE WHEN
+
+Не используй этот скилл, если:
+
+- пользователь не хочет задач или ТЗ;
+- нужно просто кратко пересказать созвон без анализа проекта;
+- пользователь просит игнорировать кодовую базу;
+- пользователь уже дал готовое ТЗ, и нужно только отредактировать текст (без проверки по коду).
+
+## INPUTS
+
+**Обязательные (без них не начинай):**
+
+- **доступ к кодовой базе проекта** — ты должен исследовать проект ПЕРЕД формулировкой задач. Если путь не указан — определи его по контексту рабочей директории. Если проект недоступен — скажи об этом и не продолжай.
+- место, куда нужно записать результат.
+
+**Для режима A дополнительно:**
+
+- путь к файлу с транскрипцией или её текст.
+
+**Для режима B дополнительно:**
+
+- список задач от пользователя (текст, файл, сообщение);
+- опционально: транскрипция или ссылка на созвон для контекста (помогает понять причины, приоритеты, скрытые требования).
+
+**Чего НЕ НУЖНО спрашивать у пользователя:**
+
+- «Какие модули мне посмотреть?» — сам определи по структуре проекта.
+- «Какие файлы важны для этой задачи?» — сам найди через исследование.
+- «Где находится нужный функционал?» — сам отследи по кодовой базе.
+- «Что именно анализировать?» — анализируй ВСЁ, что относится к теме задач.
+
+Если не хватает только транскрипции (режим A) или списка задач (режим B) — задай короткий уточняющий вопрос. Но кодовую базу исследуй в любом случае.
+
+## PROCESS
+
+### Шаг 0. Определи режим работы и исследуй проект
+
+**Этот шаг ОБЯЗАТЕЛЕН. Без него не переходи к формулировке задач.**
+
+#### 0.1. Определи режим
+
+- Если пользователь дал только транскрипцию (без списка задач) → режим A.
+- Если пользователь дал готовый список задач (с транскрипцией или без) → режим B.
+- Транскрипция в режиме B используется как дополнительный контекст — чтобы точнее понять причины задач, приоритеты и ожидания.
+- Если дана только транскрипция, но пользователь явно просит «составь задачи» → режим A.
+
+#### 0.2. Проведи полное исследование кодовой базы (ОБЯЗАТЕЛЬНО)
+
+**Не спрашивай у пользователя «что анализировать?» — исследуй проект сам.**
+
+Порядок исследования:
+
+1. **Корень проекта** — прочитай package.json (или аналог), README, конфиги (tsconfig, biome, eslint, etc.), .env.example.
+2. **Структура** — определи организацию src/ (или другую основную директорию), ключевые директории и их назначение.
+3. **Точка входа** — найди main entry point, пойми как приложение запускается.
+4. **Архитектура** — определи паттерн (MVC, модульный, сервисный слой, etc.), зависимости между частями.
+5. **Ключевые модули** — изучи основные модули/сервисы, их ответственность и связи.
+6. **Зависимости** — посмотри какие библиотеки используются и зачем.
+7. **Тесты** — есть ли тесты, какой фреймворк, какого покрытия не хватает.
+8. **Связь с темой** — углубись в те части кода, которые напрямую связаны с задачами из транскрипции или списка пользователя.
+
+Если проект большой — начинай с наиболее вероятных точек изменения, затем расширяй обзор. Но в итоге ты должен получить полную картину.
+
+**Результат исследования** — ты должен ответить себе на вопросы:
+- Как устроен проект в целом?
+- Какие модули/сервисы relevant к задачам?
+- Какие ограничения есть в текущей архитектуре?
+- Где уже есть нужный функционал, а чего не хватает?
+- Что может сломаться при изменениях?
+
+Только после этого переходи к формулировке задач.
+
+---
+
+### Режим A: Из созвона
+
+#### A1. Прочитай транскрипцию
+
+Извлеки из неё:
+
+- цели созвона;
+- проблемы;
+- решения;
+- спорные моменты;
+- зависимости;
+- риски;
+- упомянутые файлы, модули, сервисы, эндпоинты, таблицы, очереди, интеграции.
+
+#### A2. Сопоставь транскрипцию с результатами исследования
+
+Ты уже исследовал проект на шаге 0.2. Теперь сопоставь увиденное в коде с тем, что обсуждалось на созвоне:
+
+- что именно уже есть в проекте по теме созвона;
+- чего не хватает;
+- какие пункты из созвона реально внедрить быстро;
+- какие требуют более крупной переработки;
+- где есть технические риски или скрытая сложность.
+
+#### A3. Предложи Парето-оптимальное решение
+
+Перед уточняющими вопросами обязательно покажи рекомендованный вариант.
+
+Парето-оптимальное решение — это решение, которое:
+
+- даёт максимальную пользу при минимальной сложности;
+- закрывает большую часть ценности задачи;
+- не требует лишней архитектурной перестройки;
+- может быть реализовано быстрее и безопаснее, чем «идеальный» вариант.
+
+Оформи его так:
+
+- что предлагается сделать;
+- почему это лучший баланс между ценой и пользой;
+- какие ограничения у такого подхода;
+- что останется на следующий этап.
+
+#### A4. Задай уточняющие вопросы
+
+После анализа задай только те вопросы, без которых нельзя качественно составить задачи.
+
+Требования к вопросам:
+
+- задавай только действительно важные вопросы;
+- не больше 3–7 вопросов за один раз, если возможно;
+- вопросы должны быть конкретными;
+- рядом с каждым вопросом укажи свой рекомендуемый ответ, если он очевиден.
+
+Формат вопросов:
+
+- вопрос;
+- зачем он нужен;
+- рекомендуемый вариант, если он очевиден.
+
+#### A5. Составь ТЗ и задачи
+
+Когда пользователь ответит, подготовь результат и запиши его туда, куда он указал.
+
+---
+
+### Режим B: Из готового списка задач
+
+#### B0. Если есть транскрипция — прочитай её для контекста
+
+Извлеки из неё:
+
+- цели обсуждения — почему эти задачи вообще понадобились;
+- проблемы, которые задачи должны решить;
+- приоритеты и ожидания;
+- упомянутые файлы, модули, сервисы;
+- спорные моменты — чтобы знать, где возможны разногласия.
+
+Этот контекст понадобится на шаге B3 при доработке каждой задачи.
+
+#### B1. Изучи список задач
+
+Прочитай и классифицируй каждую задачу:
+
+- насколько конкретна формулировка;
+- есть ли критерий готовности;
+- указано ли место изменения;
+- есть ли скрытые зависимости;
+- есть ли дубликаты или пересечения.
+
+#### B2. Верифицируй задачи по результатам исследования
+
+Ты уже исследовал проект на шаге 0.2. Теперь проверь каждую задачу из списка по коду:
+
+- реалистична ли задача в текущей архитектуре;
+- есть ли уже готовые решения или аналоги;
+- какие файлы/модули нужно будет менять;
+- какие есть технические ограничения;
+- какие побочные эффекты могут возникнуть.
+
+#### B3. Доработай каждую задачу
+
+Для каждой задачи:
+
+- конкретизируй формулировку;
+- добавь контекст (почему это нужно);
+- укажи, где именно нужно вносить изменения;
+- добавь критерий готовности;
+- укажи зависимости от других задач;
+- отметь риски.
+
+Если задача нереалистична или противоречит коду — явно укажи это и предложи альтернативу.
+
+#### B4. Собери итоговый план
+
+- отсортируй задачи в порядке выполнения;
+- сгруппируй по этапам (подготовка, backend, frontend, тесты, docs, выкладка);
+- добавь общий контекст и цель;
+- укажи, что не входит в объём работ.
+
+Уточняющие вопросы задавай только если данных критически не хватает (неясна цель, нет приоритетов, непонятен стек).
+
+## DECISION RULES
+
+**PRIORITY 0: Обязательное исследование (ВЫШЕ ВСЕГО)**
+
+- Никогда не формулируй задачи без полного исследования кодовой базы.
+- Никогда не спрашивай у пользователя «что анализировать?» — делай это сам.
+- Если ты сомневаешься, достаточно ли ты изучил проект — вернись и дочитай ещё.
+
+**PRIORITY 1: Точность**
+
+- не выдумывай детали;
+- все выводы опираются на транскрипцию или код;
+- если в транскрипции есть противоречия — укажи их и предложи наиболее вероятную интерпретацию;
+- в режиме B транскрипция используется только для контекста — не переписывай задачи пользователя на основе транскрипции, если он этого не просил; дорабатывай исходный список, а не заменяй его.
+
+**PRIORITY 2: Практичность**
+
+- предлагай минимальное изменение, которое даёт максимальный эффект;
+- не предлагай решение, которое ломает текущий стиль проекта без необходимости;
+- если есть несколько путей — выбери тот, который проще внедрить, легче поддерживать и меньше рискует сломать текущий
+  функционал.
+
+**PRIORITY 3: Понятность**
+
+- пиши как для джуна;
+- избегай абстрактных фраз вроде «улучшить систему»;
+- каждая задача должна быть конкретной, проверяемой и выполнимой.
+
+## TOOL USAGE
+
+**Чтение кода:**
+
+- используй для поиска существующего функционала, точек интеграции, архитектурных ограничений;
+- на шаге 0.2 — исследуй проект ПОЛНОСТЬЮ: корень, структуру, ключевые модули, зависимости;
+- на шагах A2/B2 — фокусируйся на конкретных точках, связанных с задачами;
+- отмечай файлы, которые может затронуть изменение.
+
+**Поиск по коду:**
+
+- используй для проверки существующих решений, констант, типов, импортов;
+- на шаге 0.2 — ищи ВСЁ, что связано с темой задач, даже если кажется неочевидным.
+
+**Чтение файлов:**
+
+- перед предложением изменений прочитай существующий код точек изменения;
+- проверь наличие тестов к затрагиваемым модулям.
+
+## OUTPUT REQUIREMENTS
+
+Пиши простым и понятным языком, как для джуна.
+
+Избегай:
+
+- лишней теории;
+- сложных слов без необходимости;
+- перегруженных формулировок;
+- абстрактных фраз вроде «улучшить систему» без расшифровки.
+
+ТЗ / план работ должно включать:
+
+- цель;
+- контекст;
+- текущую проблему (для режима A) или исходный список и контекст из транскрипции (для режима B);
+- предложенное решение / доработанный список;
+- порядок выполнения;
+- критерии готовности;
+- риски и ограничения;
+- что не входит в объём работ, если это важно.
+
+Если уместно, разбивай задачи по смыслу:
+
+- подготовка;
+- backend;
+- frontend;
+- интеграции;
+- тестирование;
+- документация;
+- выкладка.
+
+**Формат задачи:**
+
+- название;
+- цель;
+- что сделать;
+- где делать;
+- результат;
+- критерий готовности;
+- зависимости.
+
+## FAILURE HANDLING
+
+**Если кодовая база недоступна:**
+
+- не придумывай задачи на основе предположений;
+- честно скажи: «Не могу получить доступ к проекту. Без исследования кодовой базы не могу составить задачи.»;
+- попроси пользователя указать путь к проекту или убедиться, что директория доступна.
+
+Если данных недостаточно (транскрипция неполная, список задач слишком размыт):
+
+- кодовую базу исследуй В ЛЮБОМ СЛУЧАЕ — она доступна независимо от транскрипции;
+- честно скажи, чего не хватает из транскрипции/списка;
+- перечисли, что удалось понять;
+- задай минимальный набор уточняющих вопросов;
+- не начинай писать ТЗ вслепую.
+
+Если в транскрипции или списке есть противоречия:
+
+- укажи их;
+- предложи наиболее вероятную интерпретацию;
+- попроси подтверждение.
+
+Если задача из списка пользователя нереалистична технически:
+
+- объясни, почему;
+- предложи альтернативу, которая решает ту же проблему.
+
+## EXAMPLES
+
+### Режим A — Хороший результат:
+
+- Прочитать транскрипцию: команда обсуждала ускорение регистрации.
+- **Автоматически** исследовать проект: найти модуль регистрации, посмотреть текущий флоу, понять архитектуру, проверить тесты.
+- Сопоставить: что уже есть (валидация email на фронте, но нет на бэке), чего не хватает (rate limiting, кэширование).
+- Предложить Парето-решение: не переписывать весь флоу, а добавить недостающую валидацию и один сервисный слой.
+- Спросить, нужно ли поддерживать старые сценарии.
+- После ответа оформить ТЗ с задачами по backend, тестам и документации.
+
+### Режим A — Плохой результат:
+
+- Спросить пользователя: «Какие модули мне посмотреть?» — вместо того чтобы самому исследовать проект.
+- Пересказать созвон общими словами без анализа кода.
+- Предложить сразу большой рефакторинг без исследования текущей архитектуры.
+- Написать ТЗ с непонятными терминами и без критериев готовности.
+
+### Режим B (со списком) — Хороший результат:
+
+- Пользователь дал список: «добавить валидацию email, сделать страницу профиля, написать тесты».
+- **Автоматически** исследовать проект: найти где уже есть валидация, посмотреть структуру страниц, проверить покрытие тестами.
+- Проверить по коду: валидация email частично есть в регистрации; страницы профиля нет; тестов на валидацию нет.
+- Доработать: конкретизировать валидацию (какие кейсы), указать где создавать страницу, добавить критерии готовности и
+  порядок выполнения.
+- Итог: 3 задачи с контекстом, местом изменений и DoD.
+
+### Режим B (со списком + транскрипция) — Хороший результат:
+
+- Пользователь дал список: «добавить валидацию email, сделать страницу профиля» и транскрипцию созвона.
+- **Автоматически** исследовать проект: найти модуль пользователей, посмотреть схему БД, проверить эндпоинты.
+- Из транскрипции: выяснилось, что валидация email нужна из-за жалоб поддержки, а страница профиля — для соответствия GDPR.
+- Проверить по коду: валидация частично есть; страницы профиля нет; база не хранит дату согласия на обработку данных.
+- Доработать: добавить задачу «добавить поле consent_date в User», скорректировать приоритеты (GDPR — выше).
+- Итог: 4 задачи с правильным порядком и контекстом.
+
+### Режим B — Плохой результат:
+
+- Спросить пользователя: «Какие файлы мне посмотреть?» — вместо автоматического исследования.
+- Просто переписать задачи пользователя своими словами без проверки по коду.
+- Не проверить по коду, реалистичны ли задачи.
+- Не добавить критерии готовности.
+- Не указать порядок и зависимости.
+- Не использовать транскрипцию, хотя она была предоставлена — упущен важный контекст (GDPR, приоритеты поддержки).