---
name: vibe-sdlc-release
description: >
  Vibe-SDLC Phase 5：回饋收集、Release 發佈與迭代規劃。
  使用時機：里程碑收尾完成（由 Phase 4 觸發），需要收集回饋、發佈 Release、啟動下一輪迭代。
user_invocable: true
---

# Phase 5：回饋收集、Release 發佈與迭代規劃

## 目的

收集驗收回饋、發佈 GitHub Release、引導啟動下一輪迭代。

> **注意**：里程碑完成確認與規格文件盤點已在 Phase 4 的「里程碑收尾作業」中完成。Phase 5 專注於回饋、Release 與迭代閉環。

## 你的角色

你是 AI 助手（執行者）。在此階段你的職責是：
- 協助整理使用者回饋
- 根據開發者指示更新 PRD 與 Dev Plan
- 引導 GitHub Release 發佈流程

**你不應該**：
- 自行決定哪些回饋需要處理
- 未經開發者確認就修改規格文件
- 自行決定下一輪迭代的優先級

## 前置條件

- Phase 4 已產出**里程碑完成確認報告**（里程碑收尾作業已執行）
- 規格文件盤點已完成（於 Phase 4 中執行）

## 運作模式

Phase 5 依據專案類型自動選擇運作模式：

| 條件 | 模式 | 行為 |
|------|------|------|
| 有部署環境（`docker-compose.yml` 或 CI/CD 配置） | **完整模式** | 回饋收集 → Release 發佈 → 迭代規劃 |
| 無部署環境（純規範 / Library / CLI 專案） | **快速模式** | 跳過驗收，直接進入 Release 發佈 → 迭代規劃 |

## 操作步驟

### 完整模式

| 步驟 | 執行者 | 操作 | 產出 |
|------|--------|------|------|
| 1 | **開發者** | 在測試環境進行驗收測試，回報問題與回饋 | 回饋清單 |
| 2 | **AI 助手** | 整理回饋為結構化格式（詳見「回饋整理格式」） | 回饋報告 |
| 3 | **開發者** | 確認哪些回饋需要處理 | 決策 |
| 4 | **AI 助手** | 根據確認結果更新規格文件（PRD、Dev Plan 及其他受影響文件），確認版本修訂記錄已同步 | 更新後的規格 |
| 5 | **AI 助手** | 引導 README 生成或更新（詳見「README 生成與更新」） | README.md |
| 6 | **AI 助手** | 引導 GitHub Release 發佈（詳見「GitHub Release 流程」） | GitHub Release |
| 7 | — | **回到 Phase 2**，啟動下一輪迭代 | — |

> **驗收中發現的問題**：直接複用「議題收集與處置流程」（核心原則第 6 條，選項 1～5）。選項 1、2 修正完成後額外詢問是否重新部署。

### 快速模式

| 步驟 | 執行者 | 操作 | 產出 |
|------|--------|------|------|
| 1 | **AI 助手** | 詢問是否有回饋需要收集 | — |
| 2 | **AI 助手** | 若有回饋，整理並更新規格文件；若無，跳過 | — |
| 3 | **AI 助手** | 引導 README 生成或更新（詳見「README 生成與更新」） | README.md |
| 4 | **AI 助手** | 引導 GitHub Release 發佈 | GitHub Release |
| 5 | — | **回到 Phase 2**，啟動下一輪迭代 | — |

## 回饋整理格式

當開發者提供回饋時，協助整理為以下格式：

```markdown
# 迭代回饋整理

## 回饋來源
- [使用者測試 / 內部審查 / 客戶反饋]

## 需求變更（更新至 PRD）
| 編號 | 回饋描述 | 影響範圍 | 優先級 | PRD 章節 |
|------|----------|----------|--------|----------|

## 新增任務（更新至 Dev Plan）
| 編號 | 任務描述 | 建議里程碑 | 優先級 | 依賴 |
|------|----------|-----------|--------|------|

## 不處理項目（含原因）
| 編號 | 回饋描述 | 不處理原因 |
|------|----------|-----------|
```

## README 生成與更新

Release 發佈前，AI 應主動檢查並引導 README 的生成或更新。

### 偵測與引導

```
📄 README 檢查
──────────────
{情境判斷結果}

請選擇：
  1️⃣  生成 / 更新 README.md
  2️⃣  跳過，不需要更新
```

| 情境 | 提示 |
|------|------|
| 專案無 README.md | 「專案尚無 README.md，建議在 Release 前生成。」 |
| 已有 README.md，本輪有功能變更 | 「本輪迭代新增/修改了功能，建議更新 README.md。」 |
| 已有 README.md，本輪僅修 Bug | 「本輪僅有 Bug 修正，README 可能不需更新。」 |

### 內容來源

README 內容從規格文件自動提取：

| 章節 | 來源 |
|------|------|
| 專案描述 + 功能特色 | PRD（`01-1-PRD.md`） |
| 技術棧 + 系統架構 | SRD（`01-2-SRD.md`） |
| 安裝 / 部署步驟 | Dev Plan 或 CI/CD Spec |
| API 概覽 | API Spec（若適用） |
| UI 截圖 / Demo | UI/UX 設計文件（若適用） |

### 建議結構（專業開源風格）

```markdown
# 專案名稱

> 一句話描述

[![License](badge)](#) [![CI](badge)](#) ...

## Features / 功能特色

## Quick Start / 快速開始

## Installation / 安裝

## Usage / 使用方式

## Architecture / 架構（選用）

## API Reference / API 參考（選用）

## Contributing / 貢獻指南（選用）

## License
```

### 多語支援

生成 README 後，詢問開發者是否需要多語版本：

```
🌐 多語 README
──────────────
是否需要其他語言的 README？

  1️⃣  不需要
  2️⃣  繁體中文（README.zh-TW.md）
  3️⃣  簡體中文（README.zh-CN.md）
  4️⃣  日文（README.ja.md）
  5️⃣  自訂語言：___

可多選（如 2,4）：
```

若選擇多語：
- 在主 README.md 頂部加入語言切換連結：`[English](README.md) | [繁體中文](README.zh-TW.md) | ...`
- 各語言版本的結構與主 README 一致，內容翻譯為對應語言
- 技術術語、程式碼區塊、指令保持原文不翻譯

## GitHub Release 流程

驗收通過（或快速模式下回饋處理完畢）後，AI 應主動提示開發者是否要發佈 GitHub Release。

### 引導流程

向開發者確認以下三個問題：

```
🚀 GitHub Release 發佈
──────────────────────
里程碑已完成，是否要發佈 GitHub Release？

請確認：
  1️⃣  版本號：（建議 v{X.Y.Z}，目前最新 tag：{latest_tag}）
  2️⃣  類型：正式版（Release）/ 預覽版（Pre-release）
  3️⃣  Release Notes 風格：自動生成 / 簡要摘要 / 詳細變更日誌
```

若開發者選擇**不發佈 Release**，直接跳至迭代引導。

### 執行步驟

1. **查詢現有 tag**：`git tag -l` 確認版本號不衝突
2. **建立 tag**：`git tag -a {version} -m "{version}"`
3. **推送 tag**：`git push origin {version}`
4. **建立 Release**：
   ```bash
   gh release create {version} -R {owner}/{repo} \
     --title "{version} - {project_name}" \
     [--prerelease] \
     --notes "..."
   ```
5. **回傳 Release URL** 給開發者確認

### Release Notes 生成規則

依開發者選擇的風格：

| 風格 | 內容 |
|------|------|
| **自動生成** | 使用 `gh release create --generate-notes` 自動從 PR 標題生成 |
| **簡要摘要** | 列出功能摘要（按模組分類）與技術棧，不逐一列 PR |
| **詳細變更日誌** | 按里程碑分組，列出每個 PR 的標題與編號 |

## 完成條件

- [ ] 回饋已整理並反映至規格文件（若有回饋）
- [ ] 所有被修改的規格文件皆已更新版本修訂記錄（版本號 + 日期 + 修訂說明）
- [ ] 下一輪迭代的 Dev Plan 已更新（若有新增任務）
- [ ] README.md 已生成或更新（若開發者選擇執行）
- [ ] GitHub Release 已發佈（若開發者選擇發佈）

## 行為指引

當使用者呼叫此 skill 時：

1. **偵測運作模式**：
   - 檢查專案根目錄是否存在 `docker-compose.yml`（或 `docker-compose.yaml`、`compose.yml`）或 `.github/workflows/` 中是否有 CD 配置
   - 有 → 完整模式；無 → 快速模式
   - 告知開發者當前模式，開發者可隨時切換

2. **確認前置條件**：
   - 檢查 Phase 4 是否已完成里程碑收尾作業（`02-Dev_Plan.md` 中對應里程碑任務全部標記完成）
   - 若未完成，提示先執行 Phase 4（`/vibe-sdlc-pr`）

3. **完整模式**：
   - 詢問開發者是否已完成驗收測試
   - 若開發者回報問題，引導使用「議題收集與處置流程」（選項 1～5）
   - 驗收結束時，主動提醒是否有選項 3 暫存的待建立 Issues，列出本輪修正摘要
   - 若 `chore/main-agent/*` 分支有未推送的修正，提交 PR 並在合併後刪除該分支
   - 將所有回饋整理為回饋格式

4. **快速模式**：
   - 直接詢問：「有無回饋需要收集？」
   - 若有，整理並更新規格文件
   - 若無，跳至 Release 流程

5. **README 生成與更新**：
   - 檢查是否已有 README.md，結合本輪迭代的變更判斷是否需要更新
   - 依開發者選擇生成或更新 README
   - 若生成/更新了 README，詢問是否需要多語版本
   - 若開發者選擇跳過，直接進入 Release 流程

6. **GitHub Release**：
   - 主動提示是否發佈 Release
   - 依開發者選擇執行發佈流程（詳見「GitHub Release 流程」章節）
   - 若開發者選擇跳過，直接進入迭代引導

7. **迭代引導**：
   - 提示 Context 管理建議：

   ```
   💡 里程碑 {M} 已完成。建議開啟新 session 以節省 Context。
      當前進度已同步至 GitHub，新 session 可透過 `/vibe-sdlc` 快速恢復狀態。
   ```

   - 提示開發者回到 Phase 2（`/vibe-sdlc-issues`）啟動下一輪迭代