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

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

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

Принимает текст транскрипции дейлик-митинга и создаёт:
1. `raw.md` — исходный текст с frontmatter
2. `summary.md` — человекочитаемый протокол
3. `structured.json` — машиночитаемые структурированные данные
4. Запускает валидацию через `check_protocol.py`

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

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

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

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

Определи из текста или спроси у пользователя:
- `date` — дата встречи (YYYY-MM-DD). Если не указана — используй сегодняшнюю.
- `team` — название команды. ОБЯЗАТЕЛЬНО спроси, если в тексте нет явного указания команды. Не угадывай.
- `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` только как контекст:
- нормализуй имена участников (единое написание)
- учитывай роль/фокус при формулировке `topics` и `notes`
- проверяй, что `team` и `timezone` согласованы

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

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

Создай только директорию. НЕ используй `scripts/make_meeting.sh` — он генерирует
файлы-шаблоны, которые мешают записи финальных версий. Создавай директорию напрямую:

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

Файлы `raw.md`, `summary.md`, `structured.json` и `notes.md` создаются на следующих шагах.

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

Запиши файл через bash (`cat > путь <<'EOF' ... EOF`), а не через create_file,
чтобы гарантировать перезапись если файл уже существует.

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

```md
---
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:

```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 как эталон формата.

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

Запусти проверку протокола:

```bash
python3 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 и перезапусти.
Если есть предупреждения (WARNINGS) — сообщи пользователю, но не блокируй.

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

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

1. Путь к созданным файлам
2. Краткое резюме из summary (2–3 предложения)
3. Количество: участников, action items, блокеров, решений
4. Результат валидации (OK / warnings)

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

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

## Зависимости

- scripts/check_protocol.py — валидация
- schemas/daily_meeting.schema.json — JSON-схема
- examples/ — эталоны формата