릴리스 노트 생성기

기술 티켓, PRD 또는 내부 변경 내역을 세련된 사용자용 릴리스 노트로 변환합니다.

배경

$ARGUMENTS에 대한 릴리스 노트를 작성하고 있습니다.

사용자가 파일(JIRA 내보내기, Linear 티켓, PRD, Git 로그 또는 내부 변경 내역)을 제공한 경우, 먼저 해당 파일을 읽어보세요. 제품 URL이 언급되어 있다면, 웹 검색을 통해 제품과 대상 고객층을 파악하세요.

지침

원자료를 수집하세요: 제공된 모든 티켓, 변경 내역서 또는 설명을 읽어보세요. 다음 내용을 추출하세요:
- 무엇이 변경되었는지(기능, 개선 사항 또는 수정 사항)
- 누가 영향을 받는지(어떤 사용자층)
- 왜 중요한가(사용자에게 주는 이점)
변경 사항 분류:
- 신규 기능: 완전히 새로운 기능
- 개선 사항: 기존 기능의 강화
- 버그 수정: 해결된 문제
- 호환성 변경 사항: 사용자의 조치가 필요한 모든 사항 (마이그레이션, API 변경)
- 사용 중단 예정 기능: 단계적으로 폐지될 기능
다음 원칙에 따라각 항목을 작성하십시오:
- 기술적 변경 사항이 아닌 사용자에게 주는 이점을 먼저 제시하세요
- 평이한 언어를 사용하십시오 — 전문 용어, 내부 코드명 또는 티켓 번호는 피하십시오
- 각 항목은 1~3문장으로 간결하게 작성하십시오
- 사용자가 제공한 경우 시각 자료나 스크린샷을 포함하십시오
변환 예시:
- 기술적: "대시보드 API 엔드포인트에 Redis 캐싱 레이어를 구현했습니다"
- 사용자용: "대시보드 로딩 속도가 최대 3배 빨라져, 기다리는 시간은 줄이고 분석에 더 많은 시간을 할애할 수 있습니다."
- 기술적: "동시 결제 흐름에서 발생하던 경합 조건을 수정했습니다"
- 사용자 관점: “트래픽이 많은 시간대에 일부 주문이 실패할 수 있던 문제를 수정했습니다.”

릴리스 노트 구성:

# [제품명] — [버전 / 날짜]

## 새로운 기능
- **[기능명]**: [기능의 역할과 중요성에 대한 1~2문장 분량의 설명]

## 개선 사항
- **[영역]**: [어떤 점이 개선되었으며 어떤 도움이 되는지]

## 버그 수정
- [사용자 용어로 작성된 문제 설명]을 수정했습니다.

## 호환성 변경 사항 (해당하는 경우)
- **필요한 조치**: [사용자가 해야 할 일]

제품의 어조에 맞춰문체를 조정하세요 — B2B의 경우 전문적인 어조, 소비자 대상의 경우 친근한 어조, API의 경우 개발자 중심의 어조를 사용하세요.

마크다운 문서로 저장하십시오. 사용자가 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.