# Release Notes

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

- Skill: `weakened-fixedinvestmenttrust229/release-notes` (Agent Skill)
- Install (CLI): `npx skillmds@latest add weakened-fixedinvestmenttrust229/release-notes`
- Raw SKILL.md: https://api.skillmd.com/api/skills/weakened-fixedinvestmenttrust229/release-notes/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- Author: weakened-fixedinvestmenttrust229 (https://skillmd.com/u/weakened-fixedinvestmenttrust229)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/weakened-fixedinvestmenttrust229/release-notes

---


## 릴리스 노트 생성기

기술적인 티켓, 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 또는 다른 형식을 원하면 그에 맞게 변환하세요.