refactor(skills 共用規範): 抽出共用規範至 generic spec-*,以引用+一行 fallback 摘要取代重複內容
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
co-authored by
Claude Fable 5
parent
fc39c1254d
commit
7814e2edea
@@ -18,17 +18,20 @@ argument-hint: "[--findings <findings.json 路徑>] [--target <目標分支>] [-
|
||||
|
||||
---
|
||||
|
||||
## 輸出規範(務必遵守)
|
||||
## 共用規範(generic plugin,必要前置)
|
||||
|
||||
- **語言**:所有面向使用者的輸出(修復清單、提交計畫、總結、反問)與 **commit 訊息** 一律使用**繁體中文(台灣用語)**;
|
||||
僅程式碼識別字、檔名、git 指令、conventional commit 的 `type`(`feat`/`fix`…)等技術標識保留原文,**不可**使用簡體字。
|
||||
- **編碼無亂碼(含繁中、全形標點、emoji)**:凡輸出或寫入只要含繁體中文,一律 **UTF-8(不含 BOM)**,不得出現問號方框()或錯碼。涵蓋:更新後的 `findings.json` / `exclusions.json`、**commit 訊息**、**PR 標題/描述**、終端訊息,與等級 emoji 🔴🟠🟡🔵。實作要點:
|
||||
- **寫檔**:優先用助理的檔案寫入工具(預設 UTF-8 無 BOM)。若改用 shell 寫檔,**避免 PowerShell 的 `>`/`Out-File`**(預設可能寫成 UTF-16 或加 BOM);需要時用 `Set-Content -Encoding utf8NoBOM`,或在 bash 用 `printf`/heredoc。
|
||||
- **commit 訊息**:用 `git commit -m` 直接帶字串,或寫進 UTF-8 無 BOM 的檔案再 `git commit -F <file>`;確保 `git config i18n.commitEncoding utf-8`。
|
||||
- **PR body**:以 UTF-8 JSON 經 API 送出(如 `--data @body.json`,該檔為 UTF-8 無 BOM)。
|
||||
- **送出前自我檢查**:產生含繁中的檔案/訊息後,回頭確認沒有亂碼或 BOM 再提交/送出。
|
||||
- **自動執行原則**:除非使用者明確要求先確認,或遇到不可忽略的必要決策(例如目標分支缺失、pull 策略不明、無法安全解衝突、需人工判斷的設計取捨、push 憑證皆失敗),否則各階段只需輸出簡短計畫/進度後直接執行到完成;不要為一般修復、寫檔、分類 commit、push 或開 PR 反覆詢問。
|
||||
- **Token 機密保護(極重要)**:gitea token 一律**從環境變數讀取**(如 `$GITEA_TOKEN`),**絕不**寫死在 skill、commit、PR 內文或任何輸出;**不可** echo 含 token 的指令或 URL、不可寫進 log。所有顯示給使用者的指令/錯誤訊息都要**遮蔽 token**(如以 `***` 取代)。階段 E 完成後依規範清除對話內文(見 E6)。
|
||||
執行本 skill 前,先以 Skill 工具載入下列共用規範並全程遵守;**任一載入不到(generic plugin 未安裝)時,先詢問使用者是否安裝 generic plugin(`https://gitea.jsc.idv.tw/plugins/generic.git`),使用者不安裝則直接中斷本 skill**,不得只憑下方一行摘要繼續執行:
|
||||
|
||||
- `/jsc:spec-output`:繁體中文(台灣用語)、UTF-8(不含 BOM)無亂碼(含 commit 訊息、PR 標題/描述、寫檔/API body 實作要點與送出前自我檢查)。
|
||||
- `/jsc:spec-execution`:自動執行原則(必要決策才中斷)、不臆測/需人工確認。
|
||||
- `/jsc:spec-gitea`:`GITEA_TOKEN` 機密保護(不 echo、遮蔽 `***`)、API body 以 UTF-8 JSON 檔帶入。
|
||||
- `/jsc:spec-git-safety`:不破壞既有工作、develop → master 後備、保守解衝突、新分支不覆蓋既有分支。
|
||||
|
||||
本 skill 特有補充:
|
||||
|
||||
- **必要決策**(會中斷詢問):目標分支缺失、pull 策略不明、無法安全解衝突、需人工判斷的設計取捨、push 憑證皆失敗。
|
||||
- 涵蓋範圍:更新後的 `findings.json` / `exclusions.json`、commit 訊息、PR 標題/描述、終端訊息,與等級 emoji 🔴🟠🟡🔵。
|
||||
- 階段 E 完成後依規範清除對話內文(見 E6)。
|
||||
|
||||
---
|
||||
|
||||
@@ -132,13 +135,7 @@ source_branch="$(git rev-parse --abbrev-ref HEAD)"
|
||||
|
||||
### A6. 必要時嘗試解衝突
|
||||
|
||||
當 `git pull` 後出現衝突:
|
||||
|
||||
1. 用 `git status --porcelain` 與衝突標記定位衝突檔。
|
||||
2. 讀取衝突檔脈絡,依專案現有行為與遠端變更做最小合理整合。
|
||||
3. 可安全解決的衝突:編輯檔案移除衝突標記,執行 `git add -- <檔案...>` 標記已解決。
|
||||
4. 無法安全判斷的衝突:停止處理,列出檔案、衝突原因與需要使用者決策的點;不要硬選任一邊。
|
||||
5. 全部衝突解完後,依 git 當前狀態完成 merge / rebase 的必要步驟,確認 `git status --porcelain` 沒有未解衝突,再回到 A5 判斷是否需要建立新工作分支。
|
||||
當 `git pull` 後出現衝突,依 `/jsc:spec-git-safety` 的保守解衝突流程處理(定位衝突檔 → 最小合理整合 → 可安全解決者 `git add` 標記、無法安全判斷者停止並列出決策點);全部衝突解完後,依 git 當前狀態完成 merge / rebase 的必要步驟,確認 `git status --porcelain` 沒有未解衝突,再回到 A5 判斷是否需要建立新工作分支。
|
||||
|
||||
---
|
||||
|
||||
|
||||
Reference in New Issue
Block a user