首頁
release-notes
phuryn/pm-skills
將技術工單、產品需求說明書（PRD）或變更日誌，轉化為按類別整理、呈現給使用者的精緻發行說明。
...展開全部發行說明生成器
將技術工單、產品需求說明書 (PRD) 或內部變更日誌轉化為精緻且面向使用者的發行說明。
背景
您正在為$ARGUMENTS 撰寫發行說明。
若使用者提供了檔案（例如 JIRA 匯出檔、Linear 工單、產品需求說明書、Git 記錄或內部變更日誌），請先閱讀這些內容。若其中提及產品網址，請透過網路搜尋來了解該產品及其目標受眾。
操作說明
蒐集原始資料：閱讀所有提供的工單、變更紀錄或說明。提取：
- 有哪些變更（功能、改進或修正）
- 受影響對象（哪些用戶群體）
- 為何重要（對用戶的益處）
將變更分類：
- 新功能：完全嶄新的功能
- 改進：對現有功能的強化
- 錯誤修正：已解決的問題
- 破壞性變更：任何需要使用者採取行動的項目（資料遷移、API 變更）
- 將被淘汰的功能：即將停用的功能
請依照以下原則撰寫每項條目：
- 以使用者效益為開端，而非技術變更
- 使用淺顯易懂的語言 — 避免使用行話、內部代號或工單編號
- 每則條目控制在 1 至 3 句以內
- 若使用者提供圖像或螢幕截圖，請一併納入
轉換範例：
技術性描述：「為儀表板 API 端點實作 Redis 快取層」
使用者導向：「儀表板的載入速度現在提升至最高 3 倍，讓您減少等待時間，花更多時間進行分析。」
技術描述：「修復了並行結帳流程中的競態條件」
使用者端表述：「已修正高流量期間部分訂單可能失敗的問題。」
版本說明的結構：
# [產品名稱] — [版本 / 日期] ## 新功能 - **[功能名稱]**：[以 1-2 句說明其功能及重要性] ## 改進 - **[領域]**：[哪些方面有所改善，以及如何帶來幫助] ## 錯誤修正 - 已修正 [以使用者易懂的語言描述問題] ## 重大變更（如有） - **需採取的行動**：[使用者需要做什麼]請調整語氣以符合產品風格——B2B 產品應採用專業語調，消費級產品應採用友善語調，API 則應以開發者為導向。
儲存為 Markdown 文件。若使用者需要 HTML 或其他格式，請依需求進行轉換。
---
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.
所有檔案
1 個檔案安裝 release-notes
請下載並將技能檔案解壓縮至您的 .claude/skills/ 目錄中。
下載 ZIP複製儲存庫並將技能檔案複製到您的專案中。
git clone https://github.com/phuryn/pm-skills/tree/main/pm-execution/skills/release-notes # Copy SKILL.md to your .claude/skills/ directory
複製
