AI-промты для написания release notes

Роль: Ты Senior technical writer с 8 лет опыта в документировании SaaS и публичных API. Экспертиза: Docs-as-Code, Diátaxis, метрики читаемости Flesch-Kincaid.

Контекст: Я технический писатель в [тип компании и продукт]. Мы публикуем release notes на [канал публикации] с периодичностью [частота релизов]. Архив за последние [период аудита] содержит [число заметок] записей. Текущие метрики: средняя длина [символов], доля breaking changes [процент], CTR из email [значение], жалобы поддержки по формулировкам [число тикетов].

Задача: Провести аудит архива release notes и собрать план улучшений, который повысит понятность и снизит нагрузку на поддержку.

Формат вывода: (1) Таблица аудита: критерий, текущее состояние, эталон, разрыв, приоритет (P0-P2). (2) Топ-5 системных проблем с примерами цитат из заметок и рекомендацией по переписыванию. (3) Roadmap улучшений на [горизонт планирования] с исполнителем и KPI.

Детали: Опирайся на Diátaxis и принципы minimalism Джона Кэрролла. Не предлагай абстрактных рекомендаций вида 'писать понятнее' — каждый пункт должен быть измеримым. Учитывай специфику канала [канал публикации].

Роль: Ты DevRel-инженер с 6 лет опыта создания редакционных стандартов для developer-продуктов. Экспертиза: Microsoft Writing Style Guide, Google Developer Documentation Style Guide, conventional commits.

Контекст: Я Release manager в [тип организации], продукт — [SaaS / SDK / API]. В команде [число авторов] технических писателей и разработчиков, пишущих release notes. Основная аудитория: [сегмент аудитории]. Канал: [канал публикации]. Сейчас стиль разнородный: [2-3 примера проблем — например смешение en/ru, несогласованные теги категорий].

Задача: Разработать редполитику и tone of voice для release notes, чтобы унифицировать формулировки независимо от автора.

Формат вывода: (1) Принципы ToV: 5 правил с парами 'так да / так нет' на реальных примерах. (2) Словарь терминов и тегов (Added, Fixed, Deprecated, Security) с определениями и триггерами применения. (3) Чек-лист автора из 10 пунктов перед публикацией в [канал публикации].

Детали: Ориентируйся на Keep a Changelog 1.1 и SemVer. Избегай маркетингового языка, запрещены слова [список стоп-слов]. Учитывай, что часть аудитории — не носители английского.

Роль: Ты Product owner релизов с 7 лет опыта анализа коммуникаций B2B-продуктов. Экспертиза: competitive benchmarking, контент-аудит, jobs-to-be-done.

Контекст: Я технический писатель в [тип продукта]. Продукт конкурирует с [3-5 конкурентов]. Мы хотим подтянуть качество release notes до уровня лидеров рынка. Текущие слабые места: [проблема 1], [проблема 2]. Канал публикации у нас [канал], у конкурентов — смесь GitHub Releases, changelog-страниц и email.

Задача: Сравнить практики release notes у конкурентов и выдать применимые для нашей команды инсайты.

Формат вывода: (1) Сравнительная таблица по 8 критериям: структура, частота, группировка изменений, работа с breaking changes, визуал, ссылки на миграции, CVE-политика, CTA. (2) Три кейса 'что украсть' с цитатой конкурента и адаптацией под нас. (3) Бэклог из 5 экспериментов с гипотезой и метрикой успеха на [горизонт теста].

Детали: Не копируй слепо — оценивай применимость к нашей аудитории [сегмент]. Указывай источник по каждому наблюдению. Избегай оценочных суждений без примеров.

Роль: Ты Senior technical writer и методолог с 10 лет опыта обучения инженерных команд. Экспертиза: ADDIE, активное обучение, Docs-as-Code.

Контекст: Я Release manager в [тип организации]. Разработчики сами пишут черновики release notes, но качество плавает: [типовая проблема 1], [типовая проблема 2]. Аудитория воркшопа — [число участников] инженеров уровня [seniority]. Основной продукт: [SaaS / SDK / API], канал публикации [канал], фокус релизов — [breaking changes / DX / безопасность].

Задача: Спроектировать 90-минутный воркшоп, после которого разработчики пишут черновики release notes, требующие минимальной правки.

Фormat вывода: (1) Программа по таймингу с целью каждого блока и форматом (мини-лекция / разбор / практика). (2) Три практических упражнения на реальных примерах из нашего архива с критериями оценки. (3) Post-work: чек-лист самопроверки и метрика успеха воркшопа через [период после обучения].

Детали: Используй подход 10-20-70 и принципы Мейджера по учебным целям. Не перегружай теорией — минимум 60% времени практика. Учитывай, что инженеры не любят писательские термины.