follow-up

---
name: follow-up
description: |
  Перетворює транскрипцію зустрічі або дзвінка на стислий actionable follow-up за
  фреймворком ARCV+ (Actions, Responsible, Clearly, Verbs доконаного виду + окремі блоки
  Рішення та Відкриті питання). Перед стартом питає, який саме вихід потрібен: загальний
  follow-up, проблеми та рішення, задачі по виконавцях, повні технічні деталі, ретро (АПД),
  деталі по одній темі або повідомлення учаснику. Дати додає тільки якщо вони були реально проговорені на
  зустрічі; інакше дія йде без дедлайну. Вихід — чистий plain text без markdown-розмітки,
  готовий до вставки в будь-який месенджер, пошту чи Worksection.
  Тригери (укр): "транскрипт зустрічі", "транскрипція дзвінка", "follow-up", "фоллоу-ап",
  "підсумок зустрічі", "підсумок дзвінка", "actionable follow-up", "action items",
  "що домовились", "розшифровка зустрічі", "нотатки з дзвінка".
  Triggers (en): "meeting transcript", "call transcript", "follow-up", "action items",
  "meeting recap", "post-call summary", "what did we agree".
  НЕ викликати: коли просять дослівний протокол/стенограму, переклад транскрипції без
  структурування, коли текст не містить ознак зустрічі (немає рішень, домовленостей,
  дій), або коли просять написати листа, повідомлення чи нагадування без транскрипції —
  навіть якщо це називають словом follow-up. Слово «follow-up» у запиті саме по собі не
  є приводом: приводом є транскрипція або сирі нотатки з розмови.
---

# Actionable Follow-Up

Перетворює сирий текст зустрічі або дзвінка на стислий follow-up за фреймворком ARCV+:
**A**ctions, **R**esponsible, **C**learly, **V**erbs (доконаного виду), плюс окремі блоки
**Decisions** і **Open Questions**.

## Коли застосовувати

- Користувач прислав транскрипцію зустрічі/дзвінка і хоче з неї follow-up.
- Користувач пише: "зроби follow-up", "напиши підсумок зустрічі", "витягни action items",
  "що домовились", "make a follow-up from this".
- Користувач прислав сирі нотатки з розмови з клієнтом або командою.

НЕ застосовувати, якщо:
- Просять написати листа, повідомлення чи нагадування, а транскрипції немає. Слово
  «follow-up» у запиті — не привід; привід — текст розмови. (Якщо транскрипція є і
  потрібне повідомлення учаснику — це режим усередині скіла, а не окремий випадок.)
- Просять переклад транскрипції без структурування.
- Просять дослівний протокол / стенограму обговорення (це інше — там потрібен повний хід розмови).
- Текст не містить ознак зустрічі (немає домовленостей, рішень, задач).

## Мова виходу

- За замовчуванням — **українська**.
- Якщо користувач у запиті явно вказав іншу мову ("англійською", "in English", "по-русски",
  "польською" тощо) — використовуй цю мову для всього виходу, включно з назвами блоків
  (`## Decisions`, `## Действия`, тощо).
- Імена власні (учасники, компанії, продукти) не перекладай.

## Поріг за обсягом замість безумовного прогону через humanizer

Коли скіл дублює ядро іншого скіла всередині себе, **безумовна** вимога «прогнати
через той скіл» подвоює вартість без приросту якості на малих блоках: короткий
контекстний абзац на два речення нічого не виграє від повного проходу.

Поріг за обсягом дешевший за безумовне правило й прибирає вагання виконавця:
**до ~40 слів — застосовуй правила humanizer напряму; довше — повний прогін.**
Правило з порогом виконується, правило без порога обходиться.

## Як працювати

### Крок 0. Запитай формат перед стартом

Перш ніж щось генерувати, постав **одне** запитання через AskUserQuestion — який саме
вихід потрібен. Дозволь вибрати кілька варіантів (`multiSelect: true`), бо часто потрібен
і загальний follow-up, і окремий розбір. Якщо в середовищі немає AskUserQuestion — постав
те саме запитання звичайним текстом, пронумерованим списком, і дочекайся відповіді.

Чотири варіанти на кнопках, у цьому порядку:

1. **Загальний follow-up (рекомендовано)** — стислий ARCV+ за форматом нижче.
2. **Проблеми, рішення та очікування** — що болить, що запропонували, чого чекає клієнт.
3. **Задачі по виконавцях** — розгорнуті задачі конкретних людей з деталями «як саме».
4. **Технічні деталі повністю** — усі озвучені вимоги до коду/реалізації без скорочення.

Ще два режими кнопками не виносяться, але описані в розділі «Режими виходу» — користувач
викликає їх через «Other» або словами: **Ретро (АПД) за 4 блоками**,
**Деталі по одній темі або проєкту** і **Повідомлення учаснику зустрічі**.

Коли запитання НЕ ставити:

- Користувач сам назвав режим у виклику («детально», «тільки проблеми», «зроби ретро»,
  «залиш усі технічні деталі») — виконуй одразу, без питань.
- Це вже не перший запит у сесії: follow-up згенеровано, користувач просить розгортання —
  просто виконуй.

Якщо вибрано кілька режимів — видавай їх послідовно, кожен зі своїм заголовним рядком,
з порожнім рядком між ними. Правила формату (plain text, один власник, доконаний вид)
однакові для всіх режимів.

### Крок 1. Витягни вісім речей із транскрипції

Прочитай транскрипцію повністю один раз. Ідентифікуй:

1. **Тема зустрічі** — одна фраза.
2. **Дата зустрічі** — визначай по драбині джерел, зверху вниз, і зупиняйся на першому,
   яке спрацювало:
   1. Дата, явно названа в транскрипті.
   2. Дата з назви файлу запису або метаданих рекордера
      (`..._2026-08-14-10-24-29.txt` → 14 серпня 2026 року).
   3. Дата із заголовка чи посилання на запис (tldv тощо).
   4. Поточна дата — і тільки в цьому випадку допиши ` (припущення)`.

   Мітку ` (припущення)` ставити **виключно** для випадку 4. Якщо дата взята з файлу
   чи транскрипту — це факт, не припущення.

   Одразу після визначення дати з'ясуй **день тижня** цієї дати й рахуй від нього всі
   відносні терміни («до п'ятниці», «наступного тижня»). Хибна база дати тихо зсуває
   кожен дедлайн у блоці Дій. Виняток: якщо дата взята зі щабля 4, відносні терміни не
   конвертуються взагалі — див. правило дат у Кроці 2.
3. **Учасники** — усі, хто говорив або згаданий як присутній.

   **Спершу перевір атрибуцію лейблів, потім призначай ролі.** Лейбли спікерів у записі
   бувають переплутані між людьми — це трапляється, і саме тут скіл ламався: ролі
   виводяться з реплік, а репліки приписані не тим людям. Перевіряй по трьох сигналах:
   - **Самоідентифікація.** «What's your name?» → відповідь; «мене звати…»; «я з боку
     клієнта»; «я модерую». Якщо під лейблом `A` людина називає себе `B` — лейбли
     переплутані.
   - **Звірка з `references/roster.md`.** Якщо людина, записана в ростері як «наша
     команда», розповідає про власний бізнес і просить зробити їй сайт — це не вона.
   - **Логіка сторін.** Хто описує процес, команду і терміни — виконавець; хто описує
     свій бізнес і потребу — замовник.

   При виявленому конфлікті **довіряй змісту реплік, а не лейблу**, і додай у шапку
   окремим рядком після `Учасники:` (або після `Згадані:`, якщо він є):
   `Увага: у записі переплутані лейбли спікерів, ролі відновлено за змістом розмови.`
   Читач має знати, що звіряти із записом наосліп не можна.

   Далі для кожного учасника обов'язково фіксуй роль і сторону у форматі
   `Імʼя (роль, сторона)`, де сторона — наша команда,
   клієнт або підрядник:
   `Андрій Мельник (менеджер проєкту, наша команда)`, `John Smith (замовник, клієнт)`.
   - Якщо з транскрипту роль або сторона однозначно не випливає — пиши `[уточнити роль]`.
     Не добудовуй роль із порядку реплік: саме так замовник і менеджер міняються місцями,
     а дії йдуть не тим людям.
   - Перед тим як приписувати ролі, звірся з `references/roster.md` — там канонічні
     імена, ролі й сторони людей, які трапляються регулярно. Файл має пріоритет над
     здогадкою з транскрипту.
   - У «Учасниках» стоять **люди, не компанії**. Не `Northwind Beauty LLC (Віктор)`,
     а `Віктор (власник, клієнт — Northwind Beauty LLC)`.
4. **Згадані** — люди, які НЕ були на зустрічі, але з'являються нижче як виконавці задач
   або джерело інформації (наприклад, «асистентка Оксана налаштує скрипт»). Якщо таких немає —
   пропусти цей пункт.
5. **Контекст** — 1-2 речення, що пояснюють, навіщо ця зустріч і про що загалом мова.
   Це не переказ ходу обговорення, а **орієнтир для людини, яка не була присутня**.
   Якщо тема в `Зустріч:` вже самодостатня («1:1 з Іваном», «Standup команди») —
   пропусти цей пункт.
6. **Рішення** — що ухвалили як **правило / умову на майбутнє** (без виконавця і дати).
7. **Дії** — конкретні задачі, які хтось має виконати.
8. **Відкриті питання** — не вирішено, потребує даних, відкладено, потребує інших людей.

### Крок 2. Сформулюй кожну дію за формулою

```
[Власник] [дієслово доконаного виду] [що саме][, до конкретна дата]. — [why, якщо неочевидно]
```

Частина `до конкретна дата` — **опціональна**. Деталі нижче.

Правила:

- **Власник = одна людина.** Не "команда", не "ми", не "хтось". Якщо в транскрипції
  не призначено — постав того, хто веде зустріч (PM/секретар) і додай `[уточнити власника]`.
- **Дієслово доконаного виду.** "Підготує", "надішле", "опублікує", "погодить", "перевірить".
  НЕ "робити", "обговорювати", "дивитись", "займатись".
- **Дата — тільки якщо вона була реально проговорена на зустрічі.** Це жорстке правило:
  - Якщо в транскрипції згадано дату (явну на кшталт «до 15 травня» або відносну
    «до п'ятниці», «наступного тижня», «до кінця місяця») — переведи у людський формат
    відповідної мови, рахуючи від дати зустрічі:
    - Українська: `22 травня 2026 року`
    - Російська: `22 мая 2026 года`
    - Англійська: `22 May 2026`
    - Польська: `22 maja 2026`
    - Інші — аналогічно місцевій нормі написання дат.
  - Якщо в обговоренні про термін **взагалі не йшлося** — **просто завершуй формулювання
    дії крапкою. Не ставити плейсхолдер, не вигадувати дату, не писати «коли буде час»
    тощо.** Користувач сам додасть дату, коли вона з'явиться.
  - «ASAP», «найближчим часом», «до кінця тижня» без конкретики **не вважати датою** —
    це не дедлайн, а фігура мови. Дія йде без дати.
  - **Відносний термін не конвертується, якщо сама дата зустрічі — припущення.** Коли
    дата взята зі щабля 4 драбини (поточна дата з міткою `(припущення)`), «до п'ятниці»
    або «сьогодні-завтра» в конкретну дату **не переводиться**: інакше здогадка отримує
    вигляд точної дати. Дія йде без дати, а сам термін, якщо він важливий, іде в
    «Відкриті питання» словами зустрічі («обіцяв сьогодні або завтра вранці —
    уточнити дату»). Конвертація дозволена тільки для щаблів 1-3.
- **Why-tail (опціонально).** Після основного формулювання можеш додати через ` — `
  коротку причину, якщо без неї пункт виглядає випадковим або залежить від іншої дії.
  Якщо і так зрозуміло — не дописуй.
- **Спостережуваний результат.** Якщо дія може бути двояко зрозуміла ("розібратися",
  "подумати") — переформулюй у виробничий артефакт ("надішле звіт у Slack",
  "опублікує draft у Notion", "отримає підпис на договорі").

### Крок 3. Розклади за блоками й нічого не змішуй

- **Рішення ≠ Дії.** Рішення — це правило, що діє далі ("Платіж розбиваємо на 3 транші",
  "Кінцевий дедлайн релізу — 30 червня"). Дія — це разова задача з власником і датою.
- **Відкриті питання ≠ Дії.** Якщо відомо хто і коли шукає відповідь — це дія.
  Якщо ні — відкрите питання.
- **Один пункт — одна дія.** Якщо в реченні транскрипції два дієслова з різними
  результатами — розбий на два пронумерованих пункти.

### Крок 4. Збери follow-up у форматі нижче

## Формат виходу

Вихід — **чистий plain text без жодної markdown-розмітки**. Жодних `**`, `##`, `*`, `_`,
зворотних лапок, посилань у форматі `[текст](url)`, таблиць, code-блоків, емодзі,
банерів, горизонтальних ліній (`---`, `___`, `***`).

**Це контракт на всю сесію, а не на один артефакт.** Заборона розмітки діє на кожну
наступну відповідь у цій розмові — розгортання деталей, розбір проблем, ретро, витяг
задач, супровідне повідомлення клієнту — поки користувач явно не попросить інше.
Найчастіший збій цього скіла: перший follow-up чистий, а вже друга відповідь виходить
із заголовками і жирним, і користувач вичищає її руками. Текст має виглядати ідентично у Telegram (standard клієнт),
Gmail, Outlook, Slack, Worksection, Notion, при копіюванні у будь-який інший редактор.

Структура:

- Шапка: `Зустріч:`, `Дата:`, `Учасники:` (обов'язково, кожен з роллю і стороною),
  плюс `Згадані:` (якщо є) і рядок `Увага:` про переплутані лейбли (якщо їх виявлено).
  Кожен
  з нового рядка.
- Порожній рядок.
- Блок `Контекст:` — 1-2 речення прозою, без буллетів і списків. Пропускається, якщо
  тема самодостатня.
- Порожній рядок.
- Назва кожного наступного блоку (`Рішення:`, `Дії:`, `По виконавцях:`, `Відкриті питання:`)
  — окремим рядком.
- Порожній рядок після назви блоку.
- Список пунктів.
- Дії — нумерований список (`1.`, `2.`, ...). Нумерація суцільна по всьому списку.
- Рішення, відкриті питання, рядки в «По виконавцях» — буллети з тире на початку рядка (`— `).
- **Порожній рядок між кожним пунктом списку**, а не тільки між блоками. Інакше у
  месенджерах і пошті пункти зливаються у суцільну стіну тексту й список стає
  нечитабельним. Це стосується і нумерованих Дій, і всіх буллетних списків.
- Порожній рядок між блоками.

**Нормалізація імен.** Транскрипція машинна й шумна, тому імена в ній псуються.

- Спелінг імені бери зі спікер-лейблів («Petro Koval [00:00]:»), а не з тіла реплік —
  у репліках ASR калічить імена найчастіше («Оксан» замість «Оксана», «Петр» замість «Петро»).
  Лейбл дає **спелінг, а не гарантію**, кому належить репліка: перевірку атрибуції
  роби за Кроком 1, до того як приписувати ролі й дії.
- Одна людина — **одна форма запису** в усьому документі, в алфавіті мови виходу.
  У follow-up українською не змішуй `Petro Koval` і `Петро Коваль`: обери кириличну
  форму й тримай її скрізь, включно з блоком «По виконавцях» і всіма розгортаннями.
- Якщо в системі є `references/roster.md` — канонічні форми імен, ролі й сторони
  бери звідти, а транскрипт використовуй лише для тих, кого в файлі немає.

**Правило для блоку Контекст.** Максимум 2 речення, максимум ~40 слів сумарно. Без
буллетів, нумерації, заголовків, переліків. Пише, **навіщо** зібрались і **про що**
загалом мова. Не повторює дій і рішень. Якщо немає чого додати поверх теми — повністю
пропусти блок.

**Блок «По виконавцях».** Після блоку «Дії» додай мінідайджест: кожен власник + номери
його пунктів через кому. Це дозволяє людині швидко знайти «свої» задачі, не перечитуючи
весь список.

- Включай цей блок **лише якщо у Діях 2 або більше унікальних виконавців**. Якщо власник
  один — пропусти, він нічого не додає.
- Сортуй за **спадаючою кількістю задач** (хто має найбільше — зверху). Якщо однакова
  кількість — за порядком першої появи в списку Дій.
- Якщо одна дія має кількох співвиконавців — особа з'являється у кількох рядках із цим
  номером.
- Якщо є дія з `[уточнити власника]` — додай окремий рядок `— Без власника: <номери>`
  останнім.

Шаблон:

```
Зустріч: <тема одним рядком>
Дата: <DD місяць YYYY року> у локалі мови виходу
Учасники: Імʼя1 (роль, сторона), Імʼя2 (роль, сторона), Імʼя3 (роль, сторона)
Згадані: ІмʼяX (роль), ІмʼяY (роль)

Контекст:

<1-2 речення про мету зустрічі і загальне коло обговорених тем>

Рішення:

— <рішення 1>

— <рішення 2>

Дії:

1. <Власник> <дієслово доконаного виду> <що саме> до <конкретна дата>. — <why, якщо потрібно>

2. <Власник> <дієслово доконаного виду> <що саме>. — <why, якщо потрібно>   ← без дати, якщо її не обговорювали

По виконавцях:

— Імʼя1: 1, 3, 5

— Імʼя2: 2, 4

— Імʼя3: 6

Відкриті питання:

— <питання 1>

— <питання 2 — хто шукає відповідь і до коли, якщо вже відомо>
```

Якщо якогось блоку немає в транскрипції (наприклад, не було рішень) — пропусти блок
повністю, не лишай назву з порожнечею.

**Самоперевірка перед видачею (обов'язкова, кожного разу).** Перечитай згенерований
текст і перевір по пунктах:

1. Назви шапки й блоків набрані правильно, без латинських гомогліфів у кириличних
   словах (`Zустріч:` замість `Зустріч:` — реальний баг цього скіла; так само
   небезпечні `C`, `P`, `X`, `A`, `E`, `O`, `I`).
2. Кожне імʼя записане однією й тією ж формою в усьому тексті.
3. Кожен учасник у шапці має роль і сторону; жодна компанія не стоїть замість людини.
4. Нумерація Дій суцільна, без пропусків і повторів.
5. Номери в «По виконавцях» усі існують у блоці Дій, і жоден пункт Дій не загубився.
6. Жодної markdown-розмітки, включно з `---` і зворотними лапками.
7. Дати або взяті з джерела, або їх немає — вигаданих і «найближчим часом» немає.
8. Перше речення кожного прозового блоку — це факт, а не шаблонний зачин
   («Загалом зустріч була присвячена…», «Важливо зазначити, що…»). Стоп-список —
   у розділі «Стиль формулювань».
9. Зіпсовані транскрибацією місця, які впливають на пункти, винесені окремим блоком
   питань після виходу, а не розвʼязані здогадкою всередині тексту.

Назви блоків і шапки перекладай разом з рештою тексту, коли користувач задав іншу мову виходу:

- Англійська: `Meeting:`, `Date:`, `Attendees:`, `Mentioned:`, `Note:`, `Context:`, `Decisions:`, `Action items:`, `By owner:`, `Open questions:`
- Російська: `Встреча:`, `Дата:`, `Участники:`, `Упомянуты:`, `Внимание:`, `Контекст:`, `Решения:`, `Действия:`, `По исполнителям:`, `Открытые вопросы:`
- Польська: `Spotkanie:`, `Data:`, `Uczestnicy:`, `Wspomniani:`, `Uwaga:`, `Kontekst:`, `Decyzje:`, `Działania:`, `Wg odpowiedzialnych:`, `Pytania otwarte:`

## Сумнівні місця

Транскрипція машинна, частина слів у ній зіпсована, і деякі з цих слів несуть зміст:
назва документа, сума, імʼя, термін. Добудувати таке слово мовчки означає видати
здогадку за домовленість.

Правило: сумнів не потрапляє в сам follow-up і не зникає. Він виноситься **окремим
блоком після виходу**, у чат, а не всередину артефакта. Артефакт іде команді або
клієнту, питання в ньому недоречні.

Що робити з дією, яка спирається на зіпсоване місце:

- сформулюй її на тому, що чути напевно, а невідоме познач `[уточнити …]`;
- не заміняй незрозуміле слово правдоподібним синонімом, навіть якщо він добре лягає
  в контекст сусідніх реплік.

Формат блоку після виходу. На кожен сумнів один пункт із трьох частин: цитата з
таймкодом, як вона звучить у транскрипті; як ти її прочитав; питання, на яке можна
відповісти «так» або «ні».

```
Сумнівні місця:

1. 13:33, Тетяна: «щоб він підготував ще Ліна чекає». Прочитав як чекліст вимог від маркетолога. Чи так?
```

Виноси лише те, що змінює зміст пункту: дію, власника, дату, суму, назву. Дрібні
спотворення, які не впливають на жоден пункт, ігноруй — блок із двадцяти питань ніхто
не читає.

Це саме стосується сумнівів у застосуванні правил скіла: якщо не зрозуміло, куди
покласти пункт або чи вважати щось рішенням, постав питання тут, а не приймай рішення
мовчки.

## Стиль формулювань

Структурні правила вище знімають розмітку й порожні дієслова, але не лексику. Слоп у цьому
скілі заходить через прозові блоки — Контекст, Проблеми та рішення, Ретро, Деталі по темі,
повідомлення учаснику. Для них діють правила нижче.

**Головне правило: пиши словами зустрічі.** Якщо на дзвінку сказали «прокладинка до
Amazon» — так і пиши, не заміняй на «проміжний майданчик для трафіку». Синонім, якого не
було в розмові, майже завжди довший і слабший за оригінал, а ще й непомітно змінює зміст.

**Follow-up фіксує, а не коментує.** Без оцінок і емоцій: «на жаль», «чудова ідея»,
«цікаво, що», «варто похвалити». Якщо оцінку озвучили на зустрічі — це цитата учасника,
і тоді видно, хто її дав.

### Стоп-список, українська

Ліворуч — викидаємо або замінюємо, праворуч — чим:

- «наразі», «на даний момент» → «зараз», або нічим
- «важливо зазначити, що», «варто відзначити», «слід підкреслити» → видалити, одразу факт
- «даний», «вищезазначений», «вищевказаний» → «цей»
- «з метою» → «щоб»
- «в рамках проєкту / зустрічі» → «на проєкті», «на зустрічі»
- «здійснити», «провести роботи з», «забезпечити виконання» → конкретне дієслово: «налаштує», «надішле», «перевірить»
- «оптимізувати процеси», «покращити взаємодію», «підвищити ефективність» → що саме зміниться і де це буде видно
- «комплексний підхід», «глибока експертиза», «прозора комунікація», «синергія» → маркетингові штампи, у follow-up не місце
- «є важливим», «є необхідним» → «важливо», «треба»
- «Отже, підсумовуючи», «Давайте розглянемо», «Як ми бачимо» → метатекст, видалити

Конструкції, яких не має бути:

- Трійки через кому заради ритму («швидко, якісно і прозоро») — лишай те, що справді сказали.
- «Не просто X, а Y» — підсилювач без інформації.
- Риторичне питання як зачин абзацу.
- Абзац, що починається з узагальнення («Загалом зустріч показала, що…») замість факту.

### Стоп-список, англійська (для повідомлень клієнту)

- "I hope this message finds you well", "Just wanted to reach out / circle back / touch base" → одразу до справи: "I'm writing about X"
- "leverage", "utilize", "facilitate", "streamline", "robust", "seamless", "cutting-edge", "holistic" → прості дієслова й прикметники
- "It's worth noting that", "It's important to highlight" → видалити
- "delve into", "in today's fast-paced world", "the landscape of" → видалити
- "Looking forward to hearing from you!" + "Let me know if you have any questions!" разом → максимум одна закривна фраза, краще жодної
- "not just X, but Y" → сказати прямо

### Прогін через humanizer

Перед видачею прозові блоки проганяй через скіл `humanizer` (або
`anthropic-skills:stop-slop`). Це стосується Контексту, режимів «Проблеми, рішення та
очікування», «Ретро (АПД)», «Деталі по одній темі» і «Повідомлення учаснику зустрічі».

Нумеровані Дії через humanizer **не** проганяй: вони формульні за задумом
(`[Власник] [дієслово доконаного виду] [що саме]`), і переписування тільки розмиє формулу.

## Режими виходу

Загальний follow-up описаний вище — це дефолт. Нижче — решта режимів із Кроку 0. Усі вони
підпорядковані тим самим правилам: чистий plain text, один власник на дію, дієслова
доконаного виду, дата тільки якщо її проговорили, порожній рядок між пунктами.

### Проблеми, рішення та очікування

Для кожної проблеми — окремий пронумерований пункт із трьох частин у трьох рядках:

```
Проблеми та рішення:

1. Проблема: <що саме не працює або болить, словами зустрічі>.
   Причина: <якщо на зустрічі назвали причину; якщо ні — рядок пропускається>.
   Рішення: <що запропонували і хто запропонував; якщо рішення не знайшли — «не знайшли на зустрічі»>.

Очікування клієнта:

— <чого клієнт чекає від співпраці / результату>
```

Не змішуй проблему з рішенням в одне речення і не вигадуй рішення, якого не озвучили.

### Задачі по виконавцях

Розгорнутий варіант блоку Дій для однієї людини або для всіх. На кожну задачу:

```
Задачі для <Імʼя>:

1. <Що зробить — дієслово доконаного виду, спостережуваний результат>.
   Як саме: <кроки або вимоги так, як їх проговорили на зустрічі>.
   Результат: <що має бути видно на виході — файл, повідомлення, доступ, документ>.
   Дедлайн: <дата, якщо проговорили; рядок пропускається, якщо ні>.
```

Формулювання лишається таким, щоб пункт можна було скопіювати прямо в трекер.

### Технічні деталі повністю

Режим для інженерних зустрічей — рев'ю верстки, розбір архітектури, вимоги до коду.
Технічні формулювання **не скорочуються**: тут цінність саме в деталях.

- Групуй за темами (кнопки, заголовки, відступи, скрипти), кожна тема — окремий
  заголовний рядок із двокрапкою.
- Кожна вимога — окремий буллет: що робити, як робити, і чому саме так, якщо причину
  озвучили на зустрічі.
- Конкретику (класи, теги, розміри, назви властивостей, значення) переноси дослівно.
- Блок Дій із власниками все одно додається в кінці — деталі не заміняють задачі.

### Ретро (АПД) за 4 блоками

Чотири блоки, кожен — заголовний рядок із двокрапкою, всередині нумеровані пункти:

```
1. Що було заплановано:
2. Що насправді відбулося:
3. Чому так сталося:
4. Що зробити по-іншому наступного разу:
```

Четвертий блок пиши так, щоб кожен пункт можна було винести в окрему задачу з власником.
У блоці «Чому так сталося» спирайся тільки на причини, названі на зустрічі; якщо причину
не назвали — так і пиши, замість власної гіпотези.

### Повідомлення учаснику зустрічі

Короткий текст у чат або пошту за домовленостями з follow-up — коли треба зрушити
наступний крок, а не переслати підсумок.

- Мова — **мова адресата**, не мова follow-up. Якщо зустріч була українською, а адресат
  англомовний — пиши англійською.
- Обсяг — до 120 слів. Одне повідомлення, не лист на три абзаци.
- Структура: одне речення контексту (на що посилаємось) → що вже зроблено або надіслано →
  одне конкретне питання чи наступний крок із домовленостей.
- Без «hope you're doing well», без підпису, без двох закривних фраз поспіль.
- Питай про те, що справді лишилось відкритим за транскриптом, а не «чи є питання».
- Обов'язковий прогін через `humanizer` і стоп-список англійської вище.

### Деталі по одній темі або проєкту

Розгорнутий переказ однієї теми зі зустрічі для людини, якої там не було. Підблоки —
заголовним рядком із двокрапкою (`Бекграунд клієнта:`, `Що вже зроблено:`,
`Що хоче клієнт:`, `Ризики:`). Проза, без markdown. Не переказуй хід розмови по черзі
реплік — збирай за темами.

## Приклад

**Вхід (фрагмент транскрипції, дата зустрічі — 2026-05-12, понеділок):**

> Олексій: Окей, по презентації — я її зроблю до п'ятниці.
> Марина: А кому показуємо?
> Олексій: Acme спочатку. Сергію, ти будеш на дзвінку?
> Сергій: Так, я модерую. До речі, чи ми вже визначились із ціною?
> Олексій: Залишаємо $5000 на місяць, як домовлялись минулого разу. Стоп — а Марина встигне до п'ятниці зі своїм блоком?
> Марина: Якщо буде бриф, то так. Сьогодні чекаю.

**Вихід:**

```
Зустріч: Підготовка презентації для Acme
Дата: 12 травня 2026 року
Учасники: Олексій (акаунт-менеджер, наша команда), Марина (дизайнер, наша команда), Сергій (керівник, наша команда)

Рішення:

— Ціна для Acme — $5000 на місяць.

Дії:

1. Олексій надішле Марині бриф для її блоку презентації до 12 травня 2026 року. — Без брифу Марина не встигне до п'ятниці.

2. Марина підготує свій блок презентації до 15 травня 2026 року. — Залежить від брифу від Олексія.

3. Олексій збере фінальну презентацію для Acme до 15 травня 2026 року.

4. Сергій модеруватиме дзвінок з Acme.

По виконавцях:

— Олексій: 1, 3

— Марина: 2

— Сергій: 4

Відкриті питання:

— Дата дзвінка з Acme — [уточнити власника й дедлайн].
```

## Що НЕ робити

- **Не переказуй обговорення narrative-стилем** ("Спочатку поговорили про…, потім
  перейшли до…"). Це протокол, не follow-up.
- **Не залишай дії без власника.** Якщо власник невідомий — постав PM/секретаря і
  познач `[уточнити власника]`.
- **Не використовуй дієслова недоконаного виду** ("робити", "обговорювати", "дивитись",
  "займатись"). Переформулюй у "зробить", "обговорить з X", "перевірить", "візьме у роботу".
- **Не вигадуй дедлайн, якщо його не було в обговоренні.** Якщо на зустрічі не сказали,
  до коли дія має бути виконана — просто пиши дію без дати. Не ставити `[уточнити дедлайн]`,
  не писати «найближчим часом», не додавати дату «логічно». Користувач сам поставить, коли
  буде ясно.
- **Не пиши "ASAP", "найближчим часом", "до кінця тижня"** як дату. Якщо ж справжня
  конкретна дата була проговорена — пиши її у локалі мови виходу (`22 травня 2026 року`,
  не `2026-05-22`, не `22.05.2026`).
- **Не змішуй рішення з діями** в один список. Це різні сутності.
- **Не вигадуй пункти**, яких немає в транскрипції. Якщо чогось бракує — постав
  `[уточнити …]` замість того, щоб домалювати.
- **Не використовуй жодної markdown-розмітки** — `**bold**`, `## headers`, `*italic*`,
  `_underline_`, зворотних лапок, посилань `[text](url)`, таблиць, code-блоків, емодзі,
  H1-заголовків, горизонтальних ліній (`---`, `___`, `***`). І в першій відповіді, і в
  усіх наступних у цій сесії. У Gmail, Worksection, стандартному Telegram-клієнті
  і Outlook ці символи рендеряться буквально й користувачу доведеться їх вичищати руками.
- **Не змінюй мову виходу**, якщо користувач не попросив явно.
- **Не приймай лейбли спікерів на віру.** Якщо під лейблом однієї людини звучать
  репліки іншої — довіряй змісту, а не підпису, і познач це в шапці. Перевірка описана
  в Кроці 1.
- **Не рахуй дедлайни від припущеної дати.** Якщо дата зустрічі стоїть з міткою
  `(припущення)`, відносні терміни лишаються неконвертованими.
- **Не здогадуйся про роль і сторону учасника.** Якщо з транскрипту не видно, хто
  замовник, а хто менеджер проєкту — став `[уточнити роль]`. Помилка тут розкидає дії
  по неправильних людях, і весь follow-up доводиться переписувати.
- **Не пиши штампами й канцеляритом** («наразі», «в рамках проєкту», «здійснити»,
  «комплексний підхід», «важливо зазначити, що»). Стоп-список і заміни — у розділі
  «Стиль формулювань»; прозові блоки перед видачею проганяй через `humanizer`.
- **Не добудовуй зіпсоване транскрибацією слово** правдоподібним синонімом. Формулюй
  пункт на тому, що чути напевно, а сумнів винось окремим блоком питань після виходу —
  див. «Сумнівні місця».
- **Не пиши закриваючі люб'язності** ("Дякую за зустріч, чекаю підтвердження!"). Якщо
  потрібен супровідний текст — користувач допише сам.