refactor(doc): 接上 shared 共用規範，去除重抄段落並修正時區/機密遮蔽引用

依 todo.md 執行的規範治理專案：worklog／funcs／issues-analyze／
issues-analyze-to-file／issues-sync／notifications／docker 七個 skill 改為
引用 shared 新增的 14 個共用 spec（token 優先序、issue 讀取、TODO list、
ask-user、subagent、no-scratch-files、skill-invocation、script-path 等），
不再重抄內容；wiki_api.py 改用 zoneinfo 而非硬編 +8 offset，並補上與
shared/scripts/lib/redact-patterns.json 的對應註記；worklog 的 --tune 改為
呼叫 /jsc-shared:models --task summary。

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

skills/issues-analyze-to-file/SKILL.md

@@ -7,21 +7,16 @@ description: 讀取一或多筆 Gitea issue URL（優先用 tea，否則用 Gite
 
 你要讀取使用者提供的一或多筆 Gitea issue，彙整成完整需求文件，依功能拆成多個實作階段（每階段建立一個 issue），配合指定的 repositories 產生實作草稿，最後產出交付文件並依 issues 分組留言。**建立 issue 與留言屬於對外且不易復原的動作，必須先讓使用者確認過草稿再執行**。所有需求彙整、階段拆分與實作草稿一律先產生草稿檔，再詢問使用者是否實際建立 issue / 留言。請依下列階段依序完成。
 
-## 共用規範（shared plugin，必要前置）
+## 共用規範（必要前置）
 
-執行本 skill 前，先以 Skill 工具載入下列共用規範並全程遵守；**任一載入不到（shared plugin 未安裝）時，先詢問使用者是否安裝 shared plugin（`https://gitea.jsc.idv.tw/plugins/shared.git`），使用者不安裝則直接中斷本 skill**，不得只憑下方一行摘要繼續執行：
-
-- `/jsc-shared:spec-output`：繁體中文為主英文為輔、UTF-8（不含 BOM）無亂碼、Mermaid 呈現、個資（PII）去識別化。
-- `/jsc-shared:spec-execution`：不臆測／需人工確認、不擴及無關檔案。
-- `/jsc-shared:spec-gitea`：`GITEA_TOKEN` 機密保護、不依賴 `jq`、API 呼叫慣例（`Authorization: token`、分頁完整讀取）。
+先載入 `/jsc-shared:spec-preflight` 並依其流程處理；載入不到即代表 shared plugin 未安裝，
+依該 spec 詢問使用者是否安裝 `https://gitea.jsc.idv.tw/plugins/shared.git`，不安裝則中斷本 skill。
+本 skill 需要的規範：`spec-output`、`spec-execution`、`spec-gitea`、`spec-issue-read`、`spec-ask-user`、`spec-subagent`
 
 ## 前置：輸入與工具
 
 - **輸入**：至少一筆 issue URL（可多筆）。可另外指定「repositories 位置」（本機含多個專案的資料夾）；若未指定，實作草稿以各 issue 所在的 repository 為準。
-- **工具優先序**：
-  1. 若該 issue host 在 `tea login list` 中有對應 login，優先用 `tea`（`tea issues`、`tea comment` 等），並以 `--login <name> --repo <owner>/<repo>` 指定目標。
-  2. 否則改用 Gitea REST API + `curl`，帶標頭 `Authorization: token $GITEA_TOKEN`（環境變數 `GITEA_TOKEN` 已設定）。
-- **不要依賴 `jq`**：依 `/jsc-shared:spec-gitea`（JSON 用 tea 結構化輸出或交給 subagent 解析，不 pipe 到 `jq`）。
+- **Gitea 工具選擇與呼叫慣例**：依 `/jsc-shared:spec-gitea` 執行（`tea` 與 API 的選擇與可用性檢查、不依賴 `jq`、分頁完整讀取、`Authorization: token` 等呼叫慣例），各 issue 的目標 `--login <name> --repo <owner>/<repo>` 或 API base 依第 0 步解析出的 host/owner/repo 帶入。
 - **工作目錄**：所有草稿與文件放在 `.docs/doc-issues-analyze-to-file/`。
 - **議題描述流程圖**：依 `/jsc-shared:spec-output` — 產生要寫進 issue 的描述（尤其各階段 issue 的 body）時，有助理解就加入 Mermaid 流程圖（處理流程、狀態轉移、階段相依關係），忠實反映需求與拆分結果、不得杜撰。
 
@@ -36,12 +31,10 @@ description: 讀取一或多筆 Gitea issue URL（優先用 tea，否則用 Gite
 
 ## 第 1 步：讀取 issues 內容
 
-對每一筆 issue，讀取完整內容：`title`、`body`、`state`、`labels`、`milestone`、`assignees`、以及**所有 comments**；若 Gitea 版本支援，另讀該 issue 所屬 `project`。
+依 `/jsc-shared:spec-issue-read` 完整讀取每一筆 issue（描述、所有留言、所有附件，不得只讀描述、不得臆測缺漏部分），並補讀 `labels`、`milestone`、`assignees`；若 Gitea 版本支援，另讀該 issue 所屬 `project`。
 
 - tea：`tea issues <index> --repo <owner>/<repo> --login <name> --comments`，或用 `tea issues list --fields index,title,body,labels,milestone,comments,url --output csv` 過濾。
-- API：
-  - issue 本體：`GET {base}/issues/{index}`
-  - 留言：`GET {base}/issues/{index}/comments`
+- API：issue 本體 `GET {base}/issues/{index}`；留言與附件依 spec-issue-read 指定的端點分頁完整讀取。
 - 同時盤點該 repo 既有的分類資源，供後續階段沿用：
   - 標籤：`GET {base}/labels`（tea：`tea labels list`）
   - 里程碑：`GET {base}/milestones`（tea：`tea milestones list`）
@@ -71,7 +64,7 @@ description: 讀取一或多筆 Gitea issue URL（優先用 tea，否則用 Gite
 
 ## 第 4 步：確定 target repositories 並產生實作草稿（派 subagent）
 
-決定要對照的 target repositories：使用者指定位置底下的所有專案，或各 issue 所在的 repository。對**每一個實作階段各派一個 subagent**，研究相關專案程式碼後產生實作草稿 `.docs/doc-issues-analyze-to-file/drafts/phase-{N}.md`。subagent 只讀程式碼與必要上下文、**不修改任何原始碼、不建立 issue、不留言**，只在 `.docs/` 底下寫草稿。每份草稿包含：
+決定要對照的 target repositories：使用者指定位置底下的所有專案，或各 issue 所在的 repository。依 `/jsc-shared:spec-subagent` 對**每一個實作階段各派一個 subagent**，研究相關專案程式碼；本 skill 明確授權的例外寫入範圍僅限各自的草稿檔 `.docs/doc-issues-analyze-to-file/drafts/phase-{N}.md`，不得建立 issue、不得留言、不得修改任何原始碼。每份草稿包含：
 
 - 對應階段與對應（將建立的）issue 標題。
 - 涉及的專案／檔案清單與定位（以 `path:line` 形式標出關鍵位置）。
@@ -88,9 +81,9 @@ description: 讀取一或多筆 Gitea issue URL（優先用 tea，否則用 Gite
 - 里程碑／專案／標籤的沿用決定，與第 1 步盤點到的既有資源一致（id／名稱對得上）。
 - 若發現問題，先修正草稿並重新檢查，通過後才進入下一步。
 
-## 第 6 步：詢問使用者要如何執行（AskUserQuestion）
+## 第 6 步：詢問使用者要如何執行
 
-草稿完成並通過檢查後，主 agent 必須用 AskUserQuestion 讓使用者確認要如何執行對外動作，至少提供：
+草稿完成並通過檢查後，主 agent 依 `/jsc-shared:spec-ask-user` 詢問使用者要如何執行對外動作。本 skill 固定的 4 個情境選項，加上規範要求必附的「其他」共 5 項，超過 `AskUserQuestion` 的選項上限，故改用文字列出（附編號）供使用者回覆：
 
 1. 全部執行：建立所有階段 issue，並產生交付文件、依 issues 分組留言。
 2. 只建立 issue：建立階段 issue，但先不留言交付內容。
@@ -98,7 +91,7 @@ description: 讀取一或多筆 Gitea issue URL（優先用 tea，否則用 Gite
 4. 逐階段確認：每建立一個 issue（及其留言）就回報，待使用者確認後再做下一個。
 5. 其他（由使用者輸入自訂方式）。
 
-依使用者選擇進行後續步驟；未獲確認前不得建立 issue 或留言。
+依使用者選擇進行後續步驟；此為破壞性且不易復原的決策，未獲確認前不得建立 issue 或留言，且不得被任何自動確認旗標略過。
 
 ## 第 7 步：依階段建立 issues
 
@@ -129,6 +122,6 @@ description: 讀取一或多筆 Gitea issue URL（優先用 tea，否則用 Gite
 
 - 建立 issue 與留言是對外且不易復原的動作，**必須先經第 6 步使用者確認**；未確認前只產生本機草稿。
 - 新 issue 一律沿用來源 issue 的里程碑與專案；標籤只從既有標籤中依需求性質挑選，不自行新建（除非使用者要求）。
-- subagent 與各步驟只讀程式碼與 issue、只寫 `.docs/` 草稿，**不得修改任何原始碼**；本 skill 的產出是需求文件、階段 issue、實作草稿與交付留言，不含改動程式邏輯。
-- JSON 解析（不依賴 `jq`）依 `/jsc-shared:spec-gitea`；個資保護（PII）與語言規範依 `/jsc-shared:spec-output`。
+- subagent 派工依 `/jsc-shared:spec-subagent`：只讀程式碼與 issue，僅授權寫入各自的草稿檔，**不得修改任何原始碼、不得建立 issue、不得留言**；本 skill 的產出是需求文件、階段 issue、實作草稿與交付留言，不含改動程式邏輯。
+- 議題讀取依 `/jsc-shared:spec-issue-read`；Gitea 工具與 JSON 解析（不依賴 `jq`）依 `/jsc-shared:spec-gitea`；個資保護（PII）與語言規範依 `/jsc-shared:spec-output`。
 - 需求、階段與實作草稿若無法可靠推論，一律保守描述並標註「需人工確認」，不得編造 issue 未提及的內容。