refactor(code): 接上 shared 共用規範，去除重抄段落並補模型檢查串接
依 todo.md 執行的規範治理專案：action-composite／action-docker／action-node／ image／issues／nuget／review-resolve／sync／target 九個 skill 改為引用 shared 新增的共用 spec（conventional-commit、pull-request、git-push、 git-safety 分支選擇、issue-read、todo-list、ask-user、action-scaffold、 node-src-layout、skill-invocation），移除大量重抄內容（review-resolve／ target 光是 commit/PR/push 三塊就精簡約 175 行）；target／issues 補上讀到 帶 model: frontmatter 清單檔時依 /jsc-shared:spec-model 做模型檢查的規則。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
Claude Sonnet 5
+30
-166
@@ -18,14 +18,11 @@ argument-hint: "[--issue <編號|編號清單|all>] [--findings <findings 檔或
|
||||
|
||||
---
|
||||
|
||||
## 共用規範（shared plugin，必要前置）
|
||||
## 共用規範（必要前置）
|
||||
|
||||
執行本 skill 前，先以 Skill 工具載入下列共用規範並全程遵守；**任一載入不到（shared plugin 未安裝）時，先詢問使用者是否安裝 shared plugin（`https://gitea.jsc.idv.tw/plugins/shared.git`），使用者不安裝則直接中斷本 skill**，不得只憑下方一行摘要繼續執行：
|
||||
|
||||
- `/jsc-shared:spec-output`：繁體中文（台灣用語）、UTF-8（不含 BOM）無亂碼（含 commit 訊息、PR 標題／描述、寫檔／API body 實作要點與送出前自我檢查）。
|
||||
- `/jsc-shared:spec-execution`：自動執行原則（必要決策才中斷）、不臆測／需人工確認。
|
||||
- `/jsc-shared:spec-gitea`：`GITEA_TOKEN` 機密保護（不 echo、遮蔽 `***`）、API body 以 UTF-8 JSON 檔帶入。
|
||||
- `/jsc-shared:spec-git-safety`：不破壞既有工作、develop → master 後備、保守解衝突、新分支不覆蓋既有分支。
|
||||
先載入 `/jsc-shared:spec-preflight` 並依其流程處理；載入不到即代表 shared plugin 未安裝，
|
||||
依該 spec 詢問使用者是否安裝 `https://gitea.jsc.idv.tw/plugins/shared.git`，不安裝則中斷本 skill。
|
||||
本 skill 需要的規範：`spec-output`、`spec-execution`、`spec-gitea`、`spec-git-safety`、`spec-issue-read`、`spec-conventional-commit`、`spec-git-push`、`spec-pull-request`、`spec-skill-invocation`
|
||||
|
||||
本 skill 特有補充：
|
||||
|
||||
@@ -82,21 +79,7 @@ git rev-parse --verify --quiet "origin/${current_branch}"
|
||||
```
|
||||
|
||||
- **`origin/<current_branch>` 存在** → 維持當前分支，直接進入 A4 更新到最新；不要只因目前分支有遠端同名分支就建立新工作分支，後續只有來源分支與 PR 目標分支相同時才需要開新分支。
|
||||
- **`origin/<current_branch>` 不存在**（當前分支為本地獨有，遠端無對應）→ 依序嘗試切換到後備分支：
|
||||
1. 切換前先確認工作區可安全切換（承接 A1 結果）。若有未提交變更導致切換失敗，停止並回報，請使用者先處理未提交變更；不可強制丟棄。
|
||||
2. 若 `origin/develop` 存在 → 切換到 `develop`：
|
||||
|
||||
```bash
|
||||
git switch develop 2>/dev/null || git switch -c develop --track origin/develop
|
||||
```
|
||||
|
||||
3. 否則若 `origin/master` 存在 → 切換到 `master`：
|
||||
|
||||
```bash
|
||||
git switch master 2>/dev/null || git switch -c master --track origin/master
|
||||
```
|
||||
|
||||
4. **`develop` 與 `master` 在遠端都不存在** → 回報「當前分支不在遠端，且找不到 develop／master 後備分支」並停止，不臆測其他分支。
|
||||
- **`origin/<current_branch>` 不存在**（當前分支為本地獨有，遠端無對應）→ 切換前先確認工作區可安全切換（承接 A1 結果，若有未提交變更導致切換失敗，停止並回報，請使用者先處理未提交變更；不可強制丟棄），再依 `/jsc-shared:spec-git-safety`「develop → master 後備分支」切換到後備分支；develop／master 在遠端都不存在時，依該規範回報並停止，不臆測其他分支。
|
||||
- 切換完成後，A4 先更新該後備分支到最新；是否建立新的工作分支交由 A5 依來源分支與 PR 目標分支是否相同判斷。切換到後備分支屬不可忽略的狀態變更，需在輸出中明確告知使用者已從原分支切換到哪一個分支。
|
||||
|
||||
### A4. Pull（更新到最新）
|
||||
@@ -121,16 +104,13 @@ source_branch="$(git rev-parse --abbrev-ref HEAD)"
|
||||
```
|
||||
|
||||
- **若後續會建立 PR（未帶 `--no-pr`）且尚未知道目標分支** → 先依階段 E1 的規則詢問目標分支，避免後續修復 commit 落在與 PR 目標同名的來源分支上才發現 source/base 相同。若帶 `--no-pr`，此階段不因缺少目標分支而詢問。
|
||||
- **若來源分支名稱與目標分支相同** → 不在該分支上直接修復／commit，也不可後續直接建立 head=base 的 PR。從目前已更新到最新的目標分支建立新的工作分支，後續階段（修復、commit、push、PR 的 `head`）都以新分支為準。
|
||||
- **若來源分支名稱與目標分支不同** → 維持目前分支，不另開分支；即使目前分支存在 `origin/<source_branch>`，也照常在目前分支處理。
|
||||
- 新分支名稱需可讀且避免覆蓋既有分支；預設格式：
|
||||
- 是否需要建立新的工作分支、判斷方式（只有同名才開新分支）與命名避免覆蓋既有分支，依 `/jsc-shared:spec-git-safety`「工作分支選擇」與「建立分支不覆蓋」執行；本 skill 新工作分支預設命名：
|
||||
|
||||
```bash
|
||||
work_branch="ai-review-resolve/${source_branch}-$(date +%Y%m%d-%H%M%S)"
|
||||
git switch -c "${work_branch}"
|
||||
```
|
||||
|
||||
- 建立前若本地或遠端已存在同名分支，換一個時間戳或短 hash，不可覆蓋既有分支。
|
||||
- 若因未提交變更導致建立／切換新分支失敗，停止並回報，請使用者先處理未提交變更；不可強制丟棄。
|
||||
- 建立新分支屬不可忽略的狀態變更，需在輸出中明確告知使用者「因來源分支與目標分支同名，已從 `<source_branch>` 建立並切換到 `<work_branch>`」。
|
||||
|
||||
@@ -216,15 +196,7 @@ source_branch="$(git rev-parse --abbrev-ref HEAD)"
|
||||
|
||||
1. 解析 repo 座標（同 E3），token 由 `GITEA_TOKEN` 提供。
|
||||
2. `all` 時先取所有 open 議題（分頁全取）：`GET /repos/<owner>/<repo>/issues?state=open&type=issues`。
|
||||
3. 對每個選定議題讀本文與全部留言（分頁全取；輸出遮蔽 token）：
|
||||
|
||||
```bash
|
||||
curl -sS -H "Authorization: token ${GITEA_TOKEN}" \
|
||||
"https://<host>/api/v1/repos/<owner>/<repo>/issues/<編號>"
|
||||
curl -sS -H "Authorization: token ${GITEA_TOKEN}" \
|
||||
"https://<host>/api/v1/repos/<owner>/<repo>/issues/<編號>/comments"
|
||||
```
|
||||
|
||||
3. 對每個選定議題讀取本文、全部留言與全部附件，依 `/jsc-shared:spec-issue-read` 執行（分頁完整讀取、不得只取部分留言；輸出遮蔽 token）；議題標題／描述與附件內容作為整體背景脈絡納入判斷，本階段只從留言中解析下列嚴重問題留言格式。
|
||||
4. 解析每則符合「嚴重問題留言」格式（action `severeCommentBody` 產出）的留言為一條 finding：
|
||||
|
||||
```
|
||||
@@ -238,7 +210,7 @@ source_branch="$(git rev-parse --abbrev-ref HEAD)"
|
||||
<suggestedCode>
|
||||
```
|
||||
|
||||
映射為 `{ reviewer, severity, file, startLine, endLine, problem, suggestion, suggestedCode }`，並記住**來源議題編號與留言 id**（供 B6 回寫）；議題標題／描述作為整體背景脈絡納入判斷。
|
||||
映射為 `{ reviewer, severity, file, startLine, endLine, problem, suggestion, suggestedCode }`，並記住**來源議題編號與留言 id**（供 B6 回寫）。
|
||||
5. 某議題解析不到任何嚴重問題留言 → 記錄並略過該議題（`all`／多選時不因單一議題無問題而中斷整批），不臆測。
|
||||
|
||||
**B1c. 合併去重**
|
||||
@@ -325,76 +297,19 @@ source_branch="$(git rev-parse --abbrev-ref HEAD)"
|
||||
|
||||
## 階段 C：分析變更並分類提交（`--no-commit` 時略過）
|
||||
|
||||
### C1. 盤點工作區變更
|
||||
依 `/jsc-shared:spec-conventional-commit` 完整盤點工作區變更（含所有已暫存／未暫存／未追蹤／改名／刪除檔案，一律以 `git status --porcelain=v1 -uall` 為主，`git diff` 只作輔助核對）、依實際異動內容歸類為 9 種 commit type、產出提交計畫，再逐組精準 `git add -- <路徑>`（不用 `git add -A`／`git add .`）後分別 `git commit -m "type(範圍): 一句總結"`。
|
||||
|
||||
```bash
|
||||
git status --porcelain=v1 -uall
|
||||
git diff # 已追蹤檔的未暫存變更
|
||||
git diff --staged # 已暫存變更
|
||||
git ls-files --others --exclude-standard # 未追蹤檔
|
||||
```
|
||||
本 skill 特有補充：
|
||||
|
||||
盤點時必須以 `git status --porcelain=v1 -uall` 為主，不可只看 `git diff`，因為那會漏掉未追蹤檔。盤點範圍必須包含**所有**變更：已修改檔、新增檔（`??` 未追蹤檔）、刪除檔、改名檔，以及已暫存與未暫存變更。`git diff`、`git diff --staged`、`git ls-files --others --exclude-standard` 只作為輔助核對。**無任何變更** → 回報「工作區無變更可提交」，跳過提交直接進入階段 D（D 會因無 commit 可 push 而跳到階段 E）。
|
||||
|
||||
### C2. 依異動內容歸類 conventional commit 類型
|
||||
|
||||
逐一檢視每個變更檔的**實際異動內容**（不只看路徑），歸入下列其一；**所有 `??` 未追蹤檔都必須納入分類**，不能因為它們不在 `git diff` 裡就漏掉：
|
||||
|
||||
| type | 適用情境 |
|
||||
| --- | --- |
|
||||
| `feat` | 新增功能／新行為／新 API／新 skill |
|
||||
| `fix` | 修正錯誤、修掉 bug（**階段 B 的 bug 修復多半歸此**） |
|
||||
| `docs` | 只改文件（README、註解、`*.md`、說明） |
|
||||
| `style` | 不影響邏輯的格式調整（排版、空白、分號、命名一致化） |
|
||||
| `refactor` | 重構：不改外部行為的內部結構調整 |
|
||||
| `perf` | 效能優化 |
|
||||
| `test` | 新增或修改測試 |
|
||||
| `chore` | 雜項：建置、設定、相依套件、版本號 bump、忽略檔等 |
|
||||
| `revert` | 還原先前的提交 |
|
||||
|
||||
- **同一檔案橫跨多型** → 以該檔**主要異動性質**歸類；難以拆分時就近歸入影響最大的一類，並在總結註記。
|
||||
- **階段 B 修復產生的變更**：依其性質歸類（修 bug→`fix`、補功能→`feat`、改文件→`docs`…）。`.gitea/ai-review/findings/` 目錄下 `*.json`（wrapper）與 `exclusions.json` 的問題狀態更新歸 `chore`。
|
||||
- **未追蹤新檔**：必須照實際內容歸入對應 type，必要時在提交前明確 `git add -- <path>`，不可因為是新檔就略過。
|
||||
|
||||
### C3. 產出提交計畫
|
||||
|
||||
把變更檔依 type 分組，**每個 type 一個 commit**，輸出提交計畫；**所有變更項目都必須被追蹤並納入計畫，不能遺漏任何 `??` 未追蹤檔**。除非使用者要求確認或分組有不可忽略的取捨，否則直接提交：
|
||||
|
||||
| 順序 | type(範圍) | commit 訊息 | 納入檔案 |
|
||||
| --- | --- | --- | --- |
|
||||
|
||||
- **commit 訊息格式**：`type(範圍): 一句總結` —
|
||||
- `type`：上表英文類型。
|
||||
- `範圍`（括號內）：**必須是這組異動實際牽涉的功能／模組／元件名稱**，而**不是**重述 type 的類別詞。
|
||||
取名規則：優先沿用程式碼／專案中既有的識別名（檔名、模組名、skill 名、功能名，可中可英、保持與原碼一致），讓人一眼看出「改到哪個東西」。
|
||||
- ✅ 對：`feat(使用者登入)`、`fix(結帳流程)`、`perf(物件查詢)`、`docs(README)`、`refactor(訂單服務)`、`chore(plugin 版本)`、`feat(review-resolve)`。
|
||||
- ❌ 錯（只是重述 type，禁止）：`feat(新增功能)`、`fix(修正錯誤)`、`perf(優化效能)`、`docs(文件)`、`chore(雜項)`。
|
||||
- 一組異動橫跨多個功能而無單一主體時，才退而取最貼近的上層範圍（例如多個 manifest → `plugin 設定`）。
|
||||
- `一句總結`：把這個 commit 內所有異動**總結成一句**繁體中文（簡短、聚焦做了什麼）。
|
||||
- 範例：`feat(使用者登入): 新增帳密登入與 token 簽發`、`fix(結帳流程): 修正空購物車導致的結帳例外`、`perf(物件查詢): 改用批次查詢降低 DB 往返`、`docs(README): 補上安裝與呼叫方式說明`、`chore(ai-review 狀態): 更新 findings 與 exclusions.json`。
|
||||
- **提交順序建議**：`fix`/`feat` 等核心異動在前，`docs`/`style`/`chore` 在後（純屬建議，可依相依性調整）。
|
||||
- **盤點要求**：提交計畫必須完整對應 C1 盤點出的所有變更項目，若有新檔或未追蹤檔，必須明確列入對應 commit，不能只根據 `git diff` 下結論。
|
||||
|
||||
### C4. 執行分類提交
|
||||
|
||||
對每組依序：
|
||||
|
||||
```bash
|
||||
git add -- <該組檔案...> # 僅暫存該組檔案，逐組精準 add
|
||||
git commit -m "type(範圍): 一句總結" # 範圍＝實際異動的功能／模組名
|
||||
```
|
||||
|
||||
- **逐組 add／commit**，確保每個 commit 只含該類異動；不要一次 `git add -A` 再混在一起。
|
||||
- 改名／刪除檔一併納入對應組的 `git add`（`git add -A -- <路徑>` 或明確列出）。
|
||||
- **所有 `??` 未追蹤檔都必須納入提交**；若是新檔，必要時要明確執行 `git add -- <path>`，不可漏掉。
|
||||
- **不可只根據 `git diff` 判斷變更**；C1 盤點出的所有異動都必須反映到分類與提交，否則視為提交計畫不完整。
|
||||
- **階段 B 產生的變更歸類**：修 bug→`fix`、補功能→`feat`、改文件→`docs`…；`.gitea/ai-review/findings/` 目錄下 `*.json`（wrapper）與 `exclusions.json` 的問題狀態更新一律歸 `chore`。
|
||||
- **無任何變更** → 回報「工作區無變更可提交」，跳過提交直接進入階段 D（D 會因無 commit 可 push 而跳到階段 E）。
|
||||
- commit 完成後進入階段 D（push）。`--no-commit` 時不進入後續階段；若工作區無變更而沒有產生任何新 commit，仍進入階段 D，由 D 判斷無 commit 可 push 後跳到階段 E。
|
||||
|
||||
---
|
||||
|
||||
## 階段 D：Push 當前分支（`--no-commit` 時略過；無 commit 可 push 時跳到階段 E）
|
||||
|
||||
commit 完成後推送**當前分支**，依序嘗試三種方式，前者失敗才退到下一個：
|
||||
commit 完成後推送**當前分支**，憑證選擇的三段式流程（認證管理器 → token push → 詢問使用者，前者失敗才退到下一個；token 全程遮蔽、用完即棄不落地）依 `/jsc-shared:spec-git-push` 執行。
|
||||
|
||||
推送前先記錄目前來源分支與其遠端基準，並確認是否有 commit 需要 push：
|
||||
|
||||
@@ -409,24 +324,6 @@ git log --oneline "origin/${source_branch}..${source_branch}" # 領先遠端
|
||||
- 若後續會建立 PR（未帶 `--no-pr`）且尚未知道目標分支，先依階段 E1 的規則詢問目標分支，這屬於不可忽略的必要決策。
|
||||
- 若來源分支名稱與目標分支相同，**不要 push 原來源分支**；記下來源分支與遠端基準，直接進入階段 E，由 E2 建立新的 PR 來源分支、帶入 commit 後再 push 新分支。
|
||||
|
||||
1. **認證管理器（優先）**：直接用 git 既有的 credential helper（如 Windows 的 `manager-core`）：
|
||||
|
||||
```bash
|
||||
git push -u origin "$(git rev-parse --abbrev-ref HEAD)"
|
||||
```
|
||||
|
||||
2. **失敗 → 改用 token push**：從環境變數讀 token，組帶 token 的遠端 URL 推送。**整個過程不可把含 token 的指令／URL 印出來**（用變數帶入、輸出時遮蔽）：
|
||||
|
||||
```bash
|
||||
# GITEA_TOKEN 來自環境變數；解析 origin 的 host/owner/repo
|
||||
git push "https://oauth2:${GITEA_TOKEN}@<host>/<owner>/<repo>.git" \
|
||||
"$(git rev-parse --abbrev-ref HEAD)"
|
||||
```
|
||||
|
||||
（token 用完即棄，不寫進 git remote 設定、不落地。）
|
||||
|
||||
3. **再失敗 → 詢問使用者要如何 push**：列出失敗原因（遮蔽 token），請使用者指示推送方式，**不可自行猜測**其他憑證或來源。
|
||||
|
||||
push 成功後記下遠端分支名，進入階段 E。若因來源分支與目標分支相同而延後 push，記下原因並進入階段 E2 建立新分支。
|
||||
|
||||
---
|
||||
@@ -437,9 +334,9 @@ push 成功後記下遠端分支名，進入階段 E。若因來源分支與目
|
||||
|
||||
- 帶 `--target <分支>` → 直接採用。
|
||||
- 若階段 D 已為了避免 source/base 相同而詢問過目標分支，沿用該目標分支。
|
||||
- **否則必須詢問使用者目標分支**（可用 `git branch -r` 列出輔助選擇），**嚴禁臆測或預設**（不可自行假設 develop／main／master）。
|
||||
- **否則**依 `/jsc-shared:spec-pull-request`「目標分支不得臆測」詢問使用者（可用 `git branch -r` 列出輔助選擇），嚴禁臆測或預設。
|
||||
|
||||
### E2. 若來源分支與目標分支相同，改建 PR 來源分支
|
||||
### E2. 若來源分支與目標分支相同，改建 PR 來源分支（cherry-pick 帶入已提交的異動）
|
||||
|
||||
先取得目前 PR 來源分支：
|
||||
|
||||
@@ -447,7 +344,7 @@ push 成功後記下遠端分支名，進入階段 E。若因來源分支與目
|
||||
git rev-parse --abbrev-ref HEAD
|
||||
```
|
||||
|
||||
若來源分支名稱與 `--target` 指定（或使用者選定）的目標分支相同，**不可直接建立 head=base 的 PR，也不可先把原來源分支 push 到目標分支**。改用下列流程建立新的 PR 來源分支，並把原來源分支的 commit 帶入後再開 PR：
|
||||
若來源分支名稱與 `--target` 指定（或使用者選定）的目標分支相同，依 `/jsc-shared:spec-git-safety`「工作分支選擇」，**不可直接建立 head=base 的 PR，也不可先把原來源分支 push 到目標分支**。此處的情境是修復與 commit 已經發生在這個（事後才發現同名的）來源分支上，因此改用下列流程建立新的 PR 來源分支，把原來源分支的 commit cherry-pick 帶入後再開 PR：
|
||||
|
||||
1. 先記錄原來源分支名稱與要帶入的 commit 清單：
|
||||
|
||||
@@ -460,7 +357,7 @@ git rev-parse --abbrev-ref HEAD
|
||||
- 若沒有任何 commit 可帶入，回報「來源分支沒有領先目標分支的 commit」，停止開 PR。
|
||||
- 若階段 D 已記錄來源分支的遠端基準，使用該基準判斷要帶入的 commit，避免把原來源分支直接推進目標分支。
|
||||
|
||||
2. 從目標分支的遠端基準建立新分支。新分支名稱需可讀且避免覆蓋既有分支，例如：
|
||||
2. 從目標分支的遠端基準建立新分支，命名依 `/jsc-shared:spec-git-safety`「建立分支不覆蓋」避免覆蓋既有分支，例如：
|
||||
|
||||
```bash
|
||||
git switch -c "ai-review-resolve/<短時間戳>" "origin/${target}"
|
||||
@@ -472,60 +369,27 @@ git rev-parse --abbrev-ref HEAD
|
||||
git cherry-pick "origin/${target}..${source_branch}"
|
||||
```
|
||||
|
||||
- cherry-pick 發生衝突時，先告知使用者，再依專案脈絡嘗試最小合理解衝突。
|
||||
- 可安全解決的衝突：移除衝突標記、`git add -- <檔案...>`，再繼續 `git cherry-pick --continue`。
|
||||
- 無法安全判斷的衝突：停止處理，列出衝突檔案與需要使用者決策的點；不要硬選任一邊。
|
||||
衝突時依 `/jsc-shared:spec-git-safety`「保守解衝突」處理（先告知使用者、依專案脈絡嘗試最小合理整合；可安全解決者移除衝突標記、`git add -- <檔案...>` 後 `git cherry-pick --continue`；無法安全判斷者停止並列出決策點，不硬選任一邊）。
|
||||
|
||||
4. 將新分支 push 到遠端，使用階段 D 的同一套 push 憑證策略，並把後續 PR 的 `head` 改為這個新分支。
|
||||
4. 將新分支 push 到遠端，憑證策略依 `/jsc-shared:spec-git-push`（同階段 D），並把後續 PR 的 `head` 改為這個新分支。
|
||||
|
||||
若來源分支與目標分支不同，直接以目前分支作為 PR 的 `head`。
|
||||
|
||||
### E3. 解析 repo 座標
|
||||
|
||||
從 `git remote get-url origin` 解析出 **host／owner／repo**（例：`https://gitea.jsc.idv.tw/plugins/code-review.git` → host=`gitea.jsc.idv.tw`、owner=`plugins`、repo=`code-review`）。
|
||||
依 `/jsc-shared:spec-pull-request`「解析 origin 座標」從 `git remote get-url origin` 解析出 host／owner／repo。
|
||||
|
||||
### E4. 決定 PR 描述形式（完整版／簡單版／使用者輸入）
|
||||
|
||||
依 `--pr-desc` 三選一；若未提供則預設使用 `full`，不要為描述形式中斷詢問：
|
||||
|
||||
- **完整版（`full`）**：**重新分析並總結** `git diff <target>...<PR 來源分支>`（比對 source 自分岔點以來的變更），整理成結構化繁體中文說明 —— 變更摘要、影響範圍、重點檔案／模組、風險或注意事項。不是貼原始 diff，而是「人讀得懂的總結」。
|
||||
- **簡單版（`simple`）**：直接把本分支領先 target 的 commit 訊息**逐條列出**：
|
||||
|
||||
```bash
|
||||
git log --oneline "<target>..<PR 來源分支>"
|
||||
```
|
||||
|
||||
以條列呈現每行 commit 訊息。
|
||||
- **使用者輸入**：採用使用者提供的描述文字。
|
||||
|
||||
PR **標題**預設取一句總結（可用首個 feat/fix commit 或分支用途）；使用者另有指定則從之。
|
||||
|
||||
產生 PR body 時必須使用實際換行與 Markdown 內容，不可把跳脫字串當作正文送出。若用 shell / `jq` 組 JSON，應以 UTF-8 暫存檔、heredoc、`printf` 或 `jq --rawfile` 帶入內容；避免讓 PR 顯示成 `## Commit\n\n- ...` 這類字面 `\n`。
|
||||
依 `--pr-desc` 三選一，各形式的內容與產生方式依 `/jsc-shared:spec-pull-request`「PR 描述模式」執行；未提供時預設 `full`，不要為描述形式中斷詢問。PR **標題**預設取一句總結（可用首個 feat/fix commit 或分支用途）；使用者另有指定則從之。
|
||||
|
||||
### E5. 呼叫 Gitea API 建立 PR（使用 token）
|
||||
|
||||
token 從環境變數讀取，呼叫 Gitea 建立 PR：
|
||||
依 `/jsc-shared:spec-pull-request`「已有相同 head→base 的 open PR 時沿用不重開」與「建立 PR：body 一律用 UTF-8 檔案帶入」執行：先查詢目標分支是否已有相同來源的 open PR，有則沿用不重複建立；沒有才呼叫 `POST /pulls`，body 以 UTF-8 檔帶入、換行為實際換行；成功取回應中的 PR 連結／編號回報使用者，失敗時顯示錯誤訊息（先依 `/jsc-shared:spec-gitea` 遮蔽 token）供排查。
|
||||
|
||||
```bash
|
||||
# 不可 echo 含 token 的指令；body 以 UTF-8 JSON 檔帶入，輸出時遮蔽 token
|
||||
# PR 描述內的換行必須是實際換行，不可使用字面 \n
|
||||
curl -sS -X POST \
|
||||
-H "Authorization: token ${GITEA_TOKEN}" \
|
||||
-H "Content-Type: application/json" \
|
||||
"https://<host>/api/v1/repos/<owner>/<repo>/pulls" \
|
||||
--data @body.json
|
||||
```
|
||||
### E6. 完成通知＋清除對話內文（重要：可能含 token）
|
||||
|
||||
- **成功**：取回應中的 PR 連結／編號回報使用者。
|
||||
- **失敗**：顯示 API 回應的錯誤訊息供排查（**先遮蔽 token**）。常見錯誤：目標分支不存在、已有相同 head→base 的 PR、token 權限不足。
|
||||
|
||||
### E6. 完成通知 + 清除對話內文（重要：可能含 token）
|
||||
|
||||
1. **通知使用者**：push 結果、PR 連結／編號、PR 描述採用哪種形式。
|
||||
2. **清除 AI 助理對話內文**：因為 push／API 過程可能使對話內文殘留 gitea token，**完成後務必清除對話內文／上下文**以免外洩：
|
||||
- Claude Code：提示使用者執行 `/clear`（或依當前助理對等指令清空對話）。
|
||||
- 其他助理：執行各自清除對話／上下文的方式。
|
||||
- 在清除前，請再次確認輸出與 log 中沒有任何明文 token。
|
||||
依 `/jsc-shared:spec-pull-request`「完成後提醒清除對話內文」通知使用者 push 結果、PR 連結／編號與描述形式；因 push／API 過程可能使對話內文殘留 gitea token，完成後依 `/jsc-shared:spec-gitea`「Token 機密保護」提醒清除對話內文／上下文，清除前再次確認輸出與 log 中沒有任何明文 token。
|
||||
|
||||
---
|
||||
|
||||
@@ -543,11 +407,11 @@ curl -sS -X POST \
|
||||
|
||||
## 呼叫方式
|
||||
|
||||
格式：`[--findings <路徑>] [--target <目標分支>] [--pr-desc <full|simple|自訂文字>] [--no-commit] [--no-pr] [--yes]` —
|
||||
各助理呼叫一個 skill 的方式依 `/jsc-shared:spec-skill-invocation`；本 skill 參數格式與範例：
|
||||
|
||||
格式：`[--issue <編號|編號清單|all>] [--findings <路徑>] [--target <目標分支>] [--pr-desc <full|simple|自訂文字>] [--no-commit] [--no-pr] [--yes]` —
|
||||
除 `--target` 外皆可省略（findings 一律讀目錄 `.gitea/ai-review/findings/` 下所有 wrapper `*.json` 與 `findings.json`；`--issue` 無/單選/多選/全部 額外從 Gitea 議題取問題，與 findings 合併去重；目標分支省略時必問、不猜測）。token 一律由環境變數（如 `GITEA_TOKEN`）提供。
|
||||
|
||||
| 助理 | 呼叫 |
|
||||
| --- | --- |
|
||||
| Claude Code / Antigravity | `/jsc-code:review-resolve`，或 `/jsc-code:review-resolve --target develop --pr-desc full --yes`、`/jsc-code:review-resolve --issue 12,15 --target master`、`/jsc-code:review-resolve --issue all --target master`、`/jsc-code:review-resolve --no-pr`、`/jsc-code:review-resolve --no-commit` |
|
||||
| Codex | `$review-resolve`，或 `$review-resolve --target develop --pr-desc full --yes`、`$review-resolve --issue all --target master`，或用 `/skills` 選單 |
|
||||
| OpenCode | 描述需求（如「讀 .gitea/ai-review/findings/ 目錄與 findings.json 的 wrapper findings，再併入議題 #12、#15 的 code review 問題去重後依嚴重度逐條處理，更新 findings/exclusions，把工作區變更依 conventional commit 分類提交，push 後對 develop 發 PR（完整版描述）」）自動觸發 |
|
||||
- Claude Code / Antigravity：`/jsc-code:review-resolve`，或 `/jsc-code:review-resolve --target develop --pr-desc full --yes`、`/jsc-code:review-resolve --issue 12,15 --target master`、`/jsc-code:review-resolve --issue all --target master`、`/jsc-code:review-resolve --no-pr`、`/jsc-code:review-resolve --no-commit`
|
||||
- Codex：`$review-resolve`，或 `$review-resolve --target develop --pr-desc full --yes`、`$review-resolve --issue all --target master`，或用 `/skills` 選單
|
||||
- OpenCode：描述需求（如「讀 .gitea/ai-review/findings/ 目錄與 findings.json 的 wrapper findings，再併入議題 #12、#15 的 code review 問題去重後依嚴重度逐條處理，更新 findings/exclusions，把工作區變更依 conventional commit 分類提交，push 後對 develop 發 PR（完整版描述）」）自動觸發
|
||||
|
||||
Reference in New Issue
Block a user