Compare commits
1 Commits
main
...
improve/di
| Author | SHA1 | Date | |
|---|---|---|---|
| 5918d671bb |
@@ -1,12 +0,0 @@
|
|||||||
# OpenClaw Project Package
|
|
||||||
|
|
||||||
此資料夾為可直接匯入或參考的原始檔案結構，包含：
|
|
||||||
|
|
||||||
- `skills/`：5 個 OpenClaw skills
|
|
||||||
- `rules/`：附件、文件編號、SOP、工作記錄模板
|
|
||||||
- `dashboards/`：專案總覽
|
|
||||||
- `projects/`：2 個主專案的 `project.yaml`
|
|
||||||
|
|
||||||
## 主專案
|
|
||||||
- `P-ONLINE-DOC-AGENT`
|
|
||||||
- `P-ETL-VISUAL-PLATFORM`
|
|
||||||
@@ -1,30 +0,0 @@
|
|||||||
# 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 | 定義顯示模組 |
|
|
||||||
@@ -1,13 +0,0 @@
|
|||||||
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
|
|
||||||
@@ -1,14 +0,0 @@
|
|||||||
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
|
|
||||||
@@ -1,27 +0,0 @@
|
|||||||
# 附件歸檔規則
|
|
||||||
|
|
||||||
## 目錄結構
|
|
||||||
|
|
||||||
```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 上傳前檢查
|
|
||||||
- 是否有文件編號
|
|
||||||
- 是否放在正確資料夾
|
|
||||||
- 檔名是否正確
|
|
||||||
- 版本是否正確
|
|
||||||
- 是否缺少必要附件
|
|
||||||
@@ -1,20 +0,0 @@
|
|||||||
# 文件編號規則
|
|
||||||
|
|
||||||
## 系統文件編號
|
|
||||||
- 線上公文：`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 與系統文件編號的對應
|
|
||||||
@@ -1,40 +0,0 @@
|
|||||||
# Web Operation SOP Template
|
|
||||||
|
|
||||||
## 系統名稱
|
|
||||||
- 線上公文 / EFLOW / FORMBUILD
|
|
||||||
|
|
||||||
## 操作目的
|
|
||||||
- 例如：建立新案件、送件、補附件、更新欄位
|
|
||||||
|
|
||||||
## 前置資料
|
|
||||||
- 帳號/登入條件
|
|
||||||
- 文件編號
|
|
||||||
- CASE-ID（若有）
|
|
||||||
- 附件清單
|
|
||||||
- 欄位資料
|
|
||||||
|
|
||||||
## 操作步驟
|
|
||||||
1. 進入系統
|
|
||||||
2. 開啟目標頁面
|
|
||||||
3. 輸入或確認必要欄位
|
|
||||||
4. 上傳附件
|
|
||||||
5. 執行送出或儲存
|
|
||||||
6. 確認結果
|
|
||||||
|
|
||||||
## 上傳附件檢查
|
|
||||||
- 路徑：
|
|
||||||
- 檔名：
|
|
||||||
- 版本：
|
|
||||||
- 是否齊全：
|
|
||||||
|
|
||||||
## 結果記錄
|
|
||||||
- 成功 / 失敗 / 阻塞
|
|
||||||
- 畫面狀態
|
|
||||||
- 文件編號
|
|
||||||
- 下一步
|
|
||||||
|
|
||||||
## 常見錯誤
|
|
||||||
- 登入失敗
|
|
||||||
- 欄位缺漏
|
|
||||||
- 附件格式不符
|
|
||||||
- 權限不足
|
|
||||||
@@ -1,25 +0,0 @@
|
|||||||
# Worklog Format
|
|
||||||
|
|
||||||
## 日期
|
|
||||||
- YYYY-MM-DD
|
|
||||||
|
|
||||||
## 所屬主專案
|
|
||||||
- P-ONLINE-DOC-AGENT / P-ETL-VISUAL-PLATFORM
|
|
||||||
|
|
||||||
## 所屬子專案
|
|
||||||
- 例如：SP-EFLOW
|
|
||||||
|
|
||||||
## 本次完成
|
|
||||||
-
|
|
||||||
|
|
||||||
## 本次阻塞
|
|
||||||
-
|
|
||||||
|
|
||||||
## 使用文件 / 附件
|
|
||||||
-
|
|
||||||
|
|
||||||
## 文件編號 / CASE-ID
|
|
||||||
-
|
|
||||||
|
|
||||||
## 下一步
|
|
||||||
-
|
|
||||||
@@ -1,62 +0,0 @@
|
|||||||
---
|
|
||||||
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. 回應格式
|
|
||||||
當被要求尋找或準備附件時，回應：
|
|
||||||
- 系統類型
|
|
||||||
- 文件編號
|
|
||||||
- 預期附件類型
|
|
||||||
- 建議資料夾路徑
|
|
||||||
- 檔名檢查結果
|
|
||||||
- 缺漏項目
|
|
||||||
@@ -1,54 +0,0 @@
|
|||||||
---
|
|
||||||
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
|
|
||||||
- 建議文件編號
|
|
||||||
- 關聯文件
|
|
||||||
- 建議資料夾名稱
|
|
||||||
@@ -1,76 +0,0 @@
|
|||||||
---
|
|
||||||
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 可視化頁面需求草稿
|
|
||||||
@@ -1,88 +0,0 @@
|
|||||||
---
|
|
||||||
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
|
|
||||||
重點：表單欄位、填寫規則、送出驗證
|
|
||||||
@@ -1,98 +0,0 @@
|
|||||||
---
|
|
||||||
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
|
|
||||||
|
|
||||||
- 優先做歸類，再做執行建議
|
|
||||||
- 不把技術類別直接當成主專案
|
|
||||||
- 若工作本質是規則，必須明確指出它不是獨立主專案
|
|
||||||
@@ -23,7 +23,6 @@
|
|||||||
| `task-capture` | Telegram 快速記錄待辦（自動優先級 + 截止日） | 生活安排 |
|
| `task-capture` | Telegram 快速記錄待辦（自動優先級 + 截止日） | 生活安排 |
|
||||||
| `qmd-brain` | 知識庫搜尋（BM25 + pgvector 向量檢索） | 知識庫 |
|
| `qmd-brain` | 知識庫搜尋（BM25 + pgvector 向量檢索） | 知識庫 |
|
||||||
| `tts-voice` | 文字轉語音（LuxTTS 聲音克隆） | 多媒體 |
|
| `tts-voice` | 文字轉語音（LuxTTS 聲音克隆） | 多媒體 |
|
||||||
| `skill-review` | Agent 自動審查 skills 並提交 Gitea PR | DevOps |
|
|
||||||
|
|
||||||
## 目錄結構
|
## 目錄結構
|
||||||
|
|
||||||
@@ -38,8 +37,7 @@ openclaw-skill/
|
|||||||
│ ├── daily-briefing/ # 每日簡報
|
│ ├── daily-briefing/ # 每日簡報
|
||||||
│ ├── task-capture/ # 快速記錄待辦
|
│ ├── task-capture/ # 快速記錄待辦
|
||||||
│ ├── qmd-brain/ # 知識庫搜尋
|
│ ├── qmd-brain/ # 知識庫搜尋
|
||||||
│ ├── tts-voice/ # 文字轉語音
|
│ └── tts-voice/ # 文字轉語音
|
||||||
│ └── skill-review/ # Agent PR 審查工作流
|
|
||||||
├── chapters/ # 技術手冊分章
|
├── chapters/ # 技術手冊分章
|
||||||
└── openclaw-knowhow-skill/ # OpenClaw 官方文件與範本
|
└── openclaw-knowhow-skill/ # OpenClaw 官方文件與範本
|
||||||
```
|
```
|
||||||
|
|||||||
@@ -12,6 +12,56 @@ interface DispatchInput {
|
|||||||
retries?: number;
|
retries?: number;
|
||||||
}
|
}
|
||||||
|
|
||||||
|
const ALLOWED_TARGETS = new Set<DispatchInput['target']>(['vps-a', 'vps-b']);
|
||||||
|
|
||||||
|
function clampInt(value: unknown, min: number, max: number, fallback: number): number {
|
||||||
|
const n = Number(value);
|
||||||
|
if (!Number.isFinite(n)) return fallback;
|
||||||
|
return Math.min(max, Math.max(min, Math.floor(n)));
|
||||||
|
}
|
||||||
|
|
||||||
|
function sanitizeTaskId(taskId: unknown): string {
|
||||||
|
if (taskId == null) return '';
|
||||||
|
return String(taskId).replace(/[\r\n]/g, '').slice(0, 128);
|
||||||
|
}
|
||||||
|
|
||||||
|
function validateInput(raw: any): DispatchInput {
|
||||||
|
const input = raw as Partial<DispatchInput>;
|
||||||
|
|
||||||
|
if (!input || typeof input !== 'object') {
|
||||||
|
throw new Error('dispatch-webhook 輸入格式錯誤：必須提供 input 物件');
|
||||||
|
}
|
||||||
|
|
||||||
|
if (!input.target || !ALLOWED_TARGETS.has(input.target as DispatchInput['target'])) {
|
||||||
|
throw new Error('dispatch-webhook 參數錯誤：target 必須是 vps-a 或 vps-b');
|
||||||
|
}
|
||||||
|
|
||||||
|
if (!input.webhookUrl || typeof input.webhookUrl !== 'string') {
|
||||||
|
throw new Error(`${input.target.toUpperCase()} Webhook URL 未設定。請在環境變數設定 VPS_A_WEBHOOK_URL 或 VPS_B_WEBHOOK_URL`);
|
||||||
|
}
|
||||||
|
|
||||||
|
let parsedUrl: URL;
|
||||||
|
try {
|
||||||
|
parsedUrl = new URL(input.webhookUrl);
|
||||||
|
} catch {
|
||||||
|
throw new Error('Webhook URL 格式錯誤，請提供有效的 http/https URL');
|
||||||
|
}
|
||||||
|
|
||||||
|
if (!['http:', 'https:'].includes(parsedUrl.protocol)) {
|
||||||
|
throw new Error('Webhook URL 協定不支援，僅允許 http 或 https');
|
||||||
|
}
|
||||||
|
|
||||||
|
if (!input.webhookToken || typeof input.webhookToken !== 'string') {
|
||||||
|
throw new Error(`${input.target.toUpperCase()} Webhook Token 未設定`);
|
||||||
|
}
|
||||||
|
|
||||||
|
if (!input.payload || typeof input.payload !== 'object' || Array.isArray(input.payload)) {
|
||||||
|
throw new Error('dispatch-webhook 參數錯誤：payload 必須是 JSON 物件');
|
||||||
|
}
|
||||||
|
|
||||||
|
return input as DispatchInput;
|
||||||
|
}
|
||||||
|
|
||||||
async function fetchWithTimeout(url: string, options: RequestInit, timeoutMs: number): Promise<Response> {
|
async function fetchWithTimeout(url: string, options: RequestInit, timeoutMs: number): Promise<Response> {
|
||||||
const controller = new AbortController();
|
const controller = new AbortController();
|
||||||
const timer = setTimeout(() => controller.abort(), timeoutMs);
|
const timer = setTimeout(() => controller.abort(), timeoutMs);
|
||||||
@@ -23,17 +73,11 @@ async function fetchWithTimeout(url: string, options: RequestInit, timeoutMs: nu
|
|||||||
}
|
}
|
||||||
|
|
||||||
export async function handler(ctx: any) {
|
export async function handler(ctx: any) {
|
||||||
const input: DispatchInput = ctx.input || ctx.params;
|
const input = validateInput(ctx.input || ctx.params);
|
||||||
|
|
||||||
if (!input.webhookUrl) {
|
const timeoutMs = clampInt(input.timeoutMs, 1000, 120000, 30000);
|
||||||
throw new Error(`${input.target.toUpperCase()} Webhook URL 未設定。請在環境變數設定 VPS_A_WEBHOOK_URL 或 VPS_B_WEBHOOK_URL`);
|
const maxRetries = clampInt(input.retries, 1, 5, 3);
|
||||||
}
|
const taskIdHeader = sanitizeTaskId(input.payload.task_id);
|
||||||
if (!input.webhookToken) {
|
|
||||||
throw new Error(`${input.target.toUpperCase()} Webhook Token 未設定`);
|
|
||||||
}
|
|
||||||
|
|
||||||
const timeoutMs = input.timeoutMs ?? 30000;
|
|
||||||
const maxRetries = input.retries ?? 3;
|
|
||||||
let lastError: Error | null = null;
|
let lastError: Error | null = null;
|
||||||
|
|
||||||
for (let attempt = 1; attempt <= maxRetries; attempt++) {
|
for (let attempt = 1; attempt <= maxRetries; attempt++) {
|
||||||
@@ -46,7 +90,7 @@ export async function handler(ctx: any) {
|
|||||||
'Content-Type': 'application/json',
|
'Content-Type': 'application/json',
|
||||||
'Authorization': `Bearer ${input.webhookToken}`,
|
'Authorization': `Bearer ${input.webhookToken}`,
|
||||||
'X-OpenClaw-Version': '1.0',
|
'X-OpenClaw-Version': '1.0',
|
||||||
'X-OpenClaw-Task-Id': String(input.payload.task_id || ''),
|
'X-OpenClaw-Task-Id': taskIdHeader,
|
||||||
},
|
},
|
||||||
body: JSON.stringify(input.payload),
|
body: JSON.stringify(input.payload),
|
||||||
},
|
},
|
||||||
@@ -72,8 +116,8 @@ export async function handler(ctx: any) {
|
|||||||
};
|
};
|
||||||
|
|
||||||
} catch (err: any) {
|
} catch (err: any) {
|
||||||
lastError = err;
|
lastError = err instanceof Error ? err : new Error(String(err));
|
||||||
if (err.message?.includes('401') || err.message?.includes('Token')) {
|
if (lastError.message.includes('401') || lastError.message.includes('Token')) {
|
||||||
break; // 認證錯誤不重試
|
break; // 認證錯誤不重試
|
||||||
}
|
}
|
||||||
if (attempt < maxRetries) {
|
if (attempt < maxRetries) {
|
||||||
|
|||||||
@@ -1,120 +0,0 @@
|
|||||||
---
|
|
||||||
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 讓使用者知道
|
|
||||||
@@ -1,240 +0,0 @@
|
|||||||
/**
|
|
||||||
* 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,
|
|
||||||
};
|
|
||||||
Reference in New Issue
Block a user