.cursor/rules/release-notes-template.md

@@ -0,0 +1,124 @@
+# Инструкция по оформлению Release Notes
+
+## Назначение
+Этот документ описывает структуру и формат для создания файлов Release Notes (например, `docs/RELEASE_NOTES_DEV-XX.md`).
+
+## Структура документа
+
+### 1. Заголовок
+```markdown
+# Release Notes: [название-ветки]
+```
+
+### 2. Обзор
+Краткий абзац (1-2 предложения), описывающий:
+- Количество коммитов в ветке
+- Основные направления изменений
+
+**Формат:**
+```markdown
+## Обзор
+Ветка [название] содержит [N] коммитов с ключевыми улучшениями: [краткое перечисление основных изменений].
+```
+
+### 3. Ключевые изменения
+Основной раздел с пронумерованными подразделами для каждого значимого изменения.
+
+**Структура каждого подраздела:**
+```markdown
+### [Номер]. [Название изменения]
+
+**Коммит:** `[hash]`
+
+**Что сделано:**
+- [Краткое описание изменения 1]
+- [Краткое описание изменения 2]
+- [Краткое описание изменения 3]
+```
+
+**Правила:**
+- Каждое изменение = отдельный подраздел
+- Название должно быть кратким и понятным
+- В разделе "Что сделано" используй маркированные списки
+- НЕ перечисляй затронутые файлы
+- НЕ указывай статистику строк кода
+- Фокусируйся на сути изменений, а не на технических деталях
+- Разделяй подразделы горизонтальной линией `---`
+
+### 4. Основные достижения
+Раздел с чекбоксами, подводящий итоги релиза.
+
+**Формат:**
+```markdown
+## 🎯 Основные достижения
+
+✅ [Достижение 1]  
+✅ [Достижение 2]  
+✅ [Достижение 3]  
+```
+
+**Правила:**
+- Используй эмодзи ✅ для каждого достижения
+- Каждое достижение на отдельной строке
+- Краткие формулировки (3-5 слов)
+- Фокусируйся на ключевых фичах и улучшениях
+
+### 5. Временная шкала разработки
+Раздел с информацией о сроках разработки.
+
+**Формат:**
+```markdown
+## 📅 Временная шкала разработки
+
+**Последние изменения:** [дата]  
+**Основная разработка:** [период]  
+**Предыдущие улучшения:** [контекст предыдущих веток/изменений]
+
+**Хронология коммитов:**
+- `[hash]` - [дата и время] - [краткое описание]
+- `[hash]` - [дата и время] - [краткое описание]
+```
+
+**Правила:**
+- Используй реальные даты из коммитов
+- Формат даты: "DD месяц YYYY" (например, "25 января 2026")
+- Для времени используй формат "HH:MM"
+- Хронология должна быть в хронологическом порядке (от старых к новым)
+
+## Стиль написания
+
+### Общие правила:
+- **Краткость**: Фокусируйся на сути, избегай избыточных деталей
+- **Ясность**: Используй простые и понятные формулировки
+- **Структурированность**: Информация должна быть легко читаемой и сканируемой
+- **Без технических деталей**: Не перечисляй файлы, классы, методы (только если это ключевая фича)
+- **Без статистики**: Не указывай количество строк кода, файлов и т.д.
+
+### Язык:
+- Используй прошедшее время для описания изменений ("Добавлена", "Реализована", "Обновлена")
+- Избегай технического жаргона, если это не необходимо
+- Используй активный залог
+
+### Эмодзи:
+- 🔥 для раздела "Ключевые изменения"
+- 🎯 для раздела "Основные достижения"
+- 📅 для раздела "Временная шкала разработки"
+- ✅ для чекбоксов достижений
+
+## Пример использования
+
+При создании Release Notes для новой ветки:
+
+1. Получи список коммитов: `git log [base-branch]..[target-branch] --oneline`
+2. Для каждого значимого коммита создай подраздел в "Ключевые изменения"
+3. Собери основные достижения в раздел "Основные достижения"
+4. Добавь временную шкалу с реальными датами коммитов
+5. Проверь, что документ следует структуре и стилю
+
+## Важные замечания
+
+- **НЕ включай** информацию о коммитах, которые уже были в базовой ветке (master/main)
+- **НЕ перечисляй** все файлы, которые были изменены
+- **НЕ указывай** статистику строк кода
+- **Фокусируйся** на функциональных изменениях, а не на технических деталях реализации
+- Используй **реальные даты** из коммитов, а не предполагаемые