docs(code-review-resolve): 補上同步後建立工作分支流程

README.md

@@ -189,7 +189,7 @@ rm -rf ~/.config/opencode/skills/code-review
 
 ### `code-review-resolve`
 
-四階段：**(A 解決)** 讀工作目錄 `.gitea/ai-review/findings.json`（Gitea AI review 產出的問題清單），依嚴重等級 **🔴 嚴重 → 🟠 高 → 🟡 中 → 🔵 低** 由高到低**逐條修復**程式碼問題（無法安全自動修復者標「待人工處理」不硬改），全部處理完把 `findings.json` 清空為空陣列 `[]`。**(B 提交)** 分析工作區**所有**變更，依異動內容歸類為 `feat`/`fix`/`docs`/`style`/`refactor`/`perf`/`test`/`chore`/`revert`，**每個 type 各自一個 commit**，訊息為「`type(範圍): 一句總結`」格式，**括號內的範圍須對應實際異動的功能／模組**（例 `feat(使用者登入): 新增帳密登入流程`、`perf(物件查詢): 改用批次查詢降低 DB 往返`，而非 `feat(新增功能)` 這類重述 type 的詞）。**(C 推送)** push 當前分支：先用**認證管理器**、失敗改用 **token**、再失敗**詢問使用者**。**(D 開 PR)** 用 token 透過 **Gitea API** 對目標分支發 PR（**目標分支不明必須詢問、不可猜測**），PR 描述可選**完整版**（重新分析 `git diff` 總結）／**簡單版**（逐條列 commit 訊息）／**使用者輸入**；完成後因內文可能含 gitea token，**提醒並清除 AI 助理對話內文**。修改程式碼／commit／push／開 PR 前先輸出計畫並取得同意（`--yes` 可略過）；token 一律由環境變數（如 `GITEA_TOKEN`）提供，全程不明文輸出。
+五階段：**(A Git 同步)** 先 `fetch`，務必檢查目前分支的線上分支是否存在；存在則更新到最新，不存在則依序切換到遠端 `develop`／`master` 並更新到最新，找不到後備分支則停止；pull 發生衝突時告知並嘗試安全解衝突；若更新後目前分支名稱與遠端分支名稱相同，必須從該基準建立新的工作分支，後續修復、commit、push 與 PR `head` 都使用新分支。**(B 解決)** 讀工作目錄 `.gitea/ai-review/findings.json`（Gitea AI review 產出的問題清單），依嚴重等級 **🔴 嚴重 → 🟠 高 → 🟡 中 → 🔵 低** 由高到低**逐條修復**程式碼問題或登記誤報（無法安全自動修復者標「待人工處理」不硬改），已解決或已登記誤報者才自 `findings.json` 移除。**(C 提交)** 分析工作區**所有**變更，依異動內容歸類為 `feat`/`fix`/`docs`/`style`/`refactor`/`perf`/`test`/`chore`/`revert`，**每個 type 各自一個 commit**，訊息為「`type(範圍): 一句總結`」格式，**括號內的範圍須對應實際異動的功能／模組**（例 `feat(使用者登入): 新增帳密登入流程`、`perf(物件查詢): 改用批次查詢降低 DB 往返`，而非 `feat(新增功能)` 這類重述 type 的詞）。**(D 推送)** push 當前分支：先用**認證管理器**、失敗改用 **token**、再失敗**詢問使用者**。**(E 開 PR)** 用 token 透過 **Gitea API** 對目標分支發 PR（**目標分支不明必須詢問、不可猜測**），PR 描述可選**完整版**（重新分析 `git diff` 總結）／**簡單版**（逐條列 commit 訊息）／**使用者輸入**；完成後因內文可能含 gitea token，**提醒並清除 AI 助理對話內文**。除非遇到必要決策，否則依自動執行原則直接處理；token 一律由環境變數（如 `GITEA_TOKEN`）提供，全程不明文輸出。
 
 參數：`[--findings <findings.json 路徑>] [--target <目標分支>] [--pr-desc <full|simple|自訂文字>] [--no-commit] [--no-pr] [--yes]`（findings 省略時預設 `.gitea/ai-review/findings.json`；`--target` 省略時於開 PR 階段必問；`--no-commit` 只修復不提交；`--no-pr` 推送但不開 PR；`--yes` 略過確認）。
 

skills/code-review-resolve/SKILL.md

@@ -1,16 +1,16 @@
 ---
 name: code-review-resolve
-description: 解決 `.gitea/ai-review/findings.json` 的 AI review findings，先同步 git（fetch → pull，必要時嘗試解衝突），再依嚴重度逐條修復；可判斷為誤報者寫入 `.gitea/ai-review/exclusions.json`，已解決或已登記為誤報的 finding 可自 findings 移除；接著可將工作區變更依 conventional commit 類型分類提交、push 當前分支，並透過 Gitea API 對指定目標分支開 PR。當使用者說解決 findings、處理 AI review 問題、修掉 `.gitea/ai-review` 問題、依嚴重度修復後分類提交，或要分類 commit 並 push/開 PR 時觸發。不適用於：產生 findings、單純 code review 不修改、只保存裁決紀錄，或只要不分類的單一 commit。
+description: 解決 `.gitea/ai-review/findings.json` 的 AI review findings，先同步 git（fetch → 檢查目前分支的遠端分支是否存在；存在則 pull 更新，不存在則切換到 develop／master 後 pull 更新；若更新後目前分支名稱與遠端分支名稱相同，建立新的工作分支；必要時嘗試解衝突），再依嚴重度逐條修復；可判斷為誤報者寫入 `.gitea/ai-review/exclusions.json`，已解決或已登記為誤報的 finding 可自 findings 移除；接著可將工作區變更依 conventional commit 類型分類提交、push 當前分支，並透過 Gitea API 對指定目標分支開 PR。當使用者說解決 findings、處理 AI review 問題、修掉 `.gitea/ai-review` 問題、依嚴重度修復後分類提交，或要分類 commit 並 push/開 PR 時觸發。不適用於：產生 findings、單純 code review 不修改、只保存裁決紀錄，或只要不分類的單一 commit。
 argument-hint: "[--findings <findings.json 路徑>] [--target <目標分支>] [--pr-desc <full|simple|自訂文字>] [--no-commit] [--no-pr] [--yes]"
 ---
 
 # code-review-resolve — 解決 AI review findings、分類提交、push 並開 PR
 
-五階段 skill：先執行 **git 同步**（`git fetch` → `git pull`，必要時告知並嘗試解衝突），再**逐條處理** `.gitea/ai-review/findings.json` 裡的問題；成立問題修復後自 findings 移除，可判斷為誤報者寫入 `.gitea/ai-review/exclusions.json` 後也可自 findings 移除，接著把工作區所有變更**依 conventional commit 類型分門別類 commit**，然後 **push 當前分支**，最後**透過 Gitea API 發 PR**。
+五階段 skill：先執行 **git 同步**（`git fetch` → 確認目前分支的遠端分支是否存在；存在則 `git pull` 更新，不存在則切換到 `develop`，再退而 `master` 後 `git pull` 更新；若更新後目前分支名稱與遠端分支名稱相同，建立新的工作分支；必要時告知並嘗試解衝突），再**逐條處理** `.gitea/ai-review/findings.json` 裡的問題；成立問題修復後自 findings 移除，可判斷為誤報者寫入 `.gitea/ai-review/exclusions.json` 後也可自 findings 移除，接著把工作區所有變更**依 conventional commit 類型分門別類 commit**，然後 **push 當前分支**，最後**透過 Gitea API 發 PR**。
 
 | 階段 | 動作 |
 | --- | --- |
-| A. Git 同步 | `git fetch` → 當前分支不在遠端則切換 develop（再退而 master）→ `git pull` → 若有衝突則告知並嘗試解衝突 |
+| A. Git 同步 | `git fetch` → 當前分支不在遠端則切換 develop（再退而 master）→ `git pull`／必要時解衝突 → 若目前分支與遠端同名則建立新工作分支 |
 | B. 解決問題 | 讀 `findings.json` / `exclusions.json` → 依等級 🔴→🟠→🟡→🔵 逐條修復或判斷誤報 → 已解決者自 `findings.json` 移除，誤報寫入 `exclusions.json` 後也可移除；**無待處理問題則跳到階段 D** |
 | C. 分類提交 | 分析工作區所有變更 → 依 feat/fix/docs/style/refactor/perf/test/chore/revert 分組 → 各組一個 commit |
 | D. Push 當前分支 | 認證管理器 → 失敗改 token → 再失敗詢問使用者；**無 commit 可 push 則跳到階段 E** |
@@ -77,7 +77,7 @@ current_branch="$(git rev-parse --abbrev-ref HEAD)"
 git rev-parse --verify --quiet "origin/${current_branch}"
 ```
 
-- **`origin/<current_branch>` 存在** → 維持當前分支，直接進入 A4 更新到最新。
+- **`origin/<current_branch>` 存在** → 維持當前分支，直接進入 A4 更新到最新；此分支視為遠端同名基準分支，A5 必須從它建立新的工作分支，避免後續修復 commit 直接落在同名遠端分支上。
 - **`origin/<current_branch>` 不存在**（當前分支為本地獨有，遠端無對應）→ 依序嘗試切換到後備分支：
   1. 切換前先確認工作區可安全切換（承接 A1 結果）。若有未提交變更導致切換失敗，停止並回報，請使用者先處理未提交變更；不可強制丟棄。
   2. 若 `origin/develop` 存在 → 切換到 `develop`：
@@ -93,7 +93,7 @@ git rev-parse --verify --quiet "origin/${current_branch}"
      ```
 
   4. **`develop` 與 `master` 在遠端都不存在** → 回報「當前分支不在遠端，且找不到 develop／master 後備分支」並停止，不臆測其他分支。
-- 切換完成後，後續階段（含 push 與開 PR 的來源分支）都以切換後的分支為準；切換到後備分支屬不可忽略的狀態變更，需在輸出中明確告知使用者已從原分支切換到哪一個分支。
+- 切換完成後，A4 先更新該後備分支到最新，A5 再建立新的工作分支；切換到後備分支屬不可忽略的狀態變更，需在輸出中明確告知使用者已從原分支切換到哪一個分支。
 
 ### A4. Pull（更新到最新）
 
@@ -103,11 +103,33 @@ git rev-parse --verify --quiet "origin/${current_branch}"
 git pull
 ```
 
-- pull 成功後進入階段 B。
+- pull 成功後進入 A5，必要時建立新的工作分支，再進入階段 B。
 - 若顯示需要指定 merge / rebase 策略，先回報原因；未帶 `--yes` 時詢問使用者要採用哪種策略，不可自行猜測。
-- 若 pull 產生衝突，立即告知使用者發生衝突，接著依階段 A5 嘗試解衝突。
+- 若 pull 產生衝突，立即告知使用者發生衝突，接著依階段 A6 嘗試解衝突。
 
-### A5. 必要時嘗試解衝突
+### A5. 若目前分支與遠端同名，建立新的工作分支
+
+A4 更新完成後，再次確認目前分支與遠端分支的關係：
+
+```bash
+base_branch="$(git rev-parse --abbrev-ref HEAD)"
+git rev-parse --verify --quiet "origin/${base_branch}"
+```
+
+- **若 `origin/<base_branch>` 存在**（目前分支名稱與遠端分支名稱相同）→ 不在該分支上直接修復／commit。從目前已更新到最新的基準分支建立新的工作分支，後續階段（修復、commit、push、PR 的 `head`）都以新分支為準。
+- 新分支名稱需可讀且避免覆蓋既有分支；預設格式：
+
+  ```bash
+  work_branch="ai-review-resolve/${base_branch}-$(date +%Y%m%d-%H%M%S)"
+  git switch -c "${work_branch}"
+  ```
+
+- 建立前若本地或遠端已存在同名分支，換一個時間戳或短 hash，不可覆蓋既有分支。
+- 若因未提交變更導致建立／切換新分支失敗，停止並回報，請使用者先處理未提交變更；不可強制丟棄。
+- 建立新分支屬不可忽略的狀態變更，需在輸出中明確告知使用者「已從 `<base_branch>` 建立並切換到 `<work_branch>`」。
+- **若 `origin/<base_branch>` 不存在**（目前已在本地獨有工作分支）→ 維持目前分支，不另開分支。
+
+### A6. 必要時嘗試解衝突
 
 當 `git pull` 後出現衝突：
 
@@ -115,7 +137,7 @@ git pull
 2. 讀取衝突檔脈絡，依專案現有行為與遠端變更做最小合理整合。
 3. 可安全解決的衝突：編輯檔案移除衝突標記，執行 `git add -- <檔案...>` 標記已解決。
 4. 無法安全判斷的衝突：停止處理，列出檔案、衝突原因與需要使用者決策的點；不要硬選任一邊。
-5. 全部衝突解完後，依 git 當前狀態完成 merge / rebase 的必要步驟，確認 `git status --porcelain` 沒有未解衝突，再進入階段 B。
+5. 全部衝突解完後，依 git 當前狀態完成 merge / rebase 的必要步驟，確認 `git status --porcelain` 沒有未解衝突，再回到 A5 建立必要的新工作分支。
 
 ---
 
@@ -414,7 +436,7 @@ curl -sS -X POST \
 
 各階段執行後輸出：
 
-- **階段 A**：git fetch / pull 是否成功、當前分支是否存在於遠端（不存在時切到 develop／master 的結果）、是否發生衝突、衝突是否已解決或仍需人工處理。
+- **階段 A**：git fetch / pull 是否成功、當前分支是否存在於遠端（不存在時切到 develop／master 的結果）、若分支與遠端同名是否已建立新工作分支、是否發生衝突、衝突是否已解決或仍需人工處理。
 - **階段 B**：已解決 N 條（依等級分佈）、誤報寫入 exclusions M 條、待人工處理 K 條（列出原因）、`findings.json` 保留／移除筆數與 `exclusions.json` 新增筆數；若無待處理問題，說明已跳過階段 C 直接進入階段 D。
 - **階段 C**：建立了哪幾個 commit（type＋訊息＋檔數），或為何略過（`--no-commit` / 無變更）。
 - **階段 D**：push 成功與否、用了哪種方式（認證管理器／token／使用者指定），遠端分支名；若無 commit 可 push，說明已跳過 push 直接進入階段 E。