feat(wiki skills): 新增不落地計畫與待辦 wiki 流程
This commit is contained in:
@@ -0,0 +1,159 @@
|
||||
---
|
||||
name: plan-wiki
|
||||
description: 逐步詢問使用者計畫內容，並把每一輪已確認的計畫草稿直接同步到指定 Gitea wiki 的目錄頁與計畫頁，全程不建立本機計畫檔、草稿檔、暫存 JSON body 或 wiki clone。使用者要建立計畫、把計畫加入 wiki 目錄、指定 Gitea wiki repo／目錄頁／計畫頁、要求邊問邊同步 wiki、要求計畫檔案不落地、或提到 plan-wiki、計畫 wiki、wiki 目錄頁時觸發。適用於：需求尚未完整、需要逐題釐清並保存到 wiki 的計畫文件。不適用於：產生本機 plan.md／todo.md、拆 Gitea issue（用 /jsc-doc:issues-analyze）、或非 Gitea wiki。
|
||||
argument-hint: "[--wiki-repo <owner/repo>] [--index <目錄頁title>] [--project <計畫名稱>] [--page <計畫頁title>] [--host <gitea主機>] [--yes]"
|
||||
---
|
||||
|
||||
# plan-wiki — 逐步建立計畫並同步到 Gitea wiki
|
||||
|
||||
把「逐步詢問 → 彙整計畫 → 同步 wiki 目錄與頁面 → 繼續詢問」固定成可重複流程。每次使用者回答一輪問題後，都必須把目前已確認內容同步到 Gitea 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、目錄頁、計畫頁不明時必須詢問，不得臆測。
|
||||
- **不落地絕對規則**：不得建立本機 `plan.md`、`todo.md`、`.md` 草稿、暫存 JSON body、wiki clone、或任何用來傳遞中間成果的檔案；中間成果只存在於對話內容與 Gitea wiki API request body。不得使用 `curl --data @file`。
|
||||
- 使用者已用參數指定 `--wiki-repo`、`--index`、`--project`、`--page` 時跳過對應詢問。
|
||||
- 每一輪使用者回答後都要同步 wiki。同步失敗時停止下一輪詢問，先回報錯誤與待使用者處理的點。
|
||||
- 不要求使用者把 token 貼進對話；token 依 `spec-gitea` 從環境變數或既有設定取得。
|
||||
|
||||
## 參數
|
||||
|
||||
`[--wiki-repo <owner/repo>] [--index <目錄頁title>] [--project <計畫名稱>] [--page <計畫頁title>] [--host <gitea主機>] [--yes]`
|
||||
|
||||
| 參數 | 說明 |
|
||||
| --- | --- |
|
||||
| `--wiki-repo` | Gitea wiki 所屬 repo，例如 `knowledges/Plan`。未帶且無法從目前 repo 推得時詢問使用者。 |
|
||||
| `--index` | 目錄頁 title，預設可詢問使用者；若使用者明確說「目錄」可用 `目錄`。 |
|
||||
| `--project` | 計畫名稱，用於目錄頁 H1、說明與預設頁名。 |
|
||||
| `--page` | 計畫頁 title；未帶時用 `<project> 計畫`，但需先告知使用者。 |
|
||||
| `--host` | Gitea 主機，依 `spec-gitea` host 決定順序處理。 |
|
||||
| `--yes` | 略過一般性確認；不得略過目標 wiki 不明、寫入衝突或使用者尚未確認的計畫完成判斷。 |
|
||||
|
||||
## 階段 A：前置設定
|
||||
|
||||
1. 依 `spec-gitea` 決定 host 與 token，只輸出 token「已設定／未設定」。
|
||||
2. 確認 `--wiki-repo` 是否為 `owner/repo` 格式；不符合時詢問使用者修正。
|
||||
3. 確認目錄頁 title、計畫名稱、計畫頁 title。
|
||||
4. 用 `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. 目錄頁不存在時在記憶中組出符合「目錄頁格式」的內容；計畫頁不存在時在記憶中組出目前計畫草稿。不得先寫成本機檔案。
|
||||
|
||||
## 目錄頁格式
|
||||
|
||||
目錄頁必須維持下列結構；更新時保留既有列，只新增或更新本計畫相關列：
|
||||
|
||||
```markdown
|
||||
# <project> 計畫
|
||||
|
||||
<一段計畫說明。>
|
||||
|
||||
| 頁面 | 內容 |
|
||||
|------|------|
|
||||
| [<page title>](<page title percent-encoded, 空白用 %20>) | <頁面內容摘要> |
|
||||
|
||||
產出日期：yyyy-MM-dd
|
||||
```
|
||||
|
||||
若目錄頁已存在且不是單一計畫專用目錄，仍以同一張 `| 頁面 | 內容 |` 表格為準：保留原標題與說明，只在表格中 upsert 本計畫頁面列。連結文字用頁面 title；連結 target 用 `encodeURIComponent(title).replace(/%20/g, "%20")` 的結果，不使用 API `sub_url` 反推人工連結。
|
||||
|
||||
## 計畫頁格式
|
||||
|
||||
計畫頁使用 Markdown，至少包含：
|
||||
|
||||
```markdown
|
||||
# <page title>
|
||||
|
||||
## 目標
|
||||
|
||||
## 背景與限制
|
||||
|
||||
## 範圍
|
||||
|
||||
## 方案
|
||||
|
||||
## 待確認
|
||||
|
||||
## TODO
|
||||
- [ ] ...
|
||||
```
|
||||
|
||||
已有計畫頁時保留使用者明確保留的內容；每輪只更新本 skill 管理的章節。需求不明的部分放在 `## 待確認`，不得自行補完。
|
||||
|
||||
## 階段 C：逐步詢問
|
||||
|
||||
每輪最多問 1～3 個問題，問題必須能推進計畫內容。建議順序：
|
||||
|
||||
1. 計畫目標與成功標準。
|
||||
2. 使用者、情境、限制條件。
|
||||
3. 功能範圍與明確不做的範圍。
|
||||
4. 方案拆解、資料流、外部依賴。
|
||||
5. 里程碑、驗收項目、風險與待確認。
|
||||
|
||||
每輪回答後：
|
||||
|
||||
- 將回答整合進計畫頁。
|
||||
- 把仍不明確的點列入 `## 待確認`。
|
||||
- 產出或更新 `## TODO` checklist，格式依 `spec-todo-list`。
|
||||
- 詢問使用者下一輪問題前，先完成階段 D 的 wiki 同步。
|
||||
|
||||
使用者明確表示「完成」「先到這裡」「計畫完成」時，進入階段 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 必須由工具呼叫或記憶中內容直接送出，不得先寫成本機 JSON 或 Markdown 檔。
|
||||
- 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 --index 目錄 --project Kokorone --page "Kokorone 系統架構計畫"` |
|
||||
| Codex | `$plan-wiki --wiki-repo knowledges/Plan --index 目錄 --project Kokorone` |
|
||||
| OpenCode | 描述需求（如「逐步問我計畫內容，並同步到 Gitea wiki 目錄與頁面」）自動觸發 |
|
||||
Reference in New Issue
Block a user