Files
doc/skills/notifications/SKILL.md
T
jiantw83andClaude Sonnet 5 0cad39177b feat(spec-version-guard): 新增版本檢查 hook 並在 7 個 skill 檔頭引用規範
hooks/hooks.json 在既有 Stop(worklog)之外新增 PreToolUse 條目,沿用跨 plugin
腳本定位手法呼叫 shared 的 version-guard.mjs;docker/funcs/issues-analyze-to-file/
issues-analyze/issues-sync/notifications/worklog 七個 skill 檔頭補上
spec-version-guard。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-17 14:54:37 +08:00

2.9 KiB

name, description
name description
notifications 讀取 Gitea 通知,依通知類型分組後逐組執行;若沒有通知就直接結束;先從目前工作區的 REVIEW.md 找對應流程,找不到就詢問使用者怎麼處理,並把缺少流程的通知類型附加回 REVIEW.md。當使用者要整理 Gitea 通知、依通知類型批次處理、照 REVIEW.md 執行通知流程、或補齊 REVIEW.md 的通知類型說明時使用此 skill。

共用規範(必要前置)

先載入 /jsc-shared:spec-preflight 並依其流程處理;載入不到即代表 shared plugin 未安裝, 依該 spec 詢問使用者是否安裝 https://gitea.jsc.idv.tw/plugins/shared.git,不安裝則中斷本 skill。 本 skill 需要的規範:spec-version-guard、spec-output、spec-execution、spec-gitea、spec-no-scratch-files

依 REVIEW.md 處理 Gitea 通知

你要讀取目前使用者在目標 Gitea 主機上的通知,先依通知類型分組,再逐組套用 REVIEW.md 內定義的處理流程。若沒有通知,直接結束,不改任何檔案,也不寫回 Gitea。

第 0 步:先決條件

  1. 先依 /jsc-shared:spec-gitea 確認工具可用性,並決定使用 tea 或 Gitea REST API + GITEA_TOKEN。
  2. 依 /jsc-shared:spec-gitea 的「gitea 主機決定順序」決定 host,不自行定義順序。
  3. 若 tea 可用且該 host 有對應 login,優先用 tea;否則用 API + GITEA_TOKEN。

第 1 步:讀取通知

  1. 以 tea 或 Gitea API 讀取目前使用者通知。
  2. 分頁要抓完整,直到沒有下一頁為止。
  3. 預設只處理 unread 與 pinned 通知;若實作環境或 REVIEW.md 明確要求納入其他狀態,再依需求擴充。
  4. 若沒有任何通知,直接結束。

第 2 步:依通知類型分組

  1. 以通知的 subject.type 分組。
  2. 同一組內依通知原始順序逐一處理。
  3. 每處理完一組才進下一組。

第 3 步:從 REVIEW.md 找處理流程

  1. 先讀目前工作目錄根目錄的 REVIEW.md。
  2. 以通知類型名稱尋找對應流程,優先找同名標題或清楚對應的段落。
  3. 找到流程就照流程執行。
  4. 找不到流程時,立刻詢問使用者這個通知類型要怎麼處理,不要自行猜。

第 4 步:處理缺流程的類別

  1. 找不到流程的通知類型要先暫存,等使用者回答後再處理。
  2. 把這個類型與使用者最後確認的處理方式附加到 REVIEW.md。
  3. 若 REVIEW.md 不存在,先詢問使用者要在 repo root 建立,還是改用其他 review 檔案。

第 5 步:執行與收尾

  1. 逐組完成後,回報本次讀到的通知總數、分組結果、已套用的流程,以及哪些通知類型沒有既有流程。
  2. 若有新增到 REVIEW.md,明確回報更新位置。
  3. 依 /jsc-shared:spec-no-scratch-files 執行,全程不把通知內容落地成草稿檔或暫存檔。