feat: add ProjectManager skill package
包含 5 個專案管理 skills、2 個主專案定義、4 個共用規則及 dashboard。 Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
62
ProjectManager/skills/attachment-filing-rules/SKILL.md
Normal file
62
ProjectManager/skills/attachment-filing-rules/SKILL.md
Normal file
@@ -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. 回應格式
|
||||
當被要求尋找或準備附件時,回應:
|
||||
- 系統類型
|
||||
- 文件編號
|
||||
- 預期附件類型
|
||||
- 建議資料夾路徑
|
||||
- 檔名檢查結果
|
||||
- 缺漏項目
|
||||
54
ProjectManager/skills/doc-id-convention/SKILL.md
Normal file
54
ProjectManager/skills/doc-id-convention/SKILL.md
Normal file
@@ -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
|
||||
- 建議文件編號
|
||||
- 關聯文件
|
||||
- 建議資料夾名稱
|
||||
76
ProjectManager/skills/etl-visual-project/SKILL.md
Normal file
76
ProjectManager/skills/etl-visual-project/SKILL.md
Normal file
@@ -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 可視化頁面需求草稿
|
||||
88
ProjectManager/skills/online-doc-agent-ops/SKILL.md
Normal file
88
ProjectManager/skills/online-doc-agent-ops/SKILL.md
Normal file
@@ -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
|
||||
重點:表單欄位、填寫規則、送出驗證
|
||||
98
ProjectManager/skills/project-governance/SKILL.md
Normal file
98
ProjectManager/skills/project-governance/SKILL.md
Normal file
@@ -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
|
||||
|
||||
- 優先做歸類,再做執行建議
|
||||
- 不把技術類別直接當成主專案
|
||||
- 若工作本質是規則,必須明確指出它不是獨立主專案
|
||||
Reference in New Issue
Block a user