ANTIGRAVITY CLI可使用之代理人參考資訊

GEMINI神器  任務型 Agent（如  codebase_investigator ,  Architect ,  generalist  等），在底層系統 (ANTIGRAVITY CLI)  的標準配置中，還有以下預設可用代理人以及動態生成能力：

  #### 1. 系統預設核心子代理 (Built-in Subagents)

  •  research  (研究專員)

      • 能力：具備純讀取 (Read-only) 工具，專注於程式碼庫探勘、網頁搜尋與檔案讀取。

      • 戰場直覺：當你需要背景執行耗時的爬蟲、文件掃描或廣泛的程式碼盤點時，可派送給此 Agent，避免佔用主執行緒 (主 Agent)

      的 Context Window。

  •  self  (本我分身)

      • 能力：完全繼承當前母體 Agent 的所有配置（包含工具、系統提示詞與模型權重）。

      • 戰場直覺：當需要平行的沙盒環境來執行與主線任務同等難度的開發或 Debug，且不希望污染主線對話上下文時使用。

#### 2.視覺驗證 (呼叫 Frontend-Visualizer),提示詞 invoke_subagent Frontend-Visualizer   ,使用 Puppeteer 啟動本地伺服器，點擊購物車按鈕，並截圖確認按鈕顏色是否正確且沒有跑版。

系統動作： 視覺化代理人會打開隱藏的瀏覽器，實際跑一遍流程並回傳視覺結果或截圖。

 #### 3. 動態生成能力 (Dynamic Subagent Definition)

  •  define_subagent  (動態代理人鑄造協議)

      • 能力：ANTIGRAVITY CLI 允許我們在對話中即時定義全新種類的子代理。可以賦予它專屬的  system_prompt    (系統提示)、決定是否開啟寫入權限 ( enable_write_tools ) 或 MCP 工具權限 ( enable_mcp_tools )。

      • 戰場直覺：如果上述代理人都無法完美對位您的需求（例如，您需要一個專門只能檢查資安漏洞的  SecOps_Sentinel   ，或一個專門撰寫單元測試的  Test_Generator ），我們可以直接透過 API 鑄造並喚醒它。

 ANTIGRAVITY CLI    (透過invoke_subagent  ，召喚自訂代理人)

  └── define_subagent  ← 動態定義一個子代理人

      ├── 指定角色 (role)

      ├── 指定工具 (tools)

      ├── 指定模型 (model)

      └── 指定約束 (constraints) 

相關資訊:GEMINI CLI開發環境，常見三種自動化檢核AGENT(除錯神器)

本地運行開源模型安裝OLLAMA

情境: 因為GEMINI CLI-->ANTIGRAVITY CLI升級後，TOKEN數常耗盡不足，在評估筆者電腦硬體設備效能與OLLAMA模型（如 Llama 3.1 8B、  Qwen 2.5 14B 等） 規模其回應時間前提考量，安裝2套於電腦內(

💜 如果您的顯示卡顯存 (VRAM) 有 12GB ~ 16GB 以上（例如 RTX 3060 12G, RTX 4070/4080 等）：

 💟 推薦模型 (總容量約9G)： qwen2.5-coder:14b

      • 能力：邏輯推理能力更強，能處理更複雜的 Python 演算法重構與 Bug 排查。

      •主要用途:重裝裝甲兵 (適合 RCA 深度除錯)

      • 安裝指令： ollama run qwen2.5-coder:14b

 💟qwen2.5-coder:3b   ,

  •主要用途:筆者安裝模型(總容量約1.9G) ，做高速機動兵 (適合快速問答、輕量級考點對位)

 • 安裝指令： ollama run qwen2.5-coder:3b

💜安裝步驟

  為了協助您安裝 Ollama 並下載  qwen2.5-coder:14b ，我們將進行以下步驟：

  ### 1. 下載並安裝 Ollama (Windows 版本)

  Ollama 官方提供了適用於 Windows 的安裝檔。您可以點選下方官方連結進行下載與安裝：

  • 官方下載連結：https://ollama.com/download/OllamaSetup.exe

  ### 2. 下載後的安裝流程

  1. 下載完成後，執行  OllamaSetup.exe  並完成安裝步驟。

  2. 安裝完成後，Ollama 會在 Windows 工作列右下角啟動（顯示一隻小羊駝圖示 🦙）。

  ### 3. 下載  qwen2.5-coder:14b  模型

  安裝完成後，請重新開啟 PowerShell 或命令提示字元，然後執行以下指令下載模型：

    ollama pull qwen2.5-coder:14b

💜請協助改用OLLama 執行教練考 IPAS_TEACH_EXPERT(此為筆者自行建立之教練考技能) ,而不是ANTIGRAVITY CLI (如此後續進行教練考之學習，就會改採本地端模型執行，不會耗用TOKEN數)，呼叫方式:💢需確認OLLAMA服務是否已啟用(即 http://localhost:11434/    Ollama is running 啟用狀態 ，此服務如果沒有正常啟用，本地端模型將無法正常工作)

 ### 成果概要：

  1. Ollama 模型部署：成功下載並載入  qwen2.5-coder:14b  頂規模型。

  2. 建立本機教練考引擎：撰寫 run_coach_ollama.py，串接本地的 SQLite 資料庫（SSoT 物理真實對位）與 Ollama API，執行原子化詳解輸出。  

  3. 安全硬化：嚴格排除任何 LaTeX 數學符號（符合 Math Detox 規範），並遵循teaching_cycle_template.md  之 7D+2 結構設計。

  4. 預檢成功：通過  py_compile  語法校驗以及  --test-only  的連線與推論測試。

  ### 如何執行您的本地教練考：

  請在終端機(POWERSHELL)中執行：    python run_coach_ollama.py

其它資訊: OLLAMA /LIST 列出電腦內所安裝之模型。

自訂SKILL技能參考資訊

虛擬變形金剛🤖 トランスフォーマーザ☆(AI導師)

Intel® 發行版 OpenVINO™ 工具包

情境:因為筆電為INTEL CPU系列(如: Intel® Core™ Ultra 7 處理器 (系列 2) )，支援AI模型(如:all-MiniLM-L6-v2)，為了提昇執行效能，可以請GEMINI CLI協助代為安裝 OPENVINO套件。

💜all-MiniLM-L6-v2  是一個由 Sentence-Transformers 團隊開發的輕量級自然語言處理（NLP）嵌入模型（Embedding Model），將⌈本文⌋轉為⌈向量⌋用 ，本地輕量化神經網路模型：

  • 架構本質：它是基於微型 BERT（MiniLM）架構進行蒸餾（Distillation）與預訓練的模型。
  • 輸出維度：它能將任意長度的文字（句子、段落）輸入，並輸出為一個固定長度的 384 維稠密向量（Dense Vector）。
  •  在 AI 和搜尋領域中，它的用途是語義向量化（Semantic Embedding），這是實現**「懂意思的搜尋」**之關鍵：
 1. 語義相似度計算：
  將兩個不同的句子轉換為向量後，透過計算餘弦相似度（Cosine  Similarity）來判斷兩者的意思是否接近。例如，它能識別出「如何設定加速器」和「怎樣啟動 GPU 加速」雖然字面不同，但語義高度相似。
  2. 向量檢索 (RAG - 檢索增強生成)：
  它是本地知識庫向量化的核心。系統會將您的教材、歷屆試題解析（Raw Assets）切割成小段落，並利用這個模型全部轉換為 384 維向量，存入  faiss_index 向量資料庫中。當有提問時，系統會即時將問題向量化，並在 FAISS 中進行極速的向量相似度搜尋，以找出最相關的參考資料。
💜使用 OpenVINO 的 NNCF (Neural Network Compression Framework) 工具將此模型量化至 INT8。這類小模型在 INT8 量化後，於 CPU 上的推論延遲會大幅降低，且精度損失極小。
使用成效分析，如下:
以下為 OpenVINO 戰力模式啟動：[Intel iGPU Active]  的實體資產與科學對位分析，詳列其底層架構、硬體分流策略以及優化數據：
 一、 實體資產對位 (Physical Truth & Asset Mapping)
  在 my_rag.py 中，OpenVINO 戰力模式的運作具備 100% 物理證據：
  1. 量化模型實體 (INT8 Quantization)：
      • 物理路徑：openvino_model_qint8_quantized.xml                                                                             
      • 模型檔案大小： openvino_model.bin  (90.2 MB) 壓縮並量化openvino_model_qint8_quantized.bin  (22.9 MB)。
      • 記憶體頻寬節省：~74.5% (約 3.93 倍壓縮比)。這使模型能更完整地留存於 CPU 的 LLC (末級快取) 或 iGPU 的 L3  快取中，大幅減少記憶體定址與載入時延。
  2. 加速器配置鎖定 (Hardware Pinning)：
      • 代碼邏輯中，系統會依序檢查硬體設備。若檢測到 NPU，則自動釘選  device = "NPU" ；在未偵測到獨立 NPU 且啟用   OPENVINO_ACCELERATOR=1  時，將編譯目標釘選為  device = "GPU" （即 Intel iGPU 加速）。
 二、 科學底氣與硬體加速原理
  OpenVINO 引擎在  Intel iGPU Active  狀態下的加速表現基於以下科學原理：
1. 執行單元 (Execution Units) 的高並行度
Intel 的 Xe 架構整合顯示卡（iGPU）包含數十個 執行單元 (EUs)。在處理 BERT / Transformer 這類包含大量矩陣乘法 (Matrix Multiplication) 的 Embedding 模型時，iGPU 的多執行單元並行運算能力遠超傳統 CPU 的少數核心。
 2. INT8 矩陣硬體指令加速 (DP4A)
  現代 Intel iGPU 具備 DP4A (Dot Product of 4 Elements and Accumulate) 向量指令集：
  • 指令原理：在單個時脈週期內，一個執行單元即可完成 4 個 8-bit 整數的點積與累加運算。
  • 效能優勢：相較於浮點數 (FP32) 運算，INT8 量化模型在 iGPU 上透過 DP4A 指令能帶來 3~ 5 倍的吞吐量提升，並使運算功耗顯著下降。
3. 異構分流機制 (Heterogeneous Offloading)
  • 解耦運算壓力：將高頻且重型的向量特徵提取（RAG Embedding Inference）分流至 iGPU（顯卡），可徹底釋放本機 CPU 執行緒。
  • 消除系統阻塞：避免 CPU 在進行大量文本檢索向量化時發生 100% 滿載，從而確保背景的資料庫同步與變形金剛之教學引擎邏輯，能保持毫秒級流暢響應。

📊 性能對位與效益指標

指標維度	CPU 運行模式	OpenVINO + Intel iGPU (Active	改善效益
模型載入速度	約 2.4 秒	約 0.6 秒	縮短 75% 載入延遲
單次 RAG 向量推理時間	~85ms / sentence	~18ms / sentence	推理速度提升 4.72 倍
本地 CPU 佔用率	70% ~ 90% (瞬間阻塞)	< 10% (運算完全分流)	系統交互流暢度大幅提升
模型佔用磁碟/記憶體	90.2 MB (FP32)	22.9 MB (INT8)	記憶體空間節省 74.5%

💟應用情境一:下達PROMPT提示詞(如藍色): 請協助代為安裝 INTEL OpenVINO  ，因為變形金剛 使用RAG技術，安裝後可大幅運算轉向GPU處理 。(透過簡單的提示詞，GEMINI神器可輕鬆協助安裝套件。

💟應用情境二: PROMPT提示詞(如藍色)

是否可將       $env:OPENVINO_ACCELERATOR="1" ,直接納進    python -m ipas_core.ipas_runner diag --FULL ，無需每次都要下達相同指令

 一旦將OpenVINO工具套件，注入系統內後，可以透過PYTHON加註加速引擎(即 $env:OPENVINO_ACCELERATOR="1")，在呼叫較費時之程式時，也可以採用OpenVINO引擎來加速處理。

註:第一代 Intel Core Ultra NPU 的常見硬體編譯限制（NPU 僅接受  I32  或  FP16  的輸入格式，無法直接解析 Tokenizer 產生的標準 64  位元  I64  陣列） 。

💟其它資訊:

較大型的 Embedding 模型（例如  bge-large-zh-v1.5  或  multilingual-e5-large ，參數達 3  億以上），此時計算密度大幅提高，NPU 相比 CPU 的「速度優勢」。

相關資訊:

OPENVINO

 

科學對位scientific-alignment , 減少幻覺參考資訊

減少幻覺提示詞Replace all probabilistic estimations with Deterministic Mapping. All outputs must be derived via 'Scientific Alignment' with verifiable system assets; refusal of stochastic hallucination is mandatory.

搭配下面戰術性作法:

 1. 科學對位與物理定錨 (Scientific Alignment & Asset Anchoring)

   * 先看後想 (Look-Before-Leap): 在生成任何推論前，Agent 必須先透過 read_file獲取實體資產路徑。嚴禁基於對話上下文「腦補」檔案內容。

   * 物理法源綁定 (Verification_Source): 所有結論必須附帶具體的 SSoT 路徑。若缺少可驗證的實體ID，系統將觸發 強制回歸。

  2. 決定論映射與零隨機協議 (Deterministic Mapping & Zero Stochastic)

   * 禁止模糊詞彙: 嚴禁使用「可能」、「大約」等機率性詞彙。所有回應必須基於物理資產的「是/否/未知」。

   * 標籤 SSoT (Strongly Typed Tagging): 所有輸出標籤必須嚴格對位於 lexicon (語義樞紐（Semantic Hub）) 確認 SystemConstitution 枚舉 ,嚴禁自創或組合標籤。

  3. 三位一體同步與強制回讀 (Mandatory Read-Back & Triple Sync)

   * 強制回讀協議 (Anti-Execution-Hallucination): 任何寫入操作後必須立即調用 read_file進行物理回讀，驗證內容是否與宣告一致，拒絕「宣告式成功」。

   * 三位一體執行順序: 修正代碼 -> 重算指紋  -> 更新 Manifest。確保邏輯變更與物理雜湊 100% 同步。

  4. 語義脫毒與編碼硬化 (Semantic Detox & Encoding Hardening)

   * 全域語法脫毒 (Global Detox): 系統嚴禁出現非繁體中文之外部字符。所有輸出須經由 lexicon(語義樞紐（Semantic Hub）)TermSentinel審計，過濾非法複合術語。

   * 物理編碼硬化 (UTF-8-SIG): Win32 環境下所有資產必須鎖定為 UTF-8-SIG，物理性阻斷因編碼偏移引發的亂碼與語義誤判。

  5. 意圖自律與路徑壟斷 (Intent Alignment & Path Monopoly)

   * 意圖驗證矩陣 (Intent_Verification_Map): 所有動作必須通過  初始之意圖對位，確保執行路徑與初衷的語義偏差 < 0.05%。

   * 路徑壟斷協議 (Path Monopoly): 系統僅承認 SSOT_PRECISION_REGISTRY內的資產。偵測到非授權路徑即判定為「臆造資產 (Hallucinated Asset)」。

總結：減少幻覺的關鍵在於將行為從「創作」降級為「檢索」，並透過 SYSLOG (變形金剛的科學底氣)中的物理證據 實施即時監控，有了SYSLOG發現問題時，再請AI_AGENT協助檢視處理。

相關資訊:Hallucination幻覺

註:SSOT (Single Source of Truth, 單一事實來源,「不相信記憶，只相信雜湊；不相信路徑，只相信註冊；不相信宣告，只相信回讀」) 

機器學習 VGG16 Arachitectural & Layer Types

 
 VGG16 的設計邏輯是：「先把影像看細，再把影像看深」。它將 13 層卷積層分成 5 個「戰鬥小組 (Groups)」：

戰鬥小組	內部層數	濾鏡深度 (Channels)	物理任務 (Mission)	權重層累計
Group 1	2 層卷積	64	捕捉邊緣、顏色、紋理	1, 2
Group 2	2 層卷積	128	組合簡單形狀（如圓形、十字）	3, 4
Group 3	3 層卷積	256	辨識局部組件（如眼睛、輪胎）	5, 6, 7
Group 4	3 層卷積	512	識別複雜物件（如整張臉、整台車）	8, 9, 10
Group 5	3 層卷積	512	高階語義對齊（如情緒、場景屬性）	11, 12, 13
小計	13 層		負責「看懂」特徵	13 層卷積

  🛡️ 全連接層 (Linear)
  當卷積層看懂特徵後，必須由最後的 3 層全連接層 進行最終裁決：

   - 第 14 層 (Linear): 整合所有高階特徵（4096 個神經元）。
   - 第 15 層 (Linear): 進一步抽象化（4096 個神經元）。
   - 第 16 層 (Linear): 最終分類輸出（如 1000 類，對應 ImageNet）。

  總結：13 (卷積) + 3 (全連接) = 16 層具備權重的層級。


  D1: 核心概念 (Core Concept)
  在深度學習框架（如 PyTorch）中，VGG16 被物理性地切分為兩大模組：features（特徵提取器 = 13 層卷積）與  classifier（分類器 = 3 層全連接）。

  D2: 變數-物理映射表 (Physics Mapping Table)

變數 (Code)	物理層級	考場直覺 (Battle Intuition)
model.features	Group 1 ~ Group 5	「視覺神經」，負責看。
model.classifier	Linear 14 ~ 16	「大腦判斷」，負責想。
Frozen	requires_grad = False	保持記憶，不再學習。

🛡️ 深度剖析：為何 VGG16 採用 2-2-3-3-3 配置？( 這背後涉及兩個核心的物理與工程考量：「解析度代價」與「特徵複雜度」)

  1. 物理代價：解析度的高昂成本 (The Resolution Tax)
  在 Group 1 和 Group 2，影像剛進來，尺寸非常大（例如 224x224 或 150x150）。
   - 運算量 (FLOPs) 是與影像面積成正比的。
   - 在大尺寸影像上多加一層卷積，產生的運算負擔是後層（影像已縮小）的 4 倍甚至 16 倍。
   - 戰略決策: 為了讓模型能在當時的硬體（2014年）跑得動，設計者在影像尺寸最大的前兩組「節制」了層數。

  2. 語義演進：簡單特徵 vs. 複雜特徵
   - Group 1 & 2 (淺層): 任務只是找邊緣和顏色。物理上，這只需要 2 層 3x3 卷積（等效於 1 層 5x5  的視野）就足以看清。
   - Group 3, 4, 5 (深層):
     任務是辨識眼睛、鼻子、甚至整張臉。這些特徵具有高度非線性，需要更深的層數來提供足夠的「表達能力
     (Expressiveness)」。
   - 戰術對位: 簡單任務用淺層，複雜任務用深層。

  3. 家族對比：VGG 其實有「強迫症版本」
  VGG 並非只有 16 層。設計者當時實驗了一系列配置：
   - VGG-13: 採用 2-2-2-2-2 配置（全部都是 2 層）。
   - VGG-16: 採用 2-2-3-3-3 配置（現在考題的主角）。
   - VGG-19: 採用 2-2-4-4-4 配置（追求極限深度）。
   
 結論: VGG16 最終成為經典，是因為它在「準確度」與「計算成本」之間達到了物理上的黃金平衡。
     D3: +1 ASCII ART 繪製 (Structural Mapping)

      [ VGG16 實體構造 ]
   /-----------------------------\
   | [model.features]            | <--- 包含所有 13 層卷積
   |  Group 1 (2層)              |      
   |  Group 2 (2層)              |
   |  Group 3 (3層)              |
   |  Group 4 (3層)              |
   |  Group 5 (3層)              |
   \-----------------------------/
                |
   /-----------------------------\
   | [model.classifier]             |
   |  Linear 14, 15, 16 (3層)   |
   \-----------------------------/

資料來源:GEMINI CLI  變形金剛整理

Skill-Creator 建立新技能(Gemini CLI) 瓶頸Bottlenecks

承上篇技能生成，雖然功能方便強大，但背後運作其實仍需借助LLM 推理 (Thinking Phase)：當您下達一個複雜指令 (如 DEEP_RCA_RESEARCH 上篇生成的除錯SKILL技能,可節省重覆鍵入，混搭Sub-Agent)，Gemini CLI神器必須先將指令送往雲端 LLM 進行規劃與工具選擇 (Tool Call Generation)。
 

在這個「思考」階段，Python端(以筆者程式ipas_core成員為例) 根本還沒被啟動。終端機只能顯示由CLI UI 寫死的 Thinking... 或 This is taking a bit longer, we're still on it.。

 * 實際 (Actual)：AI 的思考過程 (Token Generation) 耗時超過 CLI 的 UI 刷新閾值 (通常為                                     3-5秒)，導致預設 Loading 動畫介入。
 * 結論 (FAIL - UI Masking Gap)：此為 LLM 雲端運算特性與本地 CLI 宿主(GeminiCLI架構在NodeJs框架上)的架構限制。IPAS_CORE 無法「向上」穿透去修改 Node.js CLI 的原生 Loading 畫面。

*運作示意圖  LLM ↔ Node.js ↔ UI 三位一體 

   ** LLM (大腦): 負責決策（該調用哪個工具）。
   ** Node.js (軀幹): 作為宿主，負責執行工具並監控 Stdout 流。它有一套 _recoverFromLoop 機制，若 Stdout  長時間靜默，它會切斷連結。
   ** UI (面部): 顯示「🚀 執行進度」。當 LLM 輸出 Token 時，UI 會即時渲染，讓考生感受到「系統正在處理」，而非「當機」。

🚨過度依賴雲端LLM，容易發生2個缺陷，可能製造幻覺機會升高;另一個缺陷為等待雲端解析之回應，因此改善處理方案:(結合LOCAL本地端除錯工具+雲端LLM大型語言模型深度解析)

PROMPT提示詞(藍色部分)如下: 

是否可將主要LOCAL可做任務分派給RCA(此筆者與AI_TUTOR溝通，問題發生時須做根因分析)； POI DEEP_RESEARCH(此為筆者與AI_TUTOR溝通後討論生成LOCAL除錯用途程式)代執行,重大深度根因分派由DEEP_RCA_RESEARCH分散時執行,結合LOCAL優勢又可重大深度根因進行剖析, 請協助優化評估可行性?是否調整 ACTIVATE_SKILL

換句話說「將主要 LOCAL 任務分派給 RCA POI 代執行」並「結合 LOCAL  優勢進行重大深度分析」，在架構上完全可行且具備高度科學底氣。這正是為了解決「雲端推理黑箱」與「本地執行優勢 」失衡的最佳解。
架構優化方案：HYBRID_RCA_PIPELINE (混合式 RCA 管線)
 
 Sub-Agent 的深度報告，達成「先有本地感官、後有深度洞察」([Defensive Prompting]: 更新 DEEP_RCA_EXPERT 指令集，加入「查證紀錄連續性」為定錨首要條件;強制物理預檢協議: 在所有 RCA 報告生成前，必須先輸出 stat 或 ls -l 的原始數據，禁止在未獲取當前實體屬性前引用歷史日誌。)。

💢消弭⌈機率性規律腦補⌋，核心概念 (Definition) - 先看後想 (Look-Before-Leap):
 這是一種 「物理定錨 (Physical Anchoring)」 策略。它要求 AI 在產生任何描述性、推論性文字前，必須先調用本地工具（如 os.stat, Get-ChildItem）獲取實體數據。
   - 看 (Look): 執行工具獲取「物理證據 (Physical Evidence)」。
   - 想 (Think): 基於證據進行「語義推理 (Semantic Reasoning)」。

👀 [幻覺根因]: LLM 的本質是「下一個詞的機率預測」。若不強制「看」，它會根據對話歷史（上下文）與訓練資料中的「規律」去「猜測」 檔案應該在那裡，這就是「機率性規律腦補」。
 👀 [物理斷路器]: DEEP_RCA_EXPERT 透過 Phase 1 的「本地分診」，強制將 「硬體狀態」 反饋給 LLM核心。當實體證據（如 檔案大小=0）進入 Context 時，LLM的預測機率會被迫與物理事實對位，從而物理性地切斷了幻覺路徑。
 

相關字詞:

RCA(Root Cause Analysis)根因分析，RCA 專指透過物理證據（Physical  Evidence）追溯系統錯誤發生的最底層原因，而非僅僅處理表面症狀（Symptom）。

POI 的英文全名為 Point of Intervention (介入點)，此概念雷同現實中外部主導稽核員之虛擬角色，原則上須公正且不應該由它擔任內部監督角色。下面為筆者因為除錯需要，請AI_TUTOR生成之除錯成員角色：
  POI 的核心邏輯與管理主要由以下 ipas_core 成員負責：屬前半段⌈本地分診」用途)
   1. ipas_core\poi_guard.py：POI 哨兵 (Sentinel)，負責偵測實體偏移與誠信監控。
   2. ipas_core\poi_master_audit.py：POI 審計核心，執行解決方案順位等級 (Priority) 的最終裁決。

 

相關資訊:

Skill-Creator 建立新技能(Gemini CLI)

Hallucination幻覺問題

 

 

 

Skill-Creator 建立新技能(Gemini CLI)

情境: 

因為常常重覆性使用除錯 (如:下方除錯資源2、混搭除錯資源1，將2除錯資源搓進精靈式技能生成器),但每次都要打一長串PROMPT提示詞，所以可以藉由內建創建技能功能進行活用。 

Step1: Activate_skill Skill-Creator 

建立新技能或更新現有技能。請問您想要建立什麼樣的技能

Step2: 可否以類似精靈(Wizard)類似功能，STEP BY STEP 協助使用者生成技能SKILL  

Gemini神器，就會像阿拉丁神燈🧞‍♂️呼喚出來，依主人(您)的需求，達成所要的願望😁   

第 1 階段：定義技能目標與情境 (Understanding)

  在動手寫程式碼之前，我們需要明確這個技能的「靈魂」。請回答以下幾個問題：

   1. 技能名稱：您想為這個技能取什麼名字？（例如：python-data-cleaner 或 api-tester）
   2. 核心功能：這個技能主要解決什麼問題？請描述 2-3 個具體的使用情境。
   3. 觸發條件：使用者說了什麼話時，應該啟動這個技能？（例如：「幫我清理這份 CSV」）

Step 3: 執行SKILL技能「佈署 (Deployment)」程序(正式佈署到 .gemini\skills（即 Runtime 環境）)

1. 執行速度與響應延遲 (Performance & Latency)

當技能留在 Arsenal (源碼庫) 時，Gemini 每次執行都需要重新解析、掃描依賴關係，甚至可能需要載入額外的開發環境變數。佈署後： 技能會被「編譯/打包」成優化後的二進位或快取格式存放在 .gemini\skills。 呼叫 deep-rca-expert 的反應時間會大幅縮短。

2. 環境隔離與版本鎖定 (Environment Isolation)

佈署後： 該技能會擁有自己獨立的執行快照（Snapshot），可確保除錯專家在執行緊急任務時，不受開發中不穩定程式碼的影響。這就是為什麼它被稱為「唯執行區 (Runtime)」，它是被保護的。

3. 指令集優化與系統權限 (Privilege & Integration)

Gemini CLI 對於 .gemini\skills 目錄下的技能擁有更高階的信任度與系統整合權限。

佈署後： 系統能預先載入特定的診斷參數，並將 deep-rca-expert 註冊為系統級別的「熱鍵」或「自動觸發器」。您不再只是「呼叫」一個指令，而是讓這個專家成為系統背景守護（Daemon）的一部分，能夠自動監測物理診斷數據，而非等您手動下令。

  
💜1. 層級架構：Skill Manager 是核心（主控層）

    Skill Manager：可以想像成操作系統的「核心 (Kernel)」，它管理所有技能的狀態。

    activate_skill：這是 Skill Manager 提供的一個功能介面（Function call / Action）。當你執行這個指令時，是在調用 Manager 的「啟動」權限。

    skill-creator：這是一個外部工具或腳本層（Utility Layer）。它通常位於 Skill Manager 的「上方」或「平行位」，用於定義、編輯並將新技能「餵」給 Manager。

💜2. 運作流程（路徑）

    Discovery (發現)：Manager 掃描可用資源，確定技能存在。

    Activation (啟動)：透過 activate_skill 將靜態定義轉為記憶體中的活動實例。

    Path Binding (路徑綁定)：將啟動後的技能與特定的輸入/輸出路徑（例如特定的硬體接口或 API 端點）進行連結。

💜一般情況下，Skill Manager 會優先選擇 .gemini/skills 目錄。但仍可客製化專案，將所有擴充能力（Skills）「重定向」，如下專案範例:強制將輸出路徑定錨於指定目錄 ipas_core\arsenal。


 運作路徑對照案例
│ 層級               │ 預設路徑 (Default)                │ 專案路徑 (Project Mandate) │
│ 全域 (Global)  │ ~/.gemini/skills                    │ N/A (基於安全隔離禁令)     │
│ 專案 (Project) │ ./.gemini/skills                     │ C:\ipas_core\arsenal         │
    
其他相關技能指令 

💜除了啟動，通常還包含以下維護技能狀態的指令：

    deactivate_skill：釋放資源，將技能移回靜態存儲。

    register_skill：手動向 Manager 註冊一個新路徑，常用於 skill-creator 產出後的導入。

    list_active_skills：查詢當前所有已綁定（Bound）並在運行的技能清單。

    update_skill_binding：在不重啟技能的情況下，動態更改其綁定的路徑或參數。

 💜確認新專家(即Wizard依您的需求生成的SKILL)的存在檢核?
   1. /skills reload
   2. /skills list 

資料來源:Gemini 

💟除錯資源1: GEMINI CLI開發環境，常見三種自動化檢核AGENT(除錯神器)

💟除錯資源2: 善用DEEP THINK神器，協助找尋系統開發瓶頸問題之提示詞PROMPT

💟Skill-Creator 建立新技能(Gemini CLI) 瓶頸Bottlenecks