release-notes

name	release-notes
description	티켓, PRD, 또는 변경 이력에서 사용자 대상 릴리스 노트를 생성합니다. 카테고리별(신규 기능, 개선 사항, 버그 수정)로 정리된 명확하고 읽기 좋은 요약본을 작성합니다. 릴리스 노트 작성, 변경 이력 생성, 제품 업데이트 공지, 출시된 내용 요약 시 사용하세요.

릴리스 노트 생성기

기술적인 티켓, PRD, 또는 내부 변경 이력을 사용자 대상의 완성도 높은 릴리스 노트로 변환합니다.

맥락

$ARGUMENTS에 대한 릴리스 노트를 작성합니다.

사용자가 파일(JIRA 내보내기, Linear 티켓, PRD, Git 로그, 또는 내부 변경 이력)을 제공하면 먼저 읽으세요. 제품 URL을 언급한다면 웹 검색을 활용하여 제품과 대상 사용자를 파악하세요.

지시사항

1. 원본 자료 수집: 제공된 모든 티켓, 변경 이력, 또는 설명을 읽으세요. 다음 내용을 추출하세요:

   • 변경된 내용 (기능, 개선 사항, 또는 버그 수정)
   • 영향받는 대상 (어떤 사용자 세그먼트)
   • 중요한 이유 (사용자 혜택)

2. 변경 사항 분류:

   • 신규 기능: 완전히 새로운 기능
   • 개선 사항: 기존 기능 향상
   • 버그 수정: 해결된 문제
   • 호환성 변경: 사용자 조치가 필요한 내용 (마이그레이션, API 변경)
   • 지원 중단: 서비스가 종료되는 기능

3. 각 항목 작성 시 다음 원칙을 따르세요:

   • 기술적 변경이 아닌 사용자 혜택을 먼저 제시
   • 평이한 언어 사용 — 전문 용어, 내부 코드명, 티켓 번호 지양
   • 각 항목은 1~3문장으로 유지
   • 사용자가 이미지나 스크린샷을 제공하면 포함

   변환 예시:

   • 기술적 표현: "Implemented Redis caching layer for dashboard API endpoints"

   • 사용자 대상: "대시보드가 최대 3배 빠르게 로드되어, 기다리는 시간보다 분석하는 시간이 늘어납니다."

   • 기술적 표현: "Fixed race condition in concurrent checkout flow"

   • 사용자 대상: "트래픽이 많은 시간대에 일부 주문이 실패하는 문제를 수정했습니다."

4. 릴리스 노트 구조화:

   # [제품명] — [버전 / 날짜]
   
   ## 신규 기능
   - **[기능명]**: [기능이 하는 일과 중요한 이유를 1~2문장으로 설명]
   
   ## 개선 사항
   - **[영역]**: [무엇이 개선되었고 어떻게 도움이 되는지]
   
   ## 버그 수정
   - [사용자 관점에서 설명한 문제 해결 내용]
   
   ## 호환성 변경 (해당하는 경우)
   - **조치 필요**: [사용자가 해야 할 일]
   

5. 톤 조정: 제품의 보이스에 맞게 — B2B는 전문적으로, 소비자용은 친근하게, API는 개발자 중심으로.

마크다운 문서로 저장하세요. 사용자가 HTML 또는 다른 형식을 원하면 그에 맞게 변환하세요.