code-review/skills/code-review-resolve/SKILL.md

---

name: code-review-resolve description: 讀取工作目錄 .gitea/ai-review/findings.json（Gitea AI review 產出的問題清單），依嚴重等級（🔴 嚴重→🟠 高→🟡 中→🔵 低）由高到低逐條解決程式碼問題；全部解完後把 .gitea/ai-review/findings.json 清空為空陣列 []。接著做 git 處理：分析工作區內所有檔案變更，依異動內容歸類為 feat/fix/docs/style/refactor/perf/test/chore/revert，分門別類各自 commit，commit 訊息為「type(中文範圍): 一句總結」格式（例 feat(新增功能): 新增使用者登入流程、perf(優化效能): 改用批次查詢降低 DB 往返）。當使用者說解決 findings、處理 AI review 問題、修掉 .gitea/ai-review 的問題、依嚴重度逐條修復後分類提交、或要把工作區變更依 conventional commit 分類 commit 時觸發。不適用於：產生 findings（那是 Gitea AI review CI 或 /jsc:code-review 的工作）、單純審查不修改、或不分類的單一 commit。 argument-hint: "[--findings <findings.json 路徑>] [--no-commit] [--yes]"

code-review-resolve — 解決 AI review findings 並分類提交

兩階段 skill：先逐條修掉 .gitea/ai-review/findings.json 裡的問題並清空該檔，再把工作區所有變更依 conventional commit 類型分門別類 commit。

階段	動作
A. 解決問題	讀 findings.json → 依等級 🔴→🟠→🟡→🔵 逐條修復程式碼 → 清空 findings.json 為 []
B. 分類提交	分析工作區所有變更 → 依 feat/fix/docs/style/refactor/perf/test/chore/revert 分組 → 各組一個 commit

---

輸出規範（務必遵守）

• 語言：所有面向使用者的輸出（修復清單、提交計畫、總結、反問）與 commit 訊息 一律使用繁體中文（台灣用語）； 僅程式碼識別字、檔名、git 指令、conventional commit 的 type（feat/fix…）等技術標識保留原文，不可使用簡體字。
• 編碼無亂碼：讀寫檔案一律 UTF-8（不含 BOM）；清空後的 findings.json 與所有 commit 訊息確保中文、全形標點與等級 emoji（🔴🟠🟡🔵）正常顯示，不得出現問號方框或錯碼。
• 修改程式碼與 commit 屬於更動專案的行為：除非帶 --yes 或使用者已明確授權，否則每階段動手前先輸出計畫（預覽）並取得同意；使用者拒絕則只輸出計畫、不動檔不提交。

---

參數

格式：[--findings <路徑>] [--no-commit] [--yes]

• --findings <路徑>：findings 檔路徑。省略時預設 .gitea/ai-review/findings.json（相對於工作目錄根）。
• --no-commit：只做階段 A（修復 + 清空 findings），不執行階段 B 的 commit。
• --yes：略過各階段的同意確認，直接執行（修復、清空、commit 一氣呵成）。未帶時每階段先預覽再確認。

---

階段 A：依嚴重等級逐條解決問題

A1. 讀取 findings

讀 --findings 指定（或預設 .gitea/ai-review/findings.json）的檔案，內容為 top-level JSON 陣列，每筆是一個問題物件。常見欄位（不同產生器命名略有差異，需容錯對應）：

語義	可能欄位名
嚴重等級	severity / level / 等級
檔案位置	file / path / 檔案位置
所在行數	line / lines / 所在行數
問題標題	title / message / 問題
問題描述	description / detail / 描述
修正建議	suggestion / fix / 建議

• 檔案不存在、內容為 [] 或空白 → 視為「無問題待解決」，輸出告知並直接跳到階段 B（仍會把工作區既有變更分類提交，除非 --no-commit）。
• JSON 解析失敗 → 回報錯誤與檔案路徑並停止，不臆測內容、不亂改檔。

A2. 依嚴重等級排序

把所有 finding 依等級由高到低排序：🔴 嚴重 → 🟠 高 → 🟡 中 → 🔵 低。 英文／其他寫法對應：critical/blocker→🔴、high/major→🟠、medium/moderate→🟡、low/minor/info→🔵；無法辨識的等級排在最後並標註「等級未知」。

A3. 逐條修復（高等級先）

輸出一張「修復計畫」表並（未帶 --yes 時）請使用者確認後，依排序由上而下逐條處理：

#	等級	問題	檔案位置	行數	修復方式

對每一條 finding：

1. 讀取對應檔案與其脈絡（依 file / line）。
2. 依 suggestion／description 在程式碼中實作修正；建議含糊或與現況不符時，依原始碼脈絡做最小且合理的修正。
3. 無法安全自動修復（例如需求不明、牽涉設計取捨、檔案不存在）→ 不硬改，標記為「待人工處理」並記錄原因，繼續下一條。
4. 逐條完成後，記錄該條結果（✅ 已修復 / ⏭️ 待人工處理 + 原因）。

一次只處理一條、修完再處理下一條，避免互相干擾；同檔多條問題可合併讀取但仍逐條套用修正。

A4. 清空 findings.json

所有可修復條目處理完畢後，把 findings.json 內容覆寫為空陣列：

[]

• 以 UTF-8（不含 BOM）寫入，結尾保留一個換行。
• 若仍有「待人工處理」條目：先回報這些條目，詢問使用者是否仍要清空（清空代表這些問題不再留在檔案中）。未帶 --yes 且使用者未同意 → 保留這些條目於檔案、只移除已修復的條目，並在總結說明。

---

階段 B：分析變更並分類提交（--no-commit 時略過）

B1. 盤點工作區變更

git status --porcelain
git diff            # 已追蹤檔的未暫存變更
git diff --staged   # 已暫存變更

涵蓋所有變更：已修改、新增（未追蹤）、刪除、改名。無任何變更 → 回報「工作區無變更可提交」並結束。

B2. 依異動內容歸類 conventional commit 類型

逐一檢視每個變更檔的實際異動內容（不只看路徑），歸入下列其一：

type	適用情境
feat	新增功能／新行為／新 API／新 skill
fix	修正錯誤、修掉 bug（階段 A 的 bug 修復多半歸此）
docs	只改文件（README、註解、*.md、說明）
style	不影響邏輯的格式調整（排版、空白、分號、命名一致化）
refactor	重構：不改外部行為的內部結構調整
perf	效能優化
test	新增或修改測試
chore	雜項：建置、設定、相依套件、版本號 bump、忽略檔等
revert	還原先前的提交

• 同一檔案橫跨多型 → 以該檔主要異動性質歸類；難以拆分時就近歸入影響最大的一類，並在總結註記。
• 階段 A 修復產生的變更：依其性質歸類（修 bug→fix、補功能→feat、改文件→docs…）。findings.json 被清空這項異動歸 chore。

B3. 產出提交計畫並確認

把變更檔依 type 分組，每個 type 一個 commit，輸出提交計畫供確認（未帶 --yes 時）：

順序	type(範圍)	commit 訊息	納入檔案

• commit 訊息格式：type(中文範圍): 一句總結 —
  • type：上表英文類型。
  • 中文範圍：一個簡短的繁體中文範圍／類別詞，描述這組異動的領域，例如 新增功能、修正錯誤、優化效能、文件、重構、測試、雜項。
  • 一句總結：把這個 commit 內所有異動總結成一句繁體中文（簡短、聚焦做了什麼）。
  • 範例：feat(新增功能): 新增使用者登入流程、fix(修正錯誤): 修正空值導致的結帳例外、perf(優化效能): 改用批次查詢降低 DB 往返、docs(文件): 補上安裝與呼叫方式說明、chore(雜項): bump 版本並清空 findings.json。
• 提交順序建議：fix/feat 等核心異動在前，docs/style/chore 在後（純屬建議，可依相依性調整）。

B4. 執行分類提交

對每組依序：

git add -- <該組檔案...>       # 僅暫存該組檔案，逐組精準 add
git commit -m "type(中文範圍): 一句總結"

• 逐組 add／commit，確保每個 commit 只含該類異動；不要一次 git add -A 再混在一起。
• 改名／刪除檔一併納入對應組的 git add（git add -A -- <路徑> 或明確列出）。
• 不自動 git push、不開 PR（除非使用者另外要求）。

---

總結

提交完成後輸出：

• 階段 A：已修復 N 條（依等級分佈）、待人工處理 M 條（列出原因）、findings.json 是否已清空。
• 階段 B：建立了哪幾個 commit（type＋訊息＋檔數），或為何略過（--no-commit / 無變更）。
• 提醒尚未 push；如需上 PR 由使用者決定。

---

呼叫方式

格式：[--findings <路徑>] [--no-commit] [--yes] — 全部可省略（findings 預設 .gitea/ai-review/findings.json）。

助理	呼叫
Claude Code / Antigravity	/jsc:code-review-resolve，或 /jsc:code-review-resolve --findings .gitea/ai-review/findings.json --yes、/jsc:code-review-resolve --no-commit
Codex	$code-review-resolve，或 $code-review-resolve --findings .gitea/ai-review/findings.json --yes，或用 /skills 選單
OpenCode	描述需求（如「讀 .gitea/ai-review/findings.json 依嚴重度逐條修好，清空該檔，再把工作區變更依 conventional commit 分類提交」）自動觸發