解構與重組：從開源程式庫中「借鑑」高品質 AI Skill
早期的 Skill（技能）開發會分為 Semantic 與 Native Skill。但現在的趨勢已經不再這樣細分，因為兩者通常寫在一起。取而代之的是「語意層（Semantic Layer）」與「執行層（Executive Layer）」的分類。
- 語意層：通常由提示詞組成，代表 Agent 的「大腦」，決定車要騎到哪、去做什麼。
- 執行層：由 Scripts 與參考文件組成，代表 Agent 的「小腦」，負責具體的平衡與手腳操作，確保騎車不跌倒。
例如我要做 API 會怎麼開始？當然先找 Manus 來 (解剖) 參考；如果要編寫技能，那絕對是找網路上大公司的開源 Skill 來「抄」——啊不，是「借鑑」。
我盯上的典範 Skill 程式庫
我最近深入掃描了這幾家的實作，非常具備參考價值：
- Anthropic：官方的 Claude Skill 實作。
- Anthropic：官方的 金融服務插件。
- Obra/Superpowers：極簡但強大的擴充架構。
- alirezarezvani：針對 Claude Code 的技能與插件。
- slavingia：極簡創業家（The Minimalist Entrepreneur）技能包。
我利用 Gemini 的代碼匯入功能，將這些程式庫掛載到我的 AI 助理下，並開始掃描、探索與提取所需的架構。
其實在你匯入程式碼的當下， 你就可以直接調動 skill 來使用了，如果你不想做任何修改。
方法論：三層級解耦設計 (The 3-Level Extraction)
提示詞輸入>_ 我想要透過這些新上傳的程式碼庫， 跟你討論如何從中取出其中的 skills 編寫的方法論。
透過橫向比對，我總結出了 Skill 的三層級編寫方法論：
三層級解耦設計 (The 3-Level Extraction)
Skills 核心結構
技能分為三個層級（Level 1-3）：
- 語意層（Level 1 & 2）：包含 SKILL.md 配置，定義了 Agent 的決策流程（Instructions）與元數據（Metadata）。
- 執行層（Level 3）：位於 scripts/ 目錄下的 Python 腳本，負責具體的檔案 I/O、計算與 Pydantic v2 數據驗證。
進階邏輯流：技能的核心在於策略
提示詞輸入>_ 代碼中的「邏輯流程」, 除了 COT, 決策樹之外, 還有看到什麼寫法？ 你有觀察到什麼可以用在寫邏輯流程上面的方法論？
然後總結出以下的方法論:
🧠 Agent Skill 邏輯架構設計方法論
在 Agent 技能開發中，Level 2 (語意邏輯層) 的核心任務是定義模型如何「思考」與「決策」。根據工業實踐與程式碼庫掃描，我們將邏輯流分為「基礎推理」與「進階調度」兩大類。
一、 基礎推理模式 (Foundational Reasoning)
1. 思考鏈 (Chain of Thought, CoT)
- 定義：要求模型在產出最終結果前，先進行連續的線性推理步驟。
- 寫法實踐：在
<instructions>中明確標記步驟，並鼓勵使用<thought>標籤記錄中間過程。 - 適用場景：簡單的邏輯轉換、文本生成、初步代碼解析。
2. 語意決策樹 (Semantic Decision Trees)
- 定義：基於 If-Then-Else 的分支邏輯，根據輸入特徵引導模型進入不同的處理分支。
- 寫法實踐：使用 XML 標籤模擬條件判斷，例如：
"若檢測到 API 密鑰丟失，跳轉至 <error_handling>；若參數完整，進入 <execute_logic>。"
- 適用場景：具有明確分類規則的任務、簡單的參數檢查。
二、 進階調度模式 (Advanced Orchestration)
3. 里程碑式流水線 (Sequential Milestone Pipeline)
- 定義：將長程任務強制拆解為
Task 1至Task N的物理階段。 - 核心邏輯：Agent 必須顯式確認當前任務的「退出準則 (Exit Criteria)」已達成，方可進行下一步。
- 適用場景：長篇研究報告撰寫、複雜的環境部署、多步驟數據遷移。
4. 遞歸委派模式 (Recursive Delegation / Subagent Pattern)
- 定義：邏輯核心不在於「執行」，而在於「分發」。
- 核心邏輯：定義決策條件，決定何時調度具備專屬任務的子代理（如：
code-reviewer）。 - 適用場景：代碼審查工作流、自動化測試生成、多模態協作任務。
5. 語意有限狀態機 (Semantic Finite State Machine, SFSM)
- 定義：基於環境反饋或使用者狀態，在預定義的「語意狀態」間跳轉。
- 核心邏輯：定義 States（探索、驗證、轉向、提交）與 Transitions（觸發遷移的語意詞）。
- 適用場景：互動式引導系統、動態商務談判、創業想法驗證。
6. 負向約束驅動 (Constraint-Driven Guardrails)
- 定義：不定義成功路徑，僅定義失敗邊界。
- 核心邏輯：大量使用
<constraints>與負向案例（Negative Examples），在安全邊界內給予 LLM 最高靈活性。 - 適用場景：金融合規審核、醫療安全建議、數據隱私保護。
7. 產出物中心驗證 (Artifact-Centered Validation)
- 定義：邏輯圍繞著「數據結構完整性」旋轉。
- 核心邏輯：要求 Agent 在調用 Python 前先進行 Schema 預演，若 Level 3 報錯（Pydantic 驗證失敗），則觸發自癒循環。
- 適用場景：結構化數據生成、API 自動整合、高精密計算。
💡 架構師建議：如何組合？
- 小型技能：CoT + 決策樹。
- 工業級技能：里程碑流水線 (管理大進度) + SFSM (處理小環節互動) + 負向約束 (確保合規) + Artifact 驗證 (保證 Level 3 產出正確)。
為什麼我要先做這件事？因為每個 Skill 最大的特點，其實就是在於它的邏輯核心。一個好的技能必須具備「做事策略」。如果只是列出要素而沒有控制邏輯，那叫「參考資料」，不叫技能。技能必須包含「要做什麼」與「不要做什麼」的判斷。
接著就來製作 Skill Creator。一樣是集各家所長(Perplexity, Claude, Gemini, OpenClaw 各家都有自己的 Skill Creator)。這種橫向比對適合用 NotebookLM 來做。NotebookLM 只能看到當前的檔案資料，不能像 Gemini 一樣做整個資料夾和樹狀結構探索。
提示詞輸入>_ 利用所勾選的來源, 取出其重點能力, 總結出一個 Skill 編寫器。
整合好之後，再把我們剛剛得到的邏輯流程放進去。
做完會得到一個 "整合 Agent Skill 編寫器" integrate-skill-creator.md
實戰案例 1：創業家技能包 (Preneur-Skill-Pack)
我的第一個目標。- The Minimalist Entrepreneur - 這是一個極簡創業家技能包。
你可以選擇用命令列下載，也可以選擇用下載ZIP檔。但對於我這種想要挑挑揀揀的人來說，還是ZIP檔比較方便。這樣的做法可以絲毫不變地把技能包用到你想要放在的平臺上面(Perplexity Computer, Claude Code 或 Google Antigravity。)
我以 slavingia 的極簡創業家技能包為目標，用 Gemini 進行全目錄掃描。
原包約 40kB，雖然 Gemini 有百萬 Token 的 Context(折合字元數大概在80萬到130萬)，但實務上掛載超過 15 個知識庫(最多 20 個)或對話累積到 30 萬字元時，就會感到卡頓。所以我現在會控制只使用一半左右的掛載量，只掛載最必要的知識庫，以避免使用效率的低下。巨大的知識庫是隨任務要求再機動掛上去，例如，後面做出來的 coding-skill-pack，容量大到 160kB。
用新做成的 Skill Creator 來提取想要的技能。
提示詞輸入>_ 將來源skill改寫成符合一人公司使用的Skill，包裝成技能組 Preneur-Skill-Pack.md
最後其改寫、精簡，封裝成一個僅 13kB 的整合包，非常適合與我的「一人公司主架構 (AI_Company_Package_v1.1.md)」綁定使用。
主 Agent 調度指令更新：追加...
**檢索優先**：每當 CEO 提及任務，請立即檢索「AI_Company_Package*.md」、「*Skill*.md」。**技能調用**：當你決定調用特定技能時，以 [Use:Skill_Name] 格式呼叫。
(版本 1.0 -> 1.1)
實戰案例 2：財務一人公司技能包 (Financial-Solopreneur-Pack)
對一人公司而言，財務能力也是相當重要的，於是我針對下面這個技能庫
Claude for Financial Services Plugins
提示詞輸入>_ 掃描 GitHub 程式庫裡面的 Skill 程式碼。 將符合一人公司使用的 Financial Skills。 整理成附檔的 Skill.md 的技能包檔案。(以剛剛完成的Preneur-Skill-Pack.md為範例)
此動作從 Anthropic 的金融插件中挑選出 6 個適合一人公司的技能（從 56 項中篩選）：
技能來源路徑：
1. 挖掘案源 (Deal Sourcing)
○ 來源資料夾：private-equity/skills/deal-sourcing/
2. 投資論述追蹤 (Thesis Tracker)
○ 來源資料夾：equity-research/skills/thesis-tracker/
3. 三表財務模型 (3-Statement Model)
○ 來源資料夾：financial-analysis/skills/3-statement-model/
○ 參考資源：references/formulas.md (用於實作 Python 計算邏輯)
4. 現金流折現模型 (DCF Model)
○ 來源資料夾：financial-analysis/skills/dcf-model/
○ 參考腳本：scripts/validate_dcf.py (AI將其邏輯重構為 Pydantic v2 版本)
5. 同行可比分析 (Comps Analysis)
○ 來源資料夾：financial-analysis/skills/comps-analysis/
6. 財務計畫規劃 (Financial Plan)
○ 來源資料夾：wealth-management/skills/financial-plan/
AI架構師註記：在整理過程中，我將上述來自「私募股權 (Private Equity)」、「金融分析 (Financial Analysis)」與「財富管理 (Wealth Management)」的專業投行級指令進行了「極簡化封裝」，目的是移除大型機構才需要的冗餘審核流程（如 IC Memo 審批），使其更符合一人公司創辦人（Solopreneur）快速決策的需求。
注意：直接複製不見得合用，部分修改仍是必要的。
由於語意層有重大的改變，所以 Scripts 的執行層也必須要一個個反覆做修改。
在這樣的修改進行中。最好把 Skill 的工作資料架構好。用上面的方式(上傳資料夾)匯入給 Gemini 看。這樣他才能看到整個檔案結構的全貌。做出正確的回饋。
需要這麼多 Scripts 輔助的原因在於，財務評估極度依賴數據，這時候完全依靠大模型的語意邏輯去決策，極易產生幻覺，這無疑是非常危險的事情。
最終檔案結構：
financial-solopreneur-pack/
├── SKILL.md # 核心定義 (語意層)
├── README.md # 創辦人手冊 (說明層)
├── scripts/ # Pydantic v2 驗證器 (執行層)
│ ├── deal_validator.py
│ ├── thesis_monitor.py
│ ├── valuation_calculator.py
│ ├── statement_engine.py
│ ├── accounting_engine.py
└── references/ # 資源層：靜態參考資料 (非執行邏輯)
└── formulas.md # 用於審計與公式說明
跨平台測試結果
在 Perplexity Computer 裏面的"技能"右邊有新增技能的按鈕，按了之後就可以拖曳檔案上傳，或者是以目錄選擇上傳 SKILL.md 或打包好的 ZIP 檔(financial-solopreneur-pack.zip)。用 `load_skill (Skill_name)` 即可呼叫技能出來使用。
也可以直接在 GitHub 程式庫挑到合意的技能，直接下載成ZIP檔，然後上傳到 Perplexity Computer 上面直接使用。
測試結果 Perplexity Computer，Gemini GEMs 都可以執行 Scripts。而在Perplexity Space 只能執行其語意的部分。
Gemini 的結果是讓我比較意外的，雖然看不到 Scripts 的實際執行過程，但是要求他輸出評分結果的話，從這個結果去交互驗證 Perplexity Computer 的評估結果，是可以確定在 Gemini 的 Sandbox 裏面確實有執行 Scripts 的評估。
實戰案例 3：編碼工程技能包 (Coding-Solopreneur-Pack)
針對程式開發，我從 obra 與 alirezarezvani 的庫中挑選出架構設計、TDD、Debug 等 10 項技能。這是一個重型包，腳本繁多，由於過程太冗長就不秀出中間的經過了。
提示詞輸入>_ 掃描這些 GitHub 程式庫裡面的 Skill。 選出裡面適合 AI_Company_Package_v1.1.md 的 Coding技能，打包成 Preneur_Skill_Pack.md 一樣的技能包。
技能包概覽：
目錄結構：
.agent/skills/coding-solopreneur-pack/
├── SKILL.md # 擴充後的語意指令
├── scripts/
│ ├── architect_engine.py # Pydantic v2 驗證與決策邏輯
│ ├── spec_validator.py # Pydantic v2 驗證規格書的結構
│ ├── decomposition_engine.py # Pydantic v2 驗證任務依賴與並行邏輯
│ ├── tdd_orchestrator.py # Pydantic v2 驗證、自動執行測試、計算覆蓋率
│ ├── review_validator.py # Pydantic v2 驗證報告格式與評分邏輯
│ ├── debug_analyzer.py # Pydantic v2 驗證錯誤元數據與環境快照
│ ├── schema_engine.py # Pydantic v2 驗證表結構、生成 DDL、檢查命名規範
│ ├── mcp_validator.py # Pydantic v2 驗證 Tool Schema 與資安攔截
│ ├── pipeline_generator.py # Pydantic v2 驗證、自動生成 YAML、檢查依賴
│ └── performance_engine.py # Pydantic v2 驗證、計算效能差異與邊際成本
└── resources/
├── tech_stack_matrix.xml # 各種技術棧的權重參考
├── adr_template.md # ADR 標準模板
├── prd_standard_v1.xml # 規格書必須包含的 XML 段落定義
├── ac_helper.md # 如何撰寫高品質 Acceptance Criteria 的指南
├── subagent_personas.xml # 各種專門子代理的人格定義模板
├── complexity_rubric.md # 任務複雜度評估準則 (Context Window 管理)
├── test_templates.xml # 不同框架的測試代碼模板
├── refactor_rules.md # 重構階段的代碼美學標準
├── anti_patterns.xml # 常見代碼壞味道 (Code Smells) 參考庫
├── security_rules.md # 安全漏洞掃描檢查清單 (Injection, XSS, etc.)
├── common_error_patterns.xml # 已知錯誤模式與對策清單
├── rca_framework.md # 根因分析思考框架 (5 Whys)
├── naming_conventions.xml # 數據庫對象命名規範 (snake_case, pluralization)
├── indexing_strategies.md # 不同場景下的索引優化指南
├── mcp_protocol_v1.md # MCP JSON-RPC 通訊協議規範摘要
├── server_templates.xml # Python/Node.js MCP 官方 SDK 模板
├── pipeline_templates.xml # 包含 GitHub Actions, GitLab CI, Vercel 等模板
├── security_hardening.md # 流水線安全加固指南 (Secret Management)
├── bottleneck_patterns.xml # 常見性能瓶頸模式 (N+1, Memory Leak, etc.)
└── optimization_guide.md # 針對不同語言/框架的優化清單
這些技能包裡，其實還有寶藏可以挖，例如專案管理、品質管理的技能。 就留待給各位發掘了。
⚠️ 安全警示：防範惡意技能包
最後提醒：網路上的技能包並非完全安全，有些可能含有「提示詞注入」或引導暴露 API Key 或引導外部網頁下載等惡意行為。「無腦取用」是有風險的。 建議在你的 Skill Creator 裡埋入安全檢查機制，提醒使用者重新審查，確保在產出或使用前先過濾掉潛在的危險動作。
<本文部分內容由 AI 協助生成，經人工編輯/發佈>
SKILL.md 模板
---
name: [skill-id-gerund]
description: [具體的觸發描述，建議 200 字以內，包含核心動作與數據對象]
license: MIT
compatibility: "python>=3.10, pydantic>=2.12"
metadata:
version: "v1.0"
status: "active"
ai_generated: true
platform_support: ["antigravity", "claude-code"]
---
# [Skill Title]
<instructions>
[這裡放入 XML 結構化的語意邏輯]
</instructions>
<constraints>
[這裡放入條列的技術約制]
</constraints>
<example>
[這裡放入適當的範例]
</example>
決策樹範例
Is the issue safety-critical or involves system reliability?
├── Yes → Use FAULT TREE ANALYSIS
└── No → Is human error the suspected primary cause?
├── Yes → Use HUMAN FACTORS ANALYSIS
└── No → How many potential contributing factors?
├── 1-2 factors (linear causation) → Use 5 WHY ANALYSIS
├── 3-6 factors (complex, systemic) → Use FISHBONE DIAGRAM
└── Unknown/proactive assessment → Use FMEA
