shared/skills/plan-wiki/SKILL.md

name, description, argument-hint

name	description	argument-hint
plan-wiki	逐步詢問使用者計畫內容，持續釐清到系統規劃所需描述完整後，才把詳細分析同步到指定 Gitea wiki 的目錄頁與計畫頁，全程禁止本機檔案落地，不建立本機計畫檔、草稿檔、暫存 JSON body、附件暫存檔或 wiki clone。使用者要建立計畫、把計畫加入 wiki 目錄、指定 Gitea wiki repo／目錄頁／計畫頁、要求計畫檔案不落地、或提到 plan-wiki、計畫 wiki、wiki 目錄頁時觸發。適用於：需求尚未完整、需要逐題釐清並保存到 wiki 的計畫文件。不適用於：產生本機 plan.md／todo.md、產生代辦事項、拆 Gitea issue（用 /jsc-doc:issues-analyze）、或非 Gitea wiki。	[--wiki-repo <owner/repo>] [--index CONTENTS] [--project <計畫名稱>] [--page PLAN-<yyyyMMdd>-<HASH>] [--host <gitea主機>] [--yes]

plan-wiki — 逐步建立計畫並同步到 Gitea wiki

把「逐步詢問 → 確認描述完整 → 詳細分析計畫 → 同步 wiki 目錄與頁面」固定成流程。必須一直重複詢問使用者，直到蒐集完系統規劃所需的所有描述；凡有疑問或缺口都要詢問，不得自行幻想。只有描述完整後，才可以把詳細分析寫入計畫頁；全程禁止本機檔案落地。

階段	動作
A. 前置設定	確認 Gitea host、token、wiki repo、目錄頁、計畫名稱與計畫頁
B. 讀取 wiki 現況	讀取目錄頁與計畫頁，保留既有內容
C. 逐步詢問	每輪只問 1～3 個必要問題，使用者回答後判斷是否仍有疑問
D. 同步 wiki	描述完整且已完成詳細分析後，更新目錄頁與計畫頁
E. 完成收斂	使用者確認計畫完成後輸出 wiki 連結與摘要

共用規範（必要前置）

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

本 skill 特有補充：

• 本 skill 會寫入外部 Gitea wiki；目標 wiki repo 不明時必須詢問，不得臆測。
• 目錄頁 title 預設固定為 CONTENTS，不詢問使用者；只有使用者明確提供 --index 時才覆蓋預設值。
• 計畫頁 title 預設固定為 PLAN-{yyyyMMdd}-{HASH}，不詢問使用者；yyyyMMdd 使用 Asia/Taipei 當日日期，HASH 由已確認的計畫內容、計畫名稱或需求摘要產生穩定短雜湊並轉成全大寫。
• 加入目錄頁時，先從計畫內容尋找系統名稱；若無明確系統名稱，依計畫目標產生一個精簡系統名稱。系統名稱必須是程式碼專案可使用的英文名稱，格式固定為大駝峰（PascalCase），只允許英文字母與數字，且必須以英文字母開頭，例如 InventoryTracker。無法可靠產生時必須詢問使用者，不得自行幻想。目錄標題使用 {系統名稱}-計畫，並連結到計畫頁。
• 目錄頁禁止整頁覆蓋：不存在時才新建；存在時必須保留既有內容，只修改本計畫既有列或在既有表格附加新列。
• 不落地絕對規則：全程禁止本機檔案落地。不得建立、更新、下載或暫存任何本機輸出／中介檔案，包含 plan.md、todo.md、.md 草稿、暫存 JSON body、附件暫存檔、wiki clone、或任何用來傳遞中間成果的檔案；中間成果只存在於對話內容、工具參數與 Gitea wiki API request body。不得使用 curl --data @file、--data-binary @file 或任何 @file 形式送出本機檔案。
• 使用者已用參數指定 --wiki-repo、--index、--project、--page 時跳過對應詢問。
• 使用者已用 --project 指定計畫名稱時，仍需檢查是否符合 PascalCase 英文專案名稱；不符合時必須請使用者修正或授權轉換後的新名稱。
• 不產生 TODO、待辦事項、checklist、工作清單或實作任務；計畫頁只描述系統規劃、決策、範圍、方案、風險與待確認事項。
• 不要求使用者把 token 貼進對話；token 依 spec-gitea 從環境變數或既有設定取得。

參數

[--wiki-repo <owner/repo>] [--index CONTENTS] [--project <計畫名稱>] [--page PLAN-<yyyyMMdd>-<HASH>] [--host <gitea主機>] [--yes]

參數	說明
--wiki-repo	Gitea wiki 所屬 repo，例如 knowledges/Plan。未帶且無法從目前 repo 推得時詢問使用者。
--index	目錄頁 title；未帶時固定使用 CONTENTS，不詢問。
--project	計畫名稱／系統名稱；必須是程式碼專案可使用的 PascalCase 英文名稱。未帶時從計畫內容尋找或產生系統名稱，用於目錄列標題與摘要。
--page	計畫頁 title；未帶時固定使用 PLAN-{yyyyMMdd}-{HASH}，不詢問。
--host	Gitea 主機，依 spec-gitea host 決定順序處理。
--yes	略過一般性確認；不得略過目標 wiki 不明、寫入衝突或使用者尚未確認的計畫完成判斷。

階段 A：前置設定

1. 依 spec-gitea 決定 host 與 token，只輸出 token「已設定／未設定」。
2. 確認 --wiki-repo 是否為 owner/repo 格式；不符合時詢問使用者修正。
3. 確認目錄頁 title：未帶 --index 時固定使用 CONTENTS。
4. 確認計畫頁 title：未帶 --page 時固定使用 PLAN-{yyyyMMdd}-{HASH}。雜湊輸入優先使用已確認的計畫內容；內容不足時使用計畫名稱、來源摘要與當輪時間組合，輸出全大寫短雜湊。
5. 確認系統名稱：先從 --project、計畫內容、需求來源或使用者回答尋找明確系統名稱；系統名稱必須符合 PascalCase 英文專案名稱格式。找不到或無法可靠轉換時，必須詢問使用者，不得自行幻想。
6. 用 GET /repos/<owner>/<repo> 驗證 token 對 repo 有權限；失敗時遮蔽機密後回報並停止。

階段 B：讀取 wiki 現況

1. 依 spec-gitea 分頁讀取 GET /repos/<owner>/<repo>/wiki/pages。
2. 以 title 查表取得目錄頁與計畫頁的 sub_url，不得自行猜測轉義規則。
3. 讀取頁面：GET /repos/<owner>/<repo>/wiki/page/<sub_url>，將 content_base64 解成 UTF-8 Markdown。
4. 目錄頁不存在時在記憶中組出符合「目錄頁格式」的新頁內容；目錄頁存在時不得用預設格式覆蓋整頁，只能保留原內容後修改或附加本計畫目錄列。計畫頁不存在時在記憶中組出目前計畫草稿。不得先寫成本機檔案。

目錄頁格式

目錄頁不存在時建立下列結構；更新既有目錄頁時禁止整頁覆蓋，必須保留既有標題、說明、表格與其他內容，只新增或更新本計畫相關列。新建目錄頁的大標題（H1）使用系統名稱；若此 wiki 不是單一系統專用且無法確認系統名稱，使用 # 代辦事項：

# <系統名稱或代辦事項>

計畫目錄。

| 頁面 | 內容 |
|------|------|
| [<系統名稱>-計畫](<page title percent-encoded, 空白用 %20>) | plan wiki：<系統名稱> 計畫 |

產出日期：yyyy-MM-dd

若目錄頁已存在且不是單一計畫專用目錄，仍以同一張 | 頁面 | 內容 | 表格為準：保留原標題與說明，只在表格中 upsert 本計畫頁面列。若既有目錄頁沒有 | 頁面 | 內容 | 表格，附加一段新的目錄表格到頁面末尾，不得刪除或重排既有內容。連結文字固定為 <系統名稱>-計畫；連結 target 用 encodeURIComponent(title).replace(/%20/g, "%20") 的結果，不使用 API sub_url 反推人工連結。

計畫頁格式

計畫頁使用 Markdown，至少包含：

# <page title>

## 目標

## 背景與限制

## 範圍

## 方案

## 風險

## 待確認

已有計畫頁時保留使用者明確保留的內容；只更新本 skill 管理的章節。需求不明的部分放在 ## 待確認，不得自行補完。不得加入 ## TODO、Markdown checklist 或任何代辦事項章節。

階段 C：逐步詢問

每輪最多問 1～3 個問題，問題必須能推進計畫內容。建議順序：

1. 計畫目標與成功標準。
2. 使用者、情境、限制條件。
3. 功能範圍與明確不做的範圍。
4. 方案拆解、資料流、外部依賴。
5. 里程碑、驗收項目、風險與待確認。

每輪回答後：

• 檢查目標、成功標準、使用者與情境、限制條件、功能範圍、不做範圍、資料流、外部依賴、里程碑、驗收項目、風險與待確認事項是否足以形成系統規劃。
• 對所有仍不明確、互相矛盾或無法可靠推論的點，繼續詢問使用者；不得用「合理推測」補完。
• 在描述完整前，不得把詳細分析寫入計畫頁。
• 描述完整後，才整理計畫頁的目標、背景與限制、範圍、方案、風險與待確認；不得產生 TODO 或 checklist。

使用者明確表示「完成」「先到這裡」「計畫完成」時，先檢查系統規劃必要描述是否完整；若仍有必要缺口，必須列出缺口並繼續詢問。只有必要描述完整時，才能進入階段 D 與階段 E；不要再追問非必要細節。

階段 D：同步 wiki

描述完整並完成詳細分析後，同步順序固定：

1. 更新計畫頁。
2. 更新目錄頁：不存在才建立；存在時禁止整頁覆蓋，只修改既有 <系統名稱>-計畫 列，或在既有表格／頁末附加新列，確保有本計畫頁連結與摘要。
3. 再次讀回兩個頁面確認內容已更新。

API 寫入方式：

• 建立新頁：POST /repos/<owner>/<repo>/wiki/new，body 帶 title、content、message。
• 更新既有頁：先查表取得 sub_url，再用 PATCH /repos/<owner>/<repo>/wiki/page/<sub_url>，body 帶 title、content、message。
• request body 必須由工具呼叫、stdin、shell 變數或記憶中內容直接送出，不得先寫成本機 JSON、Markdown 或任何暫存檔；禁止所有 @file 形式。
• message 用繁體中文，例如 更新 <page title>。

若站台不支援 REST wiki 寫入端點，回報「此站台不支援不落地 wiki 寫入」並停止，不得改用 wiki git clone。

階段 E：完成收斂

輸出摘要表格：

項目	內容
Wiki repo	<owner/repo>
目錄頁	<index title>
計畫頁	<page title>
同步次數	本輪實際寫入次數
待確認	## 待確認 剩餘項目數

最後附上目錄頁與計畫頁 URL。

呼叫方式

依 /jsc-shared:spec-skill-invocation 的統一呼叫方式，本 skill 的實際參數格式與範例：

助理	呼叫
Claude Code / Antigravity	/jsc-shared:plan-wiki --wiki-repo knowledges/Plan --project Kokorone
Codex	$plan-wiki --wiki-repo knowledges/Plan --project Kokorone
OpenCode	描述需求（如「逐步問我計畫內容，並同步到 Gitea wiki 目錄與頁面」）自動觸發