Дом

Skill

Документация

release-notes

phuryn/pm-skills

Превратите технические заявки, спецификации продукта (PRD) или журналы изменений в аккуратно оформленные примечания к выпуску, предназначенные для пользователей и сгруппированные по категориям.

...Расширить все

Обновлено время 29 сентября 2026 г.

# markdown # changelog # linear # jira # release notes # product documentation

Генератор примечаний к выпуску

Превращайте технические заявки, спецификации продукта (PRD) или внутренние журналы изменений в отполированные примечания к выпуску, предназначенные для пользователей.

Контекст

Вы составляете примечания к выпуску для $ARGUMENTS.

Если пользователь предоставляет файлы (экспорты из JIRA, тикеты Linear, PRD, журналы Git или внутренние журналы изменений), сначала ознакомьтесь с ними. Если в них указан URL продукта, воспользуйтесь поиском в Интернете, чтобы понять суть продукта и его целевую аудиторию.

Инструкции

Соберите исходный материал: прочитайте все предоставленные тикеты, журналы изменений или описания. Выделите:
- Что изменилось (функция, улучшение или исправление)
- На кого это влияет (какой сегмент пользователей)
- Почему это важно (польза для пользователя)
Распределите изменения по категориям:
- Новые функции: совершенно новые возможности
- Улучшения: усовершенствования существующих функций
- Исправления ошибок: устраненные проблемы
- Существенные изменения: все, что требует действий со стороны пользователя (миграции, изменения API)
- Устаревшие функции: функции, которые будут выведены из эксплуатации
Составляйте каждую запись, следуя следующим принципам:
- Начинайте с описания преимуществ для пользователя, а не с технических изменений
- Используйте простой язык — избегайте жаргона, внутренних кодовых названий или номеров тикетов
- Каждая запись должна состоять из 1–3 предложений
- Добавляйте изображения или скриншоты, если пользователь их предоставит
Примеры преобразований:
- Технический вариант: «Реализован уровень кэширования Redis для конечных точек API панели инструментов»
- Для пользователей: «Дашборды теперь загружаются в 3 раза быстрее, поэтому вы тратите меньше времени на ожидание и больше — на анализ».
- Технический: «Исправлена ситуация конкуренции в процессе одновременной оформки заказа»
- Для пользователей: «Исправлена проблема, из-за которой некоторые заказы могли не проходить в периоды высокой нагрузки».

Структура примечаний к выпуску:

# [Название продукта] — [Версия / Дата]

## Новые функции
- **[Название функции]**: [Описание в 1–2 предложениях: что она делает и почему это важно]

## Улучшения
- **[Область]**: [Что стало лучше и как это помогает]

## Исправления ошибок
- Исправлено [описание проблемы с точки зрения пользователя]

## Существенные изменения (если есть)
- **Необходимые действия**: [Что нужно сделать пользователям]

Адаптируйте тон сообщения в соответствии со стилем продукта — профессиональный для B2B, дружественный для потребителей, ориентированный на разработчиков для API.

Сохраните в формате Markdown. Если пользователю нужен HTML или другой формат, преобразуйте документ соответствующим образом.

Посмотреть на GitHub

---
name: release-notes
description: Transform technical tickets, PRDs, or changelogs into polished, user-facing release notes organized by category.
---

## Release Notes Generator

Transform technical tickets, PRDs, or internal changelogs into polished, user-facing release notes.

### Context

You are writing release notes for **$ARGUMENTS**.

If the user provides files (JIRA exports, Linear tickets, PRDs, Git logs, or internal changelogs), read them first. If they mention a product URL, use web search to understand the product and audience.

### Instructions

1. **Gather raw material**: Read all provided tickets, changelogs, or descriptions. Extract:
   - What changed (feature, improvement, or fix)
   - Who it affects (which user segment)
   - Why it matters (the user benefit)

2. **Categorize changes**:
   - **New Features**: Entirely new capabilities
   - **Improvements**: Enhancements to existing features
   - **Bug Fixes**: Issues resolved
   - **Breaking Changes**: Anything that requires user action (migrations, API changes)
   - **Deprecations**: Features being sunset

3. **Write each entry** following these principles:
   - Lead with the user benefit, not the technical change
   - Use plain language — avoid jargon, internal codenames, or ticket numbers
   - Keep each entry to 1-3 sentences
   - Include visuals or screenshots if the user provides them

   **Example transformations**:
   - Technical: "Implemented Redis caching layer for dashboard API endpoints"
   - User-facing: "Dashboards now load up to 3× faster, so you spend less time waiting and more time analyzing."

   - Technical: "Fixed race condition in concurrent checkout flow"
   - User-facing: "Fixed an issue where some orders could fail during high-traffic periods."

4. **Structure the release notes**:

   ```
   # [Product Name] — [Version / Date]

   ## New Features
   - **[Feature name]**: [1-2 sentence description of what it does and why it matters]

   ## Improvements
   - **[Area]**: [What got better and how it helps]

   ## Bug Fixes
   - Fixed [issue description in user terms]

   ## Breaking Changes (if any)
   - **Action required**: [What users need to do]
   ```

5. **Adjust tone** to match the product's voice — professional for B2B, friendly for consumer, developer-focused for APIs.

Save as a markdown document. If the user wants HTML or another format, convert accordingly.