feat: add ProjectManager skill package

包含 5 個專案管理 skills、2 個主專案定義、4 個共用規則及 dashboard。 Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
docs: add skill-review to README
2026-03-13 12:02:15 +08:00 · 2026-03-13 11:11:52 +08:00 · 2026-03-13 11:11:27 +08:00
16 changed files with 922 additions and 1 deletions
--- a/ProjectManager/README.md
+++ b/ProjectManager/README.md
@@ -0,0 +1,12 @@
 # OpenClaw Project Package
 此資料夾為可直接匯入或參考的原始檔案結構，包含：
 - `skills/`：5 個 OpenClaw skills
 - `rules/`：附件、文件編號、SOP、工作記錄模板
 - `dashboards/`：專案總覽
 - `projects/`：2 個主專案的 `project.yaml`
 ## 主專案
 - `P-ONLINE-DOC-AGENT`
 - `P-ETL-VISUAL-PLATFORM`
--- a/ProjectManager/dashboards/projects-overview.md
+++ b/ProjectManager/dashboards/projects-overview.md
@@ -0,0 +1,30 @@
 # Projects Overview
 ## 主專案總覽
 | Project ID | 名稱 | 狀態 | 進度 | 下一步 |
 |---|---|---:|---:|---|
 | P-ONLINE-DOC-AGENT | Agent 操作線上文件系統 | active | 25% | 建立 EFLOW 附件規則 |
 | P-ETL-VISUAL-PLATFORM | ETL 資料庫轉換可視化網頁 | active | 35% | 建立 SP 與目標欄位 mapping v1 |
 ## 子專案總覽
 ### P-ONLINE-DOC-AGENT
 | Subproject ID | 名稱 | 狀態 | 備註 |
 |---|---|---|---|
 | SP-OFFICIAL-DOC | 線上公文操作 | doing | 建立 SOP v1 |
 | SP-EFLOW | EFLOW 操作 | doing | 整理送件與附件流程 |
 | SP-FORMBUILD | FORMBUILD 操作 | todo | 尚待蒐集畫面與欄位 |
 | SP-ATTACHMENT-RULES | 附件規則 | doing | 定義資料夾與命名 |
 | SP-DOC-ID-RULES | 文件編號規則 | todo | 定義 CASE 與系統編號 |
 ### P-ETL-VISUAL-PLATFORM
 | Subproject ID | 名稱 | 狀態 | 備註 |
 |---|---|---|---|
 | SP-ETL-PIPELINE | ETL 流程整理 | doing | 蒐集流程與來源資料 |
 | SP-DB-SP-ANALYSIS | SP 分析 | doing | 匯整 SP 清單 |
 | SP-TARGET-FIELD-MAPPING | 目標欄位 mapping | todo | 建立欄位對照表 |
 | SP-LLM-DIFF-CHECK | LLM 差異比對 | todo | 定義比較規則 |
 | SP-VISUAL-WEB | 可視化頁面 | todo | 定義顯示模組 |
--- a/ProjectManager/projects/P-ETL-VISUAL-PLATFORM/project.yaml
+++ b/ProjectManager/projects/P-ETL-VISUAL-PLATFORM/project.yaml
@@ -0,0 +1,13 @@
 project_id: P-ETL-VISUAL-PLATFORM
 name: ETL 資料庫轉換可視化網頁
 status: active
 objective: >-
  建立 ETL 資料庫轉換可視化網頁，並以 LLM 協助比對 Stored Procedure 與目標文件欄位差異。
 current_phase: analysis
 next_action: 建立 SP 與目標欄位 mapping 表 v1
 subprojects:
  - SP-ETL-PIPELINE
  - SP-DB-SP-ANALYSIS
  - SP-TARGET-FIELD-MAPPING
  - SP-LLM-DIFF-CHECK
  - SP-VISUAL-WEB
--- a/ProjectManager/projects/P-ONLINE-DOC-AGENT/project.yaml
+++ b/ProjectManager/projects/P-ONLINE-DOC-AGENT/project.yaml
@@ -0,0 +1,14 @@
 project_id: P-ONLINE-DOC-AGENT
 name: Agent 操作線上文件系統
 status: active
 objective: >-
  建立一套可由 Agent 依 SOP 操作的線上文件流程，涵蓋線上公文、EFLOW、FORMBUILD，
  並整合附件規則、文件編號規則與工作記錄。
 current_phase: definition
 next_action: 建立 EFLOW 附件規則與操作步驟 v1
 subprojects:
  - SP-OFFICIAL-DOC
  - SP-EFLOW
  - SP-FORMBUILD
  - SP-ATTACHMENT-RULES
  - SP-DOC-ID-RULES
--- a/ProjectManager/rules/attachment-filing-rules.md
+++ b/ProjectManager/rules/attachment-filing-rules.md
@@ -0,0 +1,27 @@
 # 附件歸檔規則
 ## 目錄結構
 ```text
 attachments/
  official-doc/
    DOC-YYYY-NNN/
  eflow/
    EFL-YYYY-NNN/
  formbuild/
    FBD-YYYY-NNN/
 ```
 ## 檔名格式
 `[文件編號]_[附件類型]_[版本]_[日期].[副檔名]`
 ### 範例
 - `DOC-2026-001_申請書_v1_2026-03-12.pdf`
 - `EFL-2026-003_核准函_v2_2026-03-12.pdf`
 ## Agent 上傳前檢查
 - 是否有文件編號
 - 是否放在正確資料夾
 - 檔名是否正確
 - 版本是否正確
 - 是否缺少必要附件
--- a/ProjectManager/rules/doc-id-convention.md
+++ b/ProjectManager/rules/doc-id-convention.md
@@ -0,0 +1,20 @@
 # 文件編號規則
 ## 系統文件編號
 - 線上公文：`DOC-YYYY-NNN`
 - EFLOW：`EFL-YYYY-NNN`
 - FORMBUILD：`FBD-YYYY-NNN`
 ## 跨系統案件編號
 - `CASE-YYYY-NNN`
 ## 範例
 - `CASE-2026-015`
  - `DOC-2026-021`
  - `EFL-2026-009`
 ## 規則
 1. 新建文件前先判斷系統類型
 2. 若屬同一案件，優先掛既有 CASE-ID
 3. 所有附件檔名必須以前述文件編號開頭
 4. 文件記錄中需保留 CASE 與系統文件編號的對應
--- a/ProjectManager/rules/web-operation-sop.md
+++ b/ProjectManager/rules/web-operation-sop.md
@@ -0,0 +1,40 @@
 # Web Operation SOP Template
 ## 系統名稱
 - 線上公文 / EFLOW / FORMBUILD
 ## 操作目的
 - 例如：建立新案件、送件、補附件、更新欄位
 ## 前置資料
 - 帳號/登入條件
 - 文件編號
 - CASE-ID（若有）
 - 附件清單
 - 欄位資料
 ## 操作步驟
 1. 進入系統
 2. 開啟目標頁面
 3. 輸入或確認必要欄位
 4. 上傳附件
 5. 執行送出或儲存
 6. 確認結果
 ## 上傳附件檢查
 - 路徑：
 - 檔名：
 - 版本：
 - 是否齊全：
 ## 結果記錄
 - 成功 / 失敗 / 阻塞
 - 畫面狀態
 - 文件編號
 - 下一步
 ## 常見錯誤
 - 登入失敗
 - 欄位缺漏
 - 附件格式不符
 - 權限不足
--- a/ProjectManager/rules/worklog-format.md
+++ b/ProjectManager/rules/worklog-format.md
@@ -0,0 +1,25 @@
 # Worklog Format
 ## 日期
 - YYYY-MM-DD
 ## 所屬主專案
 - P-ONLINE-DOC-AGENT / P-ETL-VISUAL-PLATFORM
 ## 所屬子專案
 - 例如：SP-EFLOW
 ## 本次完成
 - 
 ## 本次阻塞
 - 
 ## 使用文件 / 附件
 - 
 ## 文件編號 / CASE-ID
 - 
 ## 下一步
 - 
--- a/ProjectManager/skills/attachment-filing-rules/SKILL.md
+++ b/ProjectManager/skills/attachment-filing-rules/SKILL.md
@@ -0,0 +1,62 @@
 ---
 name: attachment-filing-rules
 description: 用於規範不同線上系統所需附件的資料夾放置、命名、版本與 Agent 取用方式。
 ---
 # Purpose
 本 skill 用來統一附件管理，讓 Agent 能穩定找到正確檔案並完成上傳。
 # Scope
 適用系統：
 - 線上公文
 - EFLOW
 - FORMBUILD
 # Folder Structure
 ```text
 attachments/
  official-doc/
    DOC-YYYY-NNN/
  eflow/
    EFL-YYYY-NNN/
  formbuild/
    FBD-YYYY-NNN/
 ```
 # File Naming Convention
 格式：
 `[文件編號]_[附件類型]_[版本]_[日期].[副檔名]`
 範例：
 - `DOC-2026-001_申請書_v1_2026-03-12.pdf`
 - `EFL-2026-003_核准函_v2_2026-03-12.pdf`
 - `FBD-2026-007_附件清單_v1_2026-03-12.xlsx`
 # Rules
 ## 1. 上傳前檢查
 Agent 上傳附件前必須確認：
 1. 有文件編號
 2. 位於正確系統資料夾
 3. 檔名格式正確
 4. 版本號正確
 5. 是最新檔案
 6. 必要附件已齊全
 ## 2. 禁止事項
 - 不可上傳檔名不明或臨時檔
 - 不可上傳無版本資訊之重複檔案
 - 不可跨系統誤用資料夾中的附件
 ## 3. 回應格式
 當被要求尋找或準備附件時，回應：
 - 系統類型
 - 文件編號
 - 預期附件類型
 - 建議資料夾路徑
 - 檔名檢查結果
 - 缺漏項目
--- a/ProjectManager/skills/doc-id-convention/SKILL.md
+++ b/ProjectManager/skills/doc-id-convention/SKILL.md
@@ -0,0 +1,54 @@
 ---
 name: doc-id-convention
 description: 用於規範線上公文、EFLOW、FORMBUILD 的文件編號與跨系統案件識別方式。
 ---
 # Purpose
 本 skill 用來讓文件、附件、案件、流程之間能一致對應。
 # ID Types
 ## 1. 系統文件編號
 - 線上公文：`DOC-YYYY-NNN`
 - EFLOW：`EFL-YYYY-NNN`
 - FORMBUILD：`FBD-YYYY-NNN`
 範例：
 - `DOC-2026-001`
 - `EFL-2026-014`
 - `FBD-2026-007`
 ## 2. 案件編號（跨系統）
 若同一件事情會跨多個系統，建立案件編號：
 - `CASE-YYYY-NNN`
 範例：
 - `CASE-2026-015`
  - `DOC-2026-021`
  - `EFL-2026-009`
 # Rules
 ## 1. 新建文件
 - 先判斷系統類型
 - 分配對應前綴編號
 - 確認是否屬於既有 CASE
 ## 2. 附件命名
 所有附件檔名必須以前述文件編號開頭。
 ## 3. 記錄關聯
 若文件跨系統，必須明確記錄：
 - CASE-ID
 - 各系統文件編號
 - 關聯說明
 # Response Format
 當需要建立或查詢文件編號時，輸出：
 - 系統類型
 - 是否已有 CASE-ID
 - 建議文件編號
 - 關聯文件
 - 建議資料夾名稱
--- a/ProjectManager/skills/etl-visual-project/SKILL.md
+++ b/ProjectManager/skills/etl-visual-project/SKILL.md
@@ -0,0 +1,76 @@
 ---
 name: etl-visual-project
 description: 用於管理 ETL 資料庫轉換可視化網頁專案，並包含 SP 分析、目標欄位 mapping 與 LLM 差異比對。
 ---
 # Purpose
 此 skill 用於處理：
 - ETL 資料流程整理
 - Stored Procedure 分析
 - 目標文件欄位 mapping
 - LLM 比較 SP 與目標欄位差異
 - 可視化網頁的需求與模組規劃
 # Project
 主專案：
 `P-ETL-VISUAL-PLATFORM`
 子專案：
 - `SP-ETL-PIPELINE`
 - `SP-DB-SP-ANALYSIS`
 - `SP-TARGET-FIELD-MAPPING`
 - `SP-LLM-DIFF-CHECK`
 - `SP-VISUAL-WEB`
 # Core Objective
 建立一套能呈現 ETL 資料庫轉換流程的可視化網頁。
 # Branch Objective
 使用 LLM 比較：
 - Stored Procedure 輸出或邏輯
 - 目標文件定義的欄位
 - 欄位差異與缺漏
 - 型別差異
 - 命名差異
 - 規則差異
 # Workflow
 ## 1. 資料蒐集
 - 蒐集 SP 清單
 - 蒐集目標文件欄位定義
 - 蒐集資料表與 ETL 流向
 ## 2. Mapping
 - 建立欄位對照表
 - 標記來源欄位、目標欄位、轉換規則
 ## 3. LLM Diff Check
 - 比較 SP 欄位與目標文件欄位
 - 輸出缺漏、命名不一致、型別不一致
 ## 4. Visual Web
 - 定義頁面模組
 - 呈現流程圖、欄位 mapping、差異報表
 # Standard Output
 每次回應時，輸出：
 1. 所屬子專案
 2. 本次目標
 3. 所需輸入資料
 4. 產出物
 5. 差異或阻塞
 6. 下一步
 # Example Tasks
 - 匯出 SP 欄位清單
 - 建立目標文件欄位表
 - 建立 mapping 表 v1
 - 用 LLM 產出欄位差異報告
 - 設計 ETL 可視化頁面需求草稿
--- a/ProjectManager/skills/online-doc-agent-ops/SKILL.md
+++ b/ProjectManager/skills/online-doc-agent-ops/SKILL.md
@@ -0,0 +1,88 @@
 ---
 name: online-doc-agent-ops
 description: 用於協助 Agent 操作線上文件系統，包括線上公文、EFLOW、FORMBUILD，並依 SOP、附件規則、文件編號規則執行。
 ---
 # Purpose
 此 skill 用於管理與執行以下系統的 Agent 操作：
 - 線上公文
 - EFLOW
 - FORMBUILD
 # Supported Scope
 ## 主專案
 `P-ONLINE-DOC-AGENT`
 ## 子專案
 - `SP-OFFICIAL-DOC`
 - `SP-EFLOW`
 - `SP-FORMBUILD`
 - `SP-ATTACHMENT-RULES`
 - `SP-DOC-ID-RULES`
 # Execution Rules
 ## 1. 操作前必做檢查
 每次操作前，先確認：
 1. 目標系統是什麼
 2. 這次操作的目的為何
 3. 是否需要附件
 4. 是否已有文件編號
 5. 是否需要建立操作記錄
 ## 2. 系統判斷
 ### 線上公文
 適用於：公文建立、上傳、送簽、帶附件等流程
 ### EFLOW
 適用於：流程送件、附件上傳、流程狀態追蹤等
 ### FORMBUILD
 適用於：表單填寫、欄位輸入、附件上傳、資料提交等
 ## 3. 附件處理規則
 若系統需要附件：
 - 先取得文件編號
 - 依系統類型到指定資料夾找檔案
 - 驗證檔名是否符合規則
 - 驗證是否為最新版本
 - 驗證附件是否齊全
 ## 4. 操作輸出
 每次完成操作後，至少記錄：
 - 日期時間
 - 操作系統
 - 文件編號
 - 操作目的
 - 使用附件
 - 結果（成功 / 失敗 / 阻塞）
 - 下一步
 # Standard Response Format
 當使用此 skill 時，請依下列格式回應：
 1. 系統名稱
 2. 本次操作目的
 3. 需要的前置資料
 4. 執行步驟
 5. 附件檢查
 6. 完成後記錄
 7. 可能錯誤與處理方式
 # Subsystem Notes
 ## SP-OFFICIAL-DOC
 重點：公文流程、附件、送件狀態
 ## SP-EFLOW
 重點：流程節點、附件、送件前檢查
 ## SP-FORMBUILD
 重點：表單欄位、填寫規則、送出驗證
--- a/ProjectManager/skills/project-governance/SKILL.md
+++ b/ProjectManager/skills/project-governance/SKILL.md
@@ -0,0 +1,98 @@
 ---
 name: project-governance
 description: 用於判斷新工作應歸屬哪個主專案、子專案或共用規則，並維持專案、子專案、任務、規則四個層級的邊界清楚。
 ---
 # Purpose
 此 skill 用來避免將「類別、專案、子專案、任務」混淆。
 適用於以下情境：
 - 使用者提出新的工作、想法或需求
 - 需要判斷是否建立新專案或新子專案
 - 需要把任務正確掛到既有專案
 - 需要判斷某件事是共用規則，而不是專案內容
 # Core Rules
 ## 1. 四層模型
 1. 規則（Rules）
   - 共用命名規範
   - 文件編號規則
   - 附件歸檔規則
   - SOP 與記錄格式
 2. 主專案（Projects）
   - `P-ONLINE-DOC-AGENT`
   - `P-ETL-VISUAL-PLATFORM`
 3. 子專案（Subprojects）
   - 某主專案下的模組、工作流、系統分支
 4. 任務（Tasks）
   - 可執行、可完成、可驗收的最小工作單位
 ## 2. 分類判斷規則
 當收到新工作時，依序判斷：
 ### A. 這是共用規則嗎？
 若是關於以下內容，歸入 Rules：
 - 附件資料夾如何放
 - 文件怎麼編號
 - Agent 如何記錄工作
 - 線上操作 SOP 的共同格式
 ### B. 這是屬於哪個主專案？
 - 若與線上公文、EFLOW、FORMBUILD 的操作、自動化、附件、送件流程有關，歸入 `P-ONLINE-DOC-AGENT`
 - 若與 ETL、Stored Procedure、欄位 mapping、LLM 比對、資料轉換可視化頁面有關，歸入 `P-ETL-VISUAL-PLATFORM`
 ### C. 是否應建立子專案？
 符合以下任一條件時，建立子專案：
 - 有獨立系統或獨立頁面
 - 有獨立流程或 SOP
 - 有獨立輸入輸出或文件產出
 - 有明顯可拆分的技術模組
 ### D. 是否只是任務？
 若該工作可在單次工作期內完成，且有明確完成條件，則建立為任務，不建立子專案。
 # Required Output Format
 在分析新工作時，固定輸出：
 1. 歸屬層級：Rule / Project / Subproject / Task
 2. 所屬主專案
 3. 所屬子專案（若有）
 4. 建議任務名稱
 5. 下一步最小可執行動作
 6. 是否需要寫入工作記錄
 # Examples
 ## Example 1
 輸入：EFLOW 送件時要帶 PDF 附件，並確認檔名格式
 輸出：
 - 層級：Rule + Task
 - 主專案：P-ONLINE-DOC-AGENT
 - 子專案：SP-EFLOW / SP-ATTACHMENT-RULES
 - 任務：定義 EFLOW 附件命名與上傳前檢查規則
 - 下一步：建立 EFLOW 附件規則草稿 v1
 ## Example 2
 輸入：比較 Stored Procedure 輸出欄位與目標文件欄位差異
 輸出：
 - 層級：Subproject + Task
 - 主專案：P-ETL-VISUAL-PLATFORM
 - 子專案：SP-LLM-DIFF-CHECK
 - 任務：建立 SP 與目標文件欄位對照表 v1
 - 下一步：蒐集 SP 欄位清單與目標文件欄位清單
 # Response Style
 - 優先做歸類，再做執行建議
 - 不把技術類別直接當成主專案
 - 若工作本質是規則，必須明確指出它不是獨立主專案
--- a/README.md
+++ b/README.md
@@ -23,6 +23,7 @@
 | `task-capture` | Telegram 快速記錄待辦（自動優先級 + 截止日） | 生活安排 |
 | `qmd-brain` | 知識庫搜尋（BM25 + pgvector 向量檢索） | 知識庫 |
 | `tts-voice` | 文字轉語音（LuxTTS 聲音克隆） | 多媒體 |
 | `skill-review` | Agent 自動審查 skills 並提交 Gitea PR | DevOps |
 ## 目錄結構
@@ -37,7 +38,8 @@ openclaw-skill/
 │   ├── daily-briefing/      # 每日簡報
 │   ├── task-capture/        # 快速記錄待辦
 │   ├── qmd-brain/           # 知識庫搜尋
-│   └── tts-voice/           # 文字轉語音
+│   ├── tts-voice/           # 文字轉語音
 │   └── skill-review/        # Agent PR 審查工作流
 ├── chapters/                # 技術手冊分章
 └── openclaw-knowhow-skill/  # OpenClaw 官方文件與範本
 ```
--- a/skills/skill-review/SKILL.md
+++ b/skills/skill-review/SKILL.md
@@ -0,0 +1,120 @@
 ---
 name: skill-review
 description: 審查 openclaw-skill repo 中的 Skills，提出改進建議並透過 Gitea PR 提交。每位 Agent 有各自的 fork，走標準 fork → branch → PR 流程。
 triggers:
  - "審查 skill"
  - "review skills"
  - "skill 改進"
  - "提 PR"
 tools:
  - exec
  - web_fetch
  - memory
 ---
 # Skill Review — Agent PR Workflow
 ## 你的身份
 你是一位有 Gitea 帳號的工程師，負責審查 `Selig/openclaw-skill` repo 中的 skills，提出改進並透過 PR 提交。
 ## 環境變數
 - `GITEA_URL`: Gitea 基礎 URL（https://git.nature.edu.kg）
 - `GITEA_TOKEN_<AGENT>`: 你的 Gitea API token（根據 agent ID 取對應的）
 - Agent → Gitea 帳號對應：
  - tiangong → `tiangong`（天工，架構/安全）
  - kaiwu → `kaiwu`（開物，UX/前端）
  - yucheng → `yucheng`（玉成，全棧/測試）
 ## 審查重點
 根據你的角色，重點審查不同面向：
 ### 天工（tiangong）— 架構設計師
 - SKILL.md 的 trigger 設計是否合理、會不會誤觸發
 - handler.ts 的錯誤處理、邊界情況
 - 安全性：有無注入風險、敏感資訊洩漏
 - Skill 之間的協作與依賴關係
 ### 開物（kaiwu）— 前端視覺
 - SKILL.md 的使用者體驗：描述是否清楚、觸發詞是否直覺
 - handler.ts 的輸出格式：Telegram markdown 排版、emoji 使用
 - 回覆內容的可讀性與美觀度
 ### 玉成（yucheng）— 全棧整合
 - handler.ts 的程式碼品質：型別安全、效能、可維護性
 - 缺少的功能或整合機會
 - 測試邊界：空值處理、異常輸入
 - 文件完整性
 ## 工作流程
 ### Step 1: 同步 fork
 ```
 POST /api/v1/repos/{owner}/{repo}/mirror-sync  # 如果有 mirror
 ```
 或者直接用最新的 upstream 內容。
 ### Step 2: 讀取所有 Skills
 讀取 repo 中 `skills/` 目錄下的每個 skill 的 SKILL.md 和 handler.ts。
 ### Step 3: 選擇改進目標
 - 每次只改 **1 個 skill 的 1 個面向**（小而精確的 PR）
 - 如果所有 skill 都很好，可以提出新 skill 的建議
 ### Step 4: 透過 Gitea API 提交
 1. **建立分支**（從 main）
   ```
   POST /api/v1/repos/{owner}/{repo}/branches
   {"new_branch_name": "improve/daily-briefing-error-handling", "old_branch_name": "main"}
   ```
 2. **更新檔案**
   ```
   PUT /api/v1/repos/{owner}/{repo}/contents/{filepath}
   {"content": "<base64>", "message": "commit message", "branch": "improve/...", "sha": "<current-sha>"}
   ```
 3. **建立 PR**（從 fork 到 upstream）
   ```
   POST /api/v1/repos/Selig/openclaw-skill/pulls
   {
     "title": "improve(daily-briefing): 加強天氣查詢錯誤處理",
     "body": "## 改進說明\n...\n## 變更內容\n...\n## 測試建議\n...",
     "head": "<agent-username>:improve/daily-briefing-error-handling",
     "base": "main"
   }
   ```
 ## PR 格式規範
 ### 標題
 ```
 <type>(<skill>): <簡述>
 ```
 Type: `improve`, `fix`, `feat`, `docs`, `refactor`
 ### 內文
 ```markdown
 ## 改進說明
 為什麼要做這個改動？發現了什麼問題？
 ## 變更內容
 - 具體改了什麼
 ## 測試建議
 - 如何驗證這個改動是正確的
 ---
 🤖 由 <agent-name> 自動審查並提交
 ```
 ## 注意事項
 - **一次只提一個 PR**，不要批量修改多個 skill
 - **不要修改** handler.ts 中涉及認證、密碼、token 的部分
 - **不要刪除** 現有功能，只能改進或新增
 - 如果沒有值得改進的地方，回覆「所有 Skills 目前狀態良好，無需改動」即可
 - PR 建立後，回覆 PR 的 URL 讓使用者知道
--- a/skills/skill-review/handler.ts
+++ b/skills/skill-review/handler.ts
@@ -0,0 +1,240 @@
 /**
 * skill-review handler
 * 提供 Gitea API 操作的輔助函式，供 agent 審查 skill 並提交 PR。
 */
 const GITEA_URL = process.env.GITEA_URL || 'https://git.nature.edu.kg';
 const UPSTREAM_OWNER = 'Selig';
 const REPO_NAME = 'openclaw-skill';
 // Agent ID → Gitea 帳號 & token 環境變數對應
 const AGENT_MAP: Record<string, { username: string; tokenEnv: string }> = {
  tiangong: { username: 'tiangong', tokenEnv: 'GITEA_TOKEN_TIANGONG' },
  kaiwu: { username: 'kaiwu', tokenEnv: 'GITEA_TOKEN_KAIWU' },
  yucheng: { username: 'yucheng', tokenEnv: 'GITEA_TOKEN_YUCHENG' },
 };
 interface GiteaFile {
  name: string;
  path: string;
  sha: string;
  content?: string;
  encoding?: string;
 }
 async function giteaApi(
  token: string,
  method: string,
  path: string,
  body?: any
 ): Promise<any> {
  const url = `${GITEA_URL}/api/v1${path}`;
  const opts: RequestInit = {
    method,
    headers: {
      Authorization: `token ${token}`,
      'Content-Type': 'application/json',
    },
  };
  if (body) opts.body = JSON.stringify(body);
  const res = await fetch(url, opts);
  const text = await res.text();
  if (!res.ok) {
    throw new Error(`Gitea API ${method} ${path} → ${res.status}: ${text}`);
  }
  return text ? JSON.parse(text) : null;
 }
 /** 同步 fork（用 Gitea merge upstream API） */
 async function syncFork(token: string, owner: string): Promise<void> {
  try {
    // Gitea 1.25: POST /repos/{owner}/{repo}/merge-upstream
    await giteaApi(token, 'POST', `/repos/${owner}/${REPO_NAME}/merge-upstream`, {
      branch: 'main',
    });
  } catch (e: any) {
    // 如果 API 不存在或已同步，忽略
    if (!e.message.includes('409')) {
      console.warn('syncFork warning:', e.message);
    }
  }
 }
 /** 列出 skills 目錄下的所有 skill */
 async function listSkills(token: string, owner: string): Promise<string[]> {
  const items = await giteaApi(
    token,
    'GET',
    `/repos/${owner}/${REPO_NAME}/contents/skills?ref=main`
  );
  return items
    .filter((item: any) => item.type === 'dir')
    .map((item: any) => item.name);
 }
 /** 讀取檔案內容 */
 async function readFile(
  token: string,
  owner: string,
  filepath: string,
  ref = 'main'
 ): Promise<GiteaFile> {
  return giteaApi(
    token,
    'GET',
    `/repos/${owner}/${REPO_NAME}/contents/${filepath}?ref=${ref}`
  );
 }
 /** 建立分支 */
 async function createBranch(
  token: string,
  owner: string,
  branchName: string
 ): Promise<void> {
  await giteaApi(token, 'POST', `/repos/${owner}/${REPO_NAME}/branches`, {
    new_branch_name: branchName,
    old_branch_name: 'main',
  });
 }
 /** 更新檔案（需要 sha） */
 async function updateFile(
  token: string,
  owner: string,
  filepath: string,
  content: string,
  sha: string,
  branch: string,
  message: string
 ): Promise<void> {
  const b64 = Buffer.from(content, 'utf-8').toString('base64');
  await giteaApi(
    token,
    'PUT',
    `/repos/${owner}/${REPO_NAME}/contents/${filepath}`,
    { content: b64, sha, message, branch }
  );
 }
 /** 建立新檔案 */
 async function createFile(
  token: string,
  owner: string,
  filepath: string,
  content: string,
  branch: string,
  message: string
 ): Promise<void> {
  const b64 = Buffer.from(content, 'utf-8').toString('base64');
  await giteaApi(
    token,
    'POST',
    `/repos/${owner}/${REPO_NAME}/contents/${filepath}`,
    { content: b64, message, branch }
  );
 }
 /** 建立 PR（從 fork 到 upstream） */
 async function createPR(
  token: string,
  agentUsername: string,
  title: string,
  body: string,
  branch: string
 ): Promise<{ url: string; number: number }> {
  const pr = await giteaApi(
    token,
    'POST',
    `/repos/${UPSTREAM_OWNER}/${REPO_NAME}/pulls`,
    {
      title,
      body,
      head: `${agentUsername}:${branch}`,
      base: 'main',
    }
  );
  return { url: pr.html_url, number: pr.number };
 }
 export async function handler(ctx: any) {
  // 偵測當前 agent
  const agentId = ctx.env?.OPENCLAW_AGENT_ID || ctx.agentId || 'unknown';
  const agentConfig = AGENT_MAP[agentId];
  if (!agentConfig) {
    return {
      reply: `❌ 無法辨識 agent: ${agentId}\n支援的 agent: ${Object.keys(AGENT_MAP).join(', ')}`,
    };
  }
  const token = ctx.env?.[agentConfig.tokenEnv] || process.env[agentConfig.tokenEnv];
  if (!token) {
    return {
      reply: `❌ 找不到 ${agentConfig.tokenEnv}，請確認 .env 設定。`,
    };
  }
  const username = agentConfig.username;
  try {
    // Step 1: 同步 fork
    await syncFork(token, username);
    // Step 2: 列出所有 skills
    const skills = await listSkills(token, username);
    // Step 3: 讀取每個 skill 的內容
    const skillContents: Record<string, { skillMd: string; handlerTs: string }> = {};
    for (const skill of skills) {
      try {
        const skillMdFile = await readFile(token, username, `skills/${skill}/SKILL.md`);
        const handlerFile = await readFile(token, username, `skills/${skill}/handler.ts`);
        skillContents[skill] = {
          skillMd: Buffer.from(skillMdFile.content || '', 'base64').toString('utf-8'),
          handlerTs: Buffer.from(handlerFile.content || '', 'base64').toString('utf-8'),
        };
      } catch {
        // 跳過讀取失敗的 skill
      }
    }
    // 回傳資料供 agent 分析
    return {
      reply: `✅ Fork 已同步，共讀取 ${Object.keys(skillContents).length} 個 skills。\n\n請根據你的角色審查以下 skills，選擇一個提出改進 PR。`,
      data: {
        agentId,
        username,
        skills: skillContents,
        // 提供 API helper 資訊，讓 agent 知道可以用 exec 呼叫
        api: {
          createBranch: 'handler.createBranch(token, owner, branchName)',
          updateFile: 'handler.updateFile(token, owner, filepath, content, sha, branch, message)',
          createFile: 'handler.createFile(token, owner, filepath, content, branch, message)',
          createPR: 'handler.createPR(token, agentUsername, title, body, branch)',
        },
      },
      metadata: { agentId, username, skillCount: Object.keys(skillContents).length },
    };
  } catch (err: any) {
    return {
      reply: `❌ 執行失敗: ${err.message}`,
      error: err.message,
    };
  }
 }
 // 匯出 helper 供 agent 透過 exec 使用
 export {
  syncFork,
  listSkills,
  readFile,
  createBranch,
  updateFile,
  createFile,
  createPR,
  giteaApi,
  AGENT_MAP,
 };