القائمة
Vibe-SDLC Phase 4：CI 監控、失敗修正與合併後作業。處理 CI 結果、修正失敗、Merge 後更新 Dev Plan。 使用時機：PR 已建立（由 Phase 3 自動建立），需要監控 CI、處理失敗、或執行合併後作業。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
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 5：回饋收集、Release 發佈與迭代規劃。 使用時機：里程碑收尾完成（由 Phase 4 觸發），需要收集回饋、發佈 Release、啟動下一輪迭代。
Vibe-SDLC Phase 1：定義規格文件與計畫，協助撰寫與審查 PRD、SRD、SDD、API Spec、Dev Plan。 使用時機：專案啟動需要建立規格文件與計畫，或需要審查既有規格的完整性與一致性。
Vibe-SDLC Phase 2：任務掛載 (Planning → Issues)。審核 Dev Plan 完整性，並自動建立 GitHub Issues。 使用時機：規格文件已定稿，需要將開發計畫轉換為 GitHub Issues 與看板任務。
| name | vibe-sdlc-pr |
| description | Vibe-SDLC Phase 4：CI 監控、失敗修正與合併後作業。處理 CI 結果、修正失敗、Merge 後更新 Dev Plan。 使用時機：PR 已建立（由 Phase 3 自動建立），需要監控 CI、處理失敗、或執行合併後作業。 |
| user_invocable | true |
監控 PR 的 CI 結果，處理失敗修正，並在合併後執行 Dev Plan 更新與驗證提醒。
注意：PR 的建立已在 Phase 3 中自動完成。Phase 4 聚焦於 CI 監控、失敗修正與合併後作業。
你是 AI 助手（執行者）。在此階段你的職責是：
02-Dev_Plan.md 標記任務完成你不應該：
| 步驟 | 執行者 | 操作 | 產出 |
|---|---|---|---|
| 1 | AI 助手 | 使用 gh pr checks 監控 CI 結果 | CI 狀態報告 |
| 2a | CI 通過 | AI 助手 通知開發者可進行 Code Review | — |
| 2b | CI 失敗 | AI 助手 讀取失敗報告，分析原因，修正程式碼，確認 PR 仍為 OPEN 後推送新 commit | 修正 commit |
| → 回到步驟 1，GitHub 重新執行 CI | — | ||
| 2c | CI 環境問題 | 若單元測試（Backend/Frontend CI）通過，但 E2E 因環境配置問題（非代碼問題）失敗，標註為已知環境問題，建議開發者合併（詳見「已知 CI 環境問題處理」） | — |
| 3 | 開發者 | Code Review，核准後點擊 Merge | Merge commit |
| 4 | GitHub | 觸發 CD pipeline（如已配置） | 部署 |
| 5 | AI 助手 | 合併後作業（詳見「合併後作業清單」） | — |
PR 合併後，AI 助手必須在對應 Issue 發佈完成 Comment：
🎉 **任務完成**
- **PR**：#{PR_NUMBER}（已合併）
- **Dev Plan**：已更新為 `[x] Completed`
- **待驗證**：{列出相關驗證 Issues，若無則寫「無」}
PR 合併後，AI 助手必須依序執行：
同步 main 並回到快照分支（不對 dev/main-agent rebase）：
git fetch origin
git checkout main && git pull origin main
git checkout dev/main-agent && git reset --hard origin/dev/main-agent
dev/main-agent的歷史由/vibe-sdlc-status管理，這裡只對齊遠端。禁止 rebase 或 force push。
清理已合併分支（依分支類型不同處理）：
feat/<agent>/issue-N-簡述)：刪除本地與遠端分支
git branch -d feat/<agent>/issue-N-簡述
git push origin --delete feat/<agent>/issue-N-簡述
chore/main-agent/*：同樣刪除本地與遠端分支
git branch -d chore/main-agent/<date>-<簡述>
git push origin --delete chore/main-agent/<date>-<簡述>
dev/main-agent 不會出現在合併路徑上（不再承接工作 PR）更新 Dev Plan：將對應任務標記為 [x] Completed
更新看板狀態：標記 Issue 為 Done
發佈完成 Comment：含 PR 連結與 Dev Plan 更新
更新 Agent 狀態檔：將已完成任務從「當前任務」移除，更新「近期待辦」
彙整 STATUS.md：呼叫 /vibe-sdlc-status 彙整全局現況至 /docs/status/STATUS.md
TG 推播完成通知：若有設定 TG 推播，發送 ✅ {agent} #{N} 完成，PR #{M} 已合併
提示規格文件同步：若 PR 涉及 API/行為變更（詳見「規格文件同步觸發條件」）
詢問是否重建部署：「PR 已合併，是否重建部署？」
提醒驗證 Issues：若有對應的手動驗證 Issues
里程碑收尾判斷：檢查當前里程碑是否所有 Issues（開發 + 驗證）皆已關閉，若是則執行「里程碑收尾作業」
若 CI 失敗的原因為環境配置問題（非代碼邏輯錯誤），AI 可標註為已知問題並建議合併：
判斷標準：
| 條件 | 判定 |
|---|---|
| Backend CI ✅ + Frontend CI ✅ + E2E ❌（環境錯誤如 DB URL、Docker 配置） | 已知環境問題，可合併 |
| Backend CI ❌ 或 Frontend CI ❌ | 代碼問題，必須修正 |
| E2E ❌ 且錯誤訊息涉及業務邏輯（assertion failed、element not found 等） | 代碼問題，必須修正 |
環境問題特徵（常見）：
Prisma schema validation / P1012 錯誤ECONNREFUSED / 服務未啟動處理方式：向開發者報告 CI 狀態，標註「E2E 因環境問題失敗（非代碼問題），Backend + Frontend 單元測試全部通過」，建議合併。
PR 合併後，若涉及以下改動，AI 應提示開發者是否需要同步更新規格文件：
| 改動類型 | 是否提示更新 | 對應規格文件 |
|---|---|---|
| 新增 API endpoint | 必須提示 | API Spec (md + yaml) |
| API 行為或欄位變更 | 必須提示 | API Spec (md + yaml) |
| UI 流程或頁面調整 | 建議提示 | PRD |
| 資料模型變更 | 建議提示 | SRD |
| 基礎設施修正（nginx、timeout） | 不需要 | — |
| 依賴升級、config 調整 | 不需要 | — |
建立 PR 時，必須使用以下格式：
## 變更摘要
[一段話描述本次變更的目的與內容]
## 關聯 Issue
Closes #N
## 變更清單
- [變更項目 1]
- [變更項目 2]
## 測試結果
- 單元測試：✅ 全部通過（N/N）
- 本地驗證：✅ Vibe Check 通過
⚠️ 重要：向已有 PR 的分支推送新 commit 前，必須先確認 PR 仍為 OPEN。已合併的 PR 不會包含後續推送的 commit。
若需對已建立 PR 的分支追加 commit（例如修正 CI 失敗、回應 Code Review 意見），必須在推送前執行：
# 檢查 PR 狀態
gh pr view <PR-NUMBER> -R <OWNER>/<REPO> --json state -q '.state'
| PR 狀態 | 處理方式 |
|---|---|
OPEN | 正常推送至該分支，commit 會自動加入 PR |
MERGED | 禁止推送至該分支。必須從最新 main 建立新分支、建立新 PR |
CLOSED | 確認是否需要重新開啟，或建立新分支與新 PR |
當 Dev Plan 採用多 Sub Agent 並行開發時，PR 流程擴展為雙層審查：
Sub Agent 建立的分支必須遵循：feat/<agent>/issue-N-簡述
例如：feat/backend/issue-12-auth-api、feat/frontend/issue-15-login-ui
每個 Sub Agent 使用獨立的 Git Worktree：
git worktree add ../worktree-backend feat/backend/issue-12-auth-api
git worktree add ../worktree-frontend feat/frontend/issue-15-login-ui
| 步驟 | 執行者 | 操作 | 說明 |
|---|---|---|---|
| 1 | Sub Agent | 提交 PR，標題含任務編號 | PR 範圍僅限該 Agent 負責的目錄 |
| 2 | GitHub | 觸發 CI | Lint、Type Check、Unit Test |
| 3 | A-Main | 初審 | 確認 PR 範圍正確、CI 通過、無跨目錄修改 |
| 4 | H-Director | 終審 & Merge | Code Review 後合併至 main |
Sub Agent 的 PR 禁止 修改其負責範圍以外的檔案：
| Agent | 允許路徑 |
|---|---|
| A-Backend | /backend/** |
| A-Frontend | /frontend/** |
| A-QA | /tests/** |
| A-DevOps | .github/**, docker/**, Dockerfile, docker-compose.yml |
| A-Main | 全專案 (整合用) |
當合併後作業第 12 步判定當前里程碑所有 Issues（開發 + 驗證）皆已關閉時，AI 應在該次合併後作業中一併執行以下收尾：
# 里程碑完成確認報告
## 里程碑資訊
- 里程碑：M[N] - [名稱]
- 完成日期：[日期]
## 任務完成狀態
| Issue | 標題 | 狀態 | 合併日期 |
|-------|------|------|----------|
## Dev Plan 對應狀態
- 總任務數：N
- 已完成：N
- 未完成：0
## 部署狀態
- 測試環境：[已部署 / 未部署]
- 部署版本：[版本號或 commit hash]
盤點本輪迭代中所有已合併 PR（含議題收集選項 1 透過 chore/main-agent/* 提交的小改動），檢查是否有遺漏的規格文件更新：
注意：基礎設施修正（nginx config、timeout 調整）不需要更新規格文件。
根據專案狀態引導開發者：
| 條件 | 引導 |
|---|---|
| 有部署環境（docker-compose 或 CI/CD 配置） | 進入 Phase 5（/vibe-sdlc-release）— 完整流程：回饋收集 → Release 發佈 → 迭代規劃 |
| 無部署環境（純規範 / Library 專案） | 進入 Phase 5 快速模式（/vibe-sdlc-release）— 直接問：是否發佈 Release？有無回饋？ |
| 開發者選擇跳過 | 直接回 Phase 2（/vibe-sdlc-issues）— 繼續下一輪迭代 |
main當使用者呼叫此 skill 時：
/vibe-sdlc-dev）gh pr list 查看gh pr checks <PR-number> 查看 CI 狀態gh pr view <PR-number> --json state -q '.state'
OPEN → 正常推送MERGED → 禁止推送，從最新 main 建新分支與新 PRCLOSED → 確認是否需重新開啟或建新 PRgit fetch origin && git checkout main && git pull origin main && git checkout dev/main-agent && git reset --hard origin/dev/main-agentchore/main-agent/*：同樣刪除本地與遠端分支/vibe-sdlc-dev 的「PR 合併後的 HEAD 收尾檢查」執行 git branch --show-current，若停在 main 則立刻切回 dev/main-agent/docs/02-Dev_Plan.md- [ ] 改為 - [x]Done（或以可行的方式標註）verification，標題以 [驗證] T-{ID} 開頭）：
/vibe-sdlc-dev）