Files

T

jiantw83andClaude Sonnet 5 1030f9d403 feat(shared): 新增14個共用spec、models/todo工具與樣板產生器，收斂跨repo重複規範

依 todo.md 執行的規範治理專案：新增 spec-preflight 等 14 個共用規範（含
conventional-commit/pull-request/git-push/issue-read/todo-list/ask-user/
subagent/no-scratch-files/skill-invocation/script-path/action-scaffold/
node-src-layout/plugin-cli/model），擴充 spec-git-safety 與 spec-gitea（token
優先序、機密遮蔽、Wiki 頁名轉義規則）；新增可執行 skill `models`（模型能力
查詢與標籤）與 `todo`（依指定模型產生/附加 todo.md）；新增 plugin.meta.json
單一事實來源與 gen-plugin-files.mjs 樣板產生器，統一四個 repo 的 manifest／
README／AGENTS.md 並移除寫死的本機使用者路徑；新增 shared/scripts/lib 的
log／機密遮蔽三語言參考實作。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

2026-08-11 06:02:30 +00:00

4.5 KiB

Raw Blame History

name, description

name	description
spec-conventional-commit	JSC plugins 共用「Conventional Commit 分類提交規範」：以 git status --porcelain=v1 -uall 完整盤點工作區變更、9 種 commit 類型對照（feat／fix／docs／style／refactor／perf／test／chore／revert）、commit 訊息格式為 type(範圍)：一句總結、範圍不得重述 type 本身、依邏輯分組後逐組以精準檔案路徑分別 git add（不用 git add -A 或 git add .）分類提交。當其他 skill 內文引用 spec-conventional-commit 或 /jsc-shared:spec-conventional-commit、或需要把工作區變更依 conventional commit 分類提交時載入此 skill。單獨被使用者呼叫時，直接說明本規範內容。

name

description

spec-conventional-commit

JSC plugins 共用「Conventional Commit 分類提交規範」：以 git status --porcelain=v1 -uall 完整盤點工作區變更、9 種 commit 類型對照（feat／fix／docs／style／refactor／perf／test／chore／revert）、commit 訊息格式為 type(範圍)：一句總結、範圍不得重述 type 本身、依邏輯分組後逐組以精準檔案路徑分別 git add（不用 git add -A 或 git add .）分類提交。當其他 skill 內文引用 spec-conventional-commit 或 /jsc-shared:spec-conventional-commit、或需要把工作區變更依 conventional commit 分類提交時載入此 skill。單獨被使用者呼叫時，直接說明本規範內容。

spec-conventional-commit — 共用 Conventional Commit 分類提交規範

工作區有變更需要 commit 時，一律遵守以下規範：先完整盤點、依實際異動內容歸類，再依邏輯分組並逐組精準提交。

盤點工作區變更

一律以 git status --porcelain=v1 -uall 為主，不可只看 git diff —— 那會漏掉未追蹤檔。git diff（已追蹤檔未暫存變更）、git diff --staged（已暫存變更）、git ls-files --others --exclude-standard（未追蹤檔）只作輔助核對。
盤點範圍必須包含所有變更：已修改檔、新增檔（?? 未追蹤檔）、刪除檔、改名檔，以及已暫存與未暫存的變更。
無任何變更 → 回報「工作區無變更可提交」，跳過提交。

commit 類型對照表

逐一檢視每個變更檔的實際異動內容（不只看路徑），歸入下列其一；所有 ?? 未追蹤檔都必須納入分類，不能因為不在 git diff 裡就漏掉。

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

同一檔案橫跨多型 → 以該檔主要異動性質歸類；難以拆分時就近歸入影響最大的一類，並在總結註記。
未追蹤新檔：必須照實際內容歸入對應 type，必要時在提交前明確 git add -- <path>，不可因為是新檔就略過。

commit 訊息格式

type(範圍): 一句總結

type：上表其中一個英文類型。
範圍（括號內）：必須是這組異動實際牽涉的功能／模組／元件名稱，不得重述 type 本身。取名規則：優先沿用程式碼／專案中既有的識別名（檔名、模組名、skill 名、功能名，可中可英、保持與原碼一致），讓人一眼看出「改到哪個東西」。
- ✅ 對：feat(使用者登入)、fix(結帳流程)、perf(物件查詢)、docs(README)、refactor(訂單服務)、chore(plugin 版本)。
- ❌ 錯（只是重述 type，禁止）：feat(新增功能)、fix(修正錯誤)、perf(優化效能)、docs(文件)、chore(雜項)。
- 一組異動橫跨多個功能而無單一主體時，才退而取最貼近的上層範圍（例如多個 manifest → plugin 設定）。
一句總結：把這個 commit 內所有異動總結成一句繁體中文，簡短、聚焦做了什麼。
範例：feat(使用者登入): 新增帳密登入與 token 簽發、fix(結帳流程): 修正空購物車導致的結帳例外、perf(物件查詢): 改用批次查詢降低 DB 往返、docs(README): 補上安裝與呼叫方式說明、chore(ai-review 狀態): 更新 findings 與 exclusions.json。

分組與提交順序

依 commit 類型把變更檔分組，每個 type 一個 commit；提交計畫必須完整對應盤點出的所有變更項目，不能遺漏任何 ?? 未追蹤檔。

逐組執行，每次僅暫存該組檔案：

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

不用 git add -A 或 git add .，避免把不同類型的異動混進同一個 commit。
改名／刪除檔一併納入對應組的 git add（git add -A -- <路徑> 或明確列出該路徑）。
提交順序建議：fix／feat 等核心異動在前，docs／style／chore 在後（純屬建議，可依相依性調整）。

4.5 KiB Raw Blame History Unescape Escape