一键导入
vibe-sdlc-release
Vibe-SDLC Phase 5:回饋收集、Release 發佈與迭代規劃。 使用時機:里程碑收尾完成(由 Phase 4 觸發),需要收集回饋、發佈 Release、啟動下一輪迭代。
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Vibe-SDLC Phase 5:回饋收集、Release 發佈與迭代規劃。 使用時機:里程碑收尾完成(由 Phase 4 觸發),需要收集回饋、發佈 Release、啟動下一輪迭代。
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | vibe-sdlc-release |
| description | Vibe-SDLC Phase 5:回饋收集、Release 發佈與迭代規劃。 使用時機:里程碑收尾完成(由 Phase 4 觸發),需要收集回饋、發佈 Release、啟動下一輪迭代。 |
| user_invocable | true |
收集驗收回饋、發佈 GitHub Release、引導啟動下一輪迭代。
注意:里程碑完成確認與規格文件盤點已在 Phase 4 的「里程碑收尾作業」中完成。Phase 5 專注於回饋、Release 與迭代閉環。
你是 AI 助手(執行者)。在此階段你的職責是:
你不應該:
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,啟動下一輪迭代 | — |
當開發者提供回饋時,協助整理為以下格式:
# 迭代回饋整理
## 回饋來源
- [使用者測試 / 內部審查 / 客戶反饋]
## 需求變更(更新至 PRD)
| 編號 | 回饋描述 | 影響範圍 | 優先級 | PRD 章節 |
|------|----------|----------|--------|----------|
## 新增任務(更新至 Dev Plan)
| 編號 | 任務描述 | 建議里程碑 | 優先級 | 依賴 |
|------|----------|-----------|--------|------|
## 不處理項目(含原因)
| 編號 | 回饋描述 | 不處理原因 |
|------|----------|-----------|
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 設計文件(若適用) |
# 專案名稱
> 一句話描述
[](#) [](#) ...
## 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):
若選擇多語:
[English](README.md) | [繁體中文](README.zh-TW.md) | ...驗收通過(或快速模式下回饋處理完畢)後,AI 應主動提示開發者是否要發佈 GitHub Release。
向開發者確認以下三個問題:
🚀 GitHub Release 發佈
──────────────────────
里程碑已完成,是否要發佈 GitHub Release?
請確認:
1️⃣ 版本號:(建議 v{X.Y.Z},目前最新 tag:{latest_tag})
2️⃣ 類型:正式版(Release)/ 預覽版(Pre-release)
3️⃣ Release Notes 風格:自動生成 / 簡要摘要 / 詳細變更日誌
若開發者選擇不發佈 Release,直接跳至迭代引導。
git tag -l 確認版本號不衝突git tag -a {version} -m "{version}"git push origin {version}gh release create {version} -R {owner}/{repo} \
--title "{version} - {project_name}" \
[--prerelease] \
--notes "..."
依開發者選擇的風格:
| 風格 | 內容 |
|---|---|
| 自動生成 | 使用 gh release create --generate-notes 自動從 PR 標題生成 |
| 簡要摘要 | 列出功能摘要(按模組分類)與技術棧,不逐一列 PR |
| 詳細變更日誌 | 按里程碑分組,列出每個 PR 的標題與編號 |
當使用者呼叫此 skill 時:
偵測運作模式:
docker-compose.yml(或 docker-compose.yaml、compose.yml)或 .github/workflows/ 中是否有 CD 配置確認前置條件:
02-Dev_Plan.md 中對應里程碑任務全部標記完成)/vibe-sdlc-pr)完整模式:
chore/main-agent/* 分支有未推送的修正,提交 PR 並在合併後刪除該分支快速模式:
README 生成與更新:
GitHub Release:
迭代引導:
💡 里程碑 {M} 已完成。建議開啟新 session 以節省 Context。
當前進度已同步至 GitHub,新 session 可透過 `/vibe-sdlc` 快速恢復狀態。
/vibe-sdlc-issues)啟動下一輪迭代Vibe-SDLC Agent 狀態查詢與彙整。讀取各 Agent 狀態檔,彙整為全局 STATUS.md,提供即時專案現況。 使用時機:想掌握各 Agent 工作狀態、專案全局現況、或需要彙整 STATUS.md 時。
Vibe-SDLC 流程總覽與導航。顯示完整 SDLC 流程、角色定義,並引導使用者進入對應的 Phase skill。 使用時機:專案啟動、查看目前進度、不確定該用哪個 Phase skill 時。
Vibe-SDLC Phase 3:開發循環 (Execution Loop)。領取 Issue 進行開發、測試、Vibe Check,通過後自動建立 PR。 使用時機:日常開發,需要從看板領取 Issue 並實作功能。
Vibe-SDLC Phase 4:CI 監控、失敗修正與合併後作業。處理 CI 結果、修正失敗、Merge 後更新 Dev Plan。 使用時機:PR 已建立(由 Phase 3 自動建立),需要監控 CI、處理失敗、或執行合併後作業。
Vibe-SDLC Phase 1:定義規格文件與計畫,協助撰寫與審查 PRD、SRD、SDD、API Spec、Dev Plan。 使用時機:專案啟動需要建立規格文件與計畫,或需要審查既有規格的完整性與一致性。
Vibe-SDLC Phase 2:任務掛載 (Planning → Issues)。審核 Dev Plan 完整性,並自動建立 GitHub Issues。 使用時機:規格文件已定稿,需要將開發計畫轉換為 GitHub Issues 與看板任務。