| name | vibe-sdlc-pr |
| description | Vibe-SDLC Phase 4：CI 監控、失敗修正與合併後作業。處理 CI 結果、修正失敗、Merge 後更新 Dev Plan。 使用時機：PR 已建立（由 Phase 3 自動建立），需要監控 CI、處理失敗、或執行合併後作業。
|
| user_invocable | true |
Phase 4：CI 監控與合併後作業 (CI/CD Gates)
目的
監控 PR 的 CI 結果，處理失敗修正，並在合併後執行 Dev Plan 更新與驗證提醒。
注意：PR 的建立已在 Phase 3 中自動完成。Phase 4 聚焦於 CI 監控、失敗修正與合併後作業。
你的角色
你是 AI 助手（執行者）。在此階段你的職責是：
- 監控 CI 執行結果
- 若 CI 失敗，根據錯誤報告修正程式碼並重新提交
- Merge 後更新
02-Dev_Plan.md 標記任務完成
- 提醒開發者相關的手動驗證 Issues
你不應該：
- 自行 Merge PR，由開發者執行
- 跳過 CI 失敗不處理
前置條件
- Phase 3 已完成，PR 已建立（由 Phase 3 自動推送與建立）
- PR 正在等待 CI 結果或開發者 Code Review
- 若需修正 CI 失敗，建議先同步工作目錄（參見 P3「工作目錄同步規範」），確保修正基於最新程式碼
操作步驟
| 步驟 | 執行者 | 操作 | 產出 |
|---|
| 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 助手 | 合併後作業（詳見「合併後作業清單」） | — |
Merge 後 Issue Comment
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。
-
清理已合併分支（依分支類型不同處理）：
-
更新 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 環境問題處理
若 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 / 服務未啟動- Docker image build 失敗（非 Dockerfile 錯誤）
- Timeout 在等待服務就緒
處理方式：向開發者報告 CI 狀態，標註「E2E 因環境問題失敗（非代碼問題），Backend + Frontend 單元測試全部通過」，建議合併。
規格文件同步觸發條件
PR 合併後，若涉及以下改動，AI 應提示開發者是否需要同步更新規格文件：
| 改動類型 | 是否提示更新 | 對應規格文件 |
|---|
| 新增 API endpoint | 必須提示 | API Spec (md + yaml) |
| API 行為或欄位變更 | 必須提示 | API Spec (md + yaml) |
| UI 流程或頁面調整 | 建議提示 | PRD |
| 資料模型變更 | 建議提示 | SRD |
| 基礎設施修正（nginx、timeout） | 不需要 | — |
| 依賴升級、config 調整 | 不需要 | — |
PR 格式規範
建立 PR 時，必須使用以下格式：
## 變更摘要
[一段話描述本次變更的目的與內容]
## 關聯 Issue
Closes #N
## 變更清單
- [變更項目 1]
- [變更項目 2]
## 測試結果
- 單元測試：✅ 全部通過（N/N）
- 本地驗證：✅ Vibe Check 通過
追加 Commit 至既有 PR 的安全檢查
⚠️ 重要：向已有 PR 的分支推送新 commit 前，必須先確認 PR 仍為 OPEN。已合併的 PR 不會包含後續推送的 commit。
若需對已建立 PR 的分支追加 commit（例如修正 CI 失敗、回應 Code Review 意見），必須在推送前執行：
gh pr view <PR-NUMBER> -R <OWNER>/<REPO> --json state -q '.state'
| PR 狀態 | 處理方式 |
|---|
OPEN | 正常推送至該分支，commit 會自動加入 PR |
MERGED | 禁止推送至該分支。必須從最新 main 建立新分支、建立新 PR |
CLOSED | 確認是否需要重新開啟，或建立新分支與新 PR |
Multi Sub Agent PR 流程
當 Dev Plan 採用多 Sub Agent 並行開發時，PR 流程擴展為雙層審查：
分支命名規範
Sub Agent 建立的分支必須遵循：feat/<agent>/issue-N-簡述
例如：feat/backend/issue-12-auth-api、feat/frontend/issue-15-login-ui
Worktree 使用
每個 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 |
PR 範圍限制
Sub Agent 的 PR 禁止 修改其負責範圍以外的檔案：
| Agent | 允許路徑 |
|---|
| A-Backend | /backend/** |
| A-Frontend | /frontend/** |
| A-QA | /tests/** |
| A-DevOps | .github/**, docker/**, Dockerfile, docker-compose.yml |
| A-Main | 全專案 (整合用) |
合併衝突處理
- 同一並行群組內的 PR 依完成先後合併，無強制順序。
- 合併後若其他 PR 產生衝突，由 A-Main 負責 rebase 解決。
- Sub Agent 不得 自行解決跨目錄衝突。
里程碑收尾作業
當合併後作業第 12 步判定當前里程碑所有 Issues（開發 + 驗證）皆已關閉時，AI 應在該次合併後作業中一併執行以下收尾：
里程碑完成確認報告
# 里程碑完成確認報告
## 里程碑資訊
- 里程碑：M[N] - [名稱]
- 完成日期：[日期]
## 任務完成狀態
| Issue | 標題 | 狀態 | 合併日期 |
|-------|------|------|----------|
## Dev Plan 對應狀態
- 總任務數：N
- 已完成：N
- 未完成：0
## 部署狀態
- 測試環境：[已部署 / 未部署]
- 部署版本：[版本號或 commit hash]
規格文件盤點
盤點本輪迭代中所有已合併 PR（含議題收集選項 1 透過 chore/main-agent/* 提交的小改動），檢查是否有遺漏的規格文件更新：
- 列出本輪迭代已合併的所有 PR
- 檢查是否有涉及 API endpoint 新增/變更、UI 流程調整、資料模型變更
- 比對規格文件是否已同步更新
- 若有遺漏，列出清單提醒開發者確認後補充
注意：基礎設施修正（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）— 繼續下一輪迭代 |
完成條件
行為指引
當使用者呼叫此 skill 時：
- 先確認前置條件：
- 是否有已建立的 open PR？（由 Phase 3 自動建立）
- 若無 open PR，提示使用者先完成 Phase 3（
/vibe-sdlc-dev）
- 列出所有 open PR，使用
gh pr list 查看
- 監控 CI 結果：
- 使用
gh pr checks <PR-number> 查看 CI 狀態
- CI 通過：通知開發者可進行 Code Review
- CI 失敗：讀取失敗報告，分析原因，修正程式碼
- 推送前必須確認 PR 狀態：
gh pr view <PR-number> --json state -q '.state'
OPEN → 正常推送MERGED → 禁止推送，從最新 main 建新分支與新 PRCLOSED → 確認是否需重新開啟或建新 PR
- 開發者 Merge 後：
- 先同步 main 與快照分支（不對 dev/main-agent rebase / force push）：
git fetch origin && git checkout main && git pull origin main && git checkout dev/main-agent && git reset --hard origin/dev/main-agent
- 若合併的是 feature 分支：刪除本地與遠端的 feature 分支
- 若合併的是
chore/main-agent/*：同樣刪除本地與遠端分支
- PR 合併後 HEAD 收尾：依
/vibe-sdlc-dev 的「PR 合併後的 HEAD 收尾檢查」執行 git branch --show-current，若停在 main 則立刻切回 dev/main-agent
- 讀取
/docs/02-Dev_Plan.md
- 找到對應任務，將
- [ ] 改為 - [x]
- 提交更新並推送
- 更新 Issue 狀態：
- 更新看板狀態為
Done（或以可行的方式標註）
- 在 Issue 發佈「🎉 任務完成」Comment（含 PR 編號、Dev Plan 更新確認、待驗證 Issues 清單）
- 檢查該任務是否有對應的手動驗證 Issues（標籤
verification，標題以 [驗證] T-{ID} 開頭）：
- 若有：提醒開發者通知對應的審查角色（H-Reviewer / H-UxReviewer）開始驗證
- 列出相關驗證 Issues 的編號與標題
- 提示開發者：
- 若還有待處理的開發 Issue → 回到 Phase 3（
/vibe-sdlc-dev）
- 若當前里程碑的開發 Issues 已全部完成，但仍有未關閉的驗證 Issues → 提醒等待驗證完成
- 若當前里程碑所有 Issues（開發 + 驗證）皆已關閉 → 執行「里程碑收尾作業」（產出里程碑完成報告 + 規格盤點 + 引導下一步）
