process-daily

name: process-daily description: > Обработка транскрипции дейлик-митинга: извлечение структурированных данных, генерация summary и валидация протокола. Используй этот скилл когда пользователь скидывает текст транскрипции дейлика, стендапа или daily standup, просит обработать запись встречи, или говорит что-то вроде "вот транскрипция", "обработай дейлик", "вот запись встречи", "daily за сегодня". Также используй, если пользователь упоминает raw.md или просит сгенерировать summary/structured.json из текста встречи.

Process Daily — обработка транскрипции дейлика

Что делает скилл

Принимает текст транскрипции дейлик-митинга и создаёт:

raw.md — исходный текст с frontmatter
summary.md — человекочитаемый протокол
structured.json — машиночитаемые структурированные данные
Сверяет открытые поручения прошлых дейликов (обновляет их статусы)
Запускает валидацию через check_protocol.py

Входные данные

Пользователь скидывает текст транскрипции в чат. Текст может быть:

Чистой транскрипцией (с таймкодами или без)
Уже с frontmatter (meeting_id, date, timezone, team)
Без метаданных — тогда извлеки дату, команду и участников из контекста

Пошаговый процесс

Шаг 1: Извлечь метаданные

Определи из текста или спроси у пользователя:

date — дата встречи (YYYY-MM-DD). Если даты нет ни в тексте, ни в сообщении пользователя — СПРОСИ. Не подставляй сегодняшнюю: транскрипции часто обрабатывают на следующий день. Если пользователь явно сказал «за сегодня» — используй сегодняшнюю.
team — название команды. ОБЯЗАТЕЛЬНО спроси, если в тексте нет явного указания команды. Не угадывай.
timezone — из teams/<team>/team.yaml → timezone; если файла нет — Europe/Moscow.
meeting_id — формат YYYY-MM-DD-team-name.

Шаг 1.1: Подтянуть team context из `team.yaml`

Если команда известна, обязательно прочитай teams/<team>/team.yaml перед генерацией summary/structured.json.

Используй team.yaml только как контекст:

нормализуй имена участников к написанию из members[*].name («Ваня» → «Иван»). Альтернативные написания, встречающиеся в транскрипциях, стоит фиксировать в members[*].aliases — их учитывает check_protocol.py при сверке участников с raw.md
учитывай роль/фокус при формулировке topics и notes
проверяй, что team и timezone согласованы

Ограничения:

не подставляй факты о ходе встречи из team.yaml
participants, done/todo/blockers/decisions — только из raw.md
если team.yaml отсутствует, продолжай обработку и отметь это в отчёте пользователю

Также считай Jira-конфиг из team.yaml → jira:

project_prefix — константа префикса проекта (например TASK). Понадобится в Шаге 5.5.

Подключение к Jira (хост, токен) настраивается в MCP-клиенте, в team.yaml его нет. Если секции jira нет, запомни это: в Шаге 5.5 нужно будет спросить префикс у пользователя.

Шаг 2: Создать структуру каталогов

mkdir -p meetings/YYYY/MM/YYYY-MM-DD-team-name

Если каталог уже существует и в нём есть raw.md или structured.json — эта встреча уже обрабатывалась. Покажи пользователю, что там лежит, и спроси подтверждение перед перезаписью. Молча не перезаписывай.

Файлы raw.md, summary.md, structured.json создаются на следующих шагах, notes.md — только при необходимости (Шаг 6.5).

Шаг 3: Записать raw.md

Запиши файл штатным инструментом записи файлов (Write) — он создаёт файл и перезаписывает существующий. Не используй bash-heredoc (cat <<EOF): он ломается, если в транскрипции встретится служебная строка.

Сохрани исходный текст транскрипции в raw.md с frontmatter:

---
meeting_id: YYYY-MM-DD-team-name
date: YYYY-MM-DD
timezone: Europe/Moscow
team: team-name
---

[текст транскрипции как есть]

Шаг 4: Сгенерировать summary.md

Прочитай raw.md и создай summary по шаблону. Правила:

Только подтверждённые факты из raw.md
Не выдумывать и не додумывать
Краткий стиль, без воды
Ориентируйся на examples/meeting_full/summary.md как эталон
Если по секции данных нет — пиши «- нет», не придумывай содержимое

Шаблон summary.md:

---
meeting_id: {meeting_id}
date: {date}
timezone: {timezone}
team: {team}
---

# Daily — {date}

## Краткое резюме
2–4 предложения: что обсуждали, ключевые решения, блокеры.

## Что сделали
- Кто: что конкретно сделал (номер задачи/PR если есть)

## Что планируют
- Кто: что берёт на сегодня

## Блокеры
- Описание блокера (у кого)

## Решения
- Конкретное решение

## Поручения
- Кто: что делает, до когда

## Оффтоп
- Что обсуждали вне рабочей повестки

Шаг 5: Сгенерировать structured.json

Создай JSON строго по схеме schemas/daily_meeting.schema.json.

Ключевые правила:

participants — только те, кто реально говорил на встрече. Если человек упомянут как исполнитель action item, но не присутствовал — не включай.

updates — по одному объекту на каждого участника:

done — что сделал (конкретные результаты)
todo — что планирует сегодня
blockers — только реальные препятствия работе
notes — дополнительный контекст (WIP-нарушения, парковка и т.д.)

decisions — только явно принятые решения, подтверждённые в raw.md.

action_items — добавляй только если:

Понятно что делать (конкретная задача)
Поручение реально дано на встрече (не выводи его сам из блокера)
Есть владелец (owner) — если по имени не назначен, ставь null. Не приписывай владельца по догадке («наверное, это сделает тимлид»)
status: всегда "open" для новых
due_date: если озвучен дедлайн — ставь дату, иначе null

topics — ключевые темы обсуждения (3–7 слов-тегов).

offtopic — всё что не относится к рабочей повестке.

Ориентируйся на examples/meeting_full/structured.json как эталон формата.

Шаг 5.5: Собрать данные по обсуждаемым задачам из Jira (MCP)

Цель — обогатить отчёт фактическим состоянием задач из трекера, а не только тем, что прозвучало на словах. Заполняется поле jira_issues в structured.json.

Инструменты Jira-MCP ищи среди доступных MCP-инструментов: имена зависят от конфигурации сервера (например mcp__atlassian__jira_get_issue, mcp__Atlassian__getJiraIssue и т.п.) — нужен инструмент получения задачи по ключу. Если Jira-MCP недоступен — пропусти этот шаг, оставь jira_issues: [] и отметь это в отчёте пользователю. Не выдумывай данные.

5.5.1 Найти упоминания задач в `raw.md`

Собери ВСЕ упоминания задач из текста транскрипции. Два формата:

полный ключ: TASK-103, BILL-45 (буквенный префикс + дефис + число);
одно число без префикса: «закрыл 103», «взял 110», «по 88».

Не путай с номерами, которые задачами не являются: PR #88, даты, версии 1.2, проценты, тайм-коды. Если сомневаешься — лучше не включай.

5.5.2 Нормализовать в ключ Jira

Если упоминание уже содержит префикс (BILL-45) — бери ключ как есть.
Если назван только номер — подставь константу project_prefix из team.yaml → jira (например 103 → TASK-103).
Если в team.yaml нет jira.project_prefix и префикс нигде не обсуждали — один раз спроси префикс у пользователя. Не угадывай.

В mentioned_as сохрани исходную форму упоминания ("103" или "TASK-103"), в key — нормализованный ключ.

5.5.3 Подтянуть данные по каждому уникальному ключу

Для каждого уникального ключа вызови инструмент получения задачи. Из ответа возьми:

summary — заголовок задачи;
status — текущий статус;
assignee — исполнитель (имя/displayName, иначе null).

Если задача не найдена или вызов упал — добавь запись с известным key, остальные поля поставь null. Не блокируй обработку из-за одной задачи.

5.5.4 Записать в `jira_issues`

Добавь массив объектов в structured.json (см. эталон examples/meeting_full/structured.json):

"jira_issues": [
  {
    "key": "TASK-103",
    "summary": "Форма отчётов: фильтр по дате",
    "status": "In Review",
    "assignee": "Мария",
    "mentioned_as": "TASK-103"
  }
]

Дедуплицируй по key. jira_issues — справочный снимок состояния задач; он не заменяет done/todo/blockers (те по-прежнему строятся только из raw.md).

Шаг 5.7: Сверить открытые поручения прошлых дейликов

Статусы action items живут в structured.json того митинга, где поручение появилось. Без сверки они навсегда остаются open, и отчёты показывают ложную картину («у всех 0% исполняемости»).

Собери открытые поручения прошлых митингов: запусти scripts/prepare_daily.py --team <team> --date <дата встречи> (секция «Открытые поручения») или просмотри action_items в structured.json последних митингов.
Если из нового raw.md следует, что поручение выполнено или отменено (например, в done участника назван результат этого поручения, или на встрече сказали «уже не нужно») — обнови поле status (done / dropped) в structured.json ИСХОДНОГО митинга.
Меняй только status. Текст поручения, owner, due_date и raw.md не трогай.
Если уверенности нет — оставь open и упомяни сомнение в отчёте пользователю.

Шаг 6: Валидация

Запусти проверку протокола (через uv, если проект им управляется; иначе python3 ...):

uv run python scripts/check_protocol.py \
 --structured meetings/YYYY/MM/YYYY-MM-DD-team-name/structured.json \
 --raw meetings/YYYY/MM/YYYY-MM-DD-team-name/raw.md

Если есть ошибки (ERRORS) о содержимом structured.json — исправь файл и перезапусти. Не более 2–3 попыток: если ошибка повторяется или касается не данных, а окружения/схемы — остановись и сообщи пользователю.
Если есть предупреждения (WARNINGS) — сообщи пользователю, но не блокируй.

Шаг 6.5: notes.md (только при необходимости)

Если в raw.md есть явные противоречия, неоднозначности или вещи, требующие ручного внимания тимлида — создай notes.md в каталоге встречи и перечисли их. Если таких нет — файл не создавай.

Шаг 7: Отчёт пользователю

После успешной обработки выведи:

Путь к созданным файлам
Краткое резюме из summary (2–3 предложения)
Количество: участников, action items, блокеров, решений, задач Jira
Обновлённые статусы прошлых поручений (Шаг 5.7), если были
Результат валидации (OK / warnings)
Если Jira-MCP был недоступен или какие-то задачи не нашлись — отметь это

Обработка ошибок

Если текст не похож на транскрипцию дейлика — скажи об этом, не обрабатывай.
Если не удаётся определить команду или дату — спроси.
Если raw.md содержит явные противоречия — отметь в notes.md (Шаг 6.5).

Зависимости

scripts/check_protocol.py — валидация
scripts/prepare_daily.py — список открытых поручений для сверки (Шаг 5.7)
schemas/daily_meeting.schema.json — JSON-схема
examples/ — эталоны формата
Jira-MCP (инструмент получения задачи по ключу) — обогащение задач, Шаг 5.5
team.yaml → jira.project_prefix — константа префикса проекта