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

情境: 

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

Step1: Activate_skill Skill-Creator 

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

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

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

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

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

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

 
💜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：在不重啟技能的情況下，動態更改其綁定的路徑或參數。

資料來源:Gemini 

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

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

Win32 環境操作中文 (Encoding Integrity )編碼，供AI_Agent操作參考資訊

情境:使用GEMINI CLI技術基底，進行中文處理操作，但AI_TUTOR不一定能完全掌握使用者端OS作業環境，而筆者是採用PowerShell做為啟用GEMINI CLI基底，但常有PYTHON程式在處理過程中，會將現有運作中之檔案編碼(預設為UTF-8)，因操作讀取關係直接將亂碼混入處理之檔案(如:*.MD、*.PY等)，所以下方資訊將有助於AI_TUTOR代理人，掌握運作中環境，將有助於改善亂碼亂入情形。

## 1. 使用者環境設定GEMINI.MD (位於 %USERPROFILE%\.gemini)，因為AI代理人會於載入系統時，讀取個人環境資訊，如果設定不同語言，它將會容易語義偏移發生可能。

## Gemini Added Memories - My preferred editor, Notepad++, is located at 'D:\Program Files\Notepad++\notepad++.exe' 

- ユーザーの好きなプログラミング言語はPythonです。

- User prefers Traditional Chinese (繁體中文) for all communications. Do not use Japanese.

2. 編碼衝突架構分析 (Technical Taxonomy)

技術行為	技術根因 (Why)	潛在風險 / 後果
UTF-8-SIG 技術分量	帶有簽章 (BOM) 的 UTF-8。在位元組 0 處包含 0xEF 0xBB 0xBF。	若使用標準 utf-8 讀取，將導致首行解析出不可見字元，破壞 JSON 或 CSV 結構。
PowerShell 5.1 隱形 BOM 陷阱	使用 -Encoding UTF8 時，輸出的實質上是 UTF-8-SIG。	引發下游系統解析崩潰，破壞數據交換協議的嚴謹性。
PowerShell >> 重新導向禁忌	預設為 UTF-16LE 或 CP950，且強制附加 BOM。	破壞 Python 線性讀取，導致 UnicodeDecodeError 或混合編碼汙染。
Python open() 缺省參數	Win32 下預設回傳 CP950，與雲端環境 UTF-8 衝突。	造成環境行為不對稱，處理跨平台數據流時發生不可預期崩潰。
BOM 隱形干擾	Windows 編輯器自動添加 BOM 導致位元組 0 處偏移。	解析器報錯，破壞檔案雜湊 (Hash) 誠信校驗與數位簽章。
忽略 chcp 65001	活動字碼頁對 Subprocess 管道具有強制約束力。	Subprocess 輸出被強制轉換為 CP950，引發解析亂碼 (Mojibake)。

物理字元降級 ( 0x3f Replacement)

在 CP950 環境下對 UTF-8 檔案執行「精準替換 (Replace)」操作。

不可逆損毀。非 ANSI 字符（如繁體中文）會被物理替換為 ASCII `?` (0x3f)，導致原始語義永久遺失，無法透過解碼恢復。

 

### 2.1 UTF-8-SIG 實務應用與橋接邏輯 在 Win32 複雜環境中，編碼處理遵循**架構規範**中的橋接邏輯：

 * **實務場景 (Win32 PowerShell)**： 

* 當使用 `Out-File` 或 `Export-Csv` 產出數據供 Excel 直接開啟時，`UTF-8-SIG` 是必要的，否則 Excel 會將其視為 Big5 (CP950) 導致亂碼。

 * 在 PowerShell 5.1 中，為了強制系統識別為萬國碼而非系統預設區域編碼，常需依賴其內建的 `UTF-8-SIG` 行為。

 * **橋接邏輯 (The Bridge Logic)**：

 * **輸入容錯 (Read)**：系統應使用 `encoding='utf-8-sig'` 讀取所有外部來源數據，以自動兼容並過濾潛在的 BOM。 

* **輸出誠信 (Write)**：系統產出的所有持久化檔案與 API 響應，必須強制使用 `encoding='utf-8'` (No BOM)，確保與現代架構（Linux/Docker/Cloud-native）的高度一致性。

 * **規範定義**：「讀取用 SIG，寫回用 No-BOM」。

 ## 3.治理參考 (Governance Framework)，處理符合以下防禦性要求：

 * 建議預先強制編碼聲明**：凡涉及檔案 I/O，必須顯式定義 `encoding='utf-8'`，嚴禁依賴運行時環境之 `locale` 缺省值。

 * 原子化脫毒機制**：系統偵測到 BOM (0xEF 0xBB 0xBF)時，應立即啟動「物理回滾」程序，將檔案重新標準化為 `UTF-8 (No BOM)` 格式。

 * 管道免疫規範**：執行跨進程調用 (Subprocess) 前，必須確保環境變數或活動字碼頁已鎖定為 65001。

 ## 4. Win32 環境標準應對 Check-list

 -** I/O 審查**：確認代碼中所有 `open()` 調用均包含 `encoding='utf-8'` 關鍵字參數。另讀取邏輯是否使用 `utf-8-sig` 以自動剝離 BOM。

 -** PowerShell 版本過濾**：確認腳本是否運行於 PowerShell Core (v7+) 或是 5.1；若是 5.1，需額外處理 `Out-File` 產出的 `UTF-8-SIG` 問題。

 -** Excel 兼容性校驗**：若輸出為 CSV 且預期使用者為一般 Windows 用戶，評估是否需暫時切換為 `UTF-8-SIG` 作為展示層適配。

 -** Shell 替代方案**：在 PowerShell 中嚴禁使用 `>>`。應改用 Python `write_file` 工具或顯式指定編碼的 `Out-File`。

 -** 流解析校驗**：讀取 JSON 或 JSONL 數據流前，確認緩衝區位元組 0 處不含 BOM 特徵碼。

 -** 環境鎖定**：在 Win32 啟動腳本 (Batch/PS1) 首行強制執行 `chcp 65001 >$null`。

 -** 適時對 執行中腳本程式或 協議** (如 *.md) 編碼掃描，確保其符合 `UTF-8 (No BOM)` 規範。 

 

文字化け(Mojibake)其它資訊:

encode文字編碼查詢

 

 

AI神器，查找 Wi-Fi 不明原因斷線 (0x80070483)

情境:電腦不明原因，無線網路經常性發生自動斷線問題，疑難檢查精靈查找後:ERROR CODE為0x80070483 

PROMPT提示詞(如藍色部分):請協助 查找事件檢視器eventvwr.msc 找尋，無線網路不明原因斷線!

使用工具:GEMINI CLI 神器，除錯大師  

問題核心鎖定在「驅動程式層級的電源切換」與「服務重啟邏輯」兩大維度，並透過「註冊表硬化」與「服務恢復策略」達成物理層級的穩定。

---

🛠️ Wi-Fi 斷線根因分析與診斷 (Root Cause Analysis)

根據AI_AGENT代理人，協助翻找系統事件檢視器紀錄，斷線並非隨機發生，進行RCA深入剖析背後不明斷線，具有高度相關性的連鎖反應，科學底氣：

• 現象紀錄 (Event Id: 12 & 521): 系統頻繁出現 Kernel-Power 事件。當 WUDFHost.exe 偵測到電池計數變更或電源配置切換時，會觸發驅動程式層級的「原則配置重設」，導致硬體短暫離線。

• 技術盲區 (PowerCfg Limitation): 一般的電源選項設定（如 UI 介面的省電設定）僅屬系統層級。當驅動程式發生 D3 (Sleep) 轉換 或自發性重設時，系統層級的設定無法有效攔截硬體行為。

• 實體證據 (Event Id: 4000): 06:08:15 出現 WLAN-AutoConfig 服務重啟，證實了網路中斷是由於「服務重啟」而非單純訊號不良。這通常與用戶登入/登出時的「系統工作階段轉移」(Id: 566) 相關。

---

⚖️ 解決方案：雙層硬化處置 (Hardening Actions)

為解決上述根因，已執行以下針對性修復：

1. 驅動程式物理硬化 (Registry Hardening)

• 對象: Realtek 8821AE (DeviceID: 1 / Index: 0001)  (筆者筆電所使用無線網卡)

• 指令: reg add "HKLM\SYSTEM\CurrentControlSet\Control\Class\{4d36e972-e325-11ce-bfc1-08002be10318}\0001" /v "PnPCapabilities" /t REG_DWORD /d 24 /f

• 理由: 將 PnPCapabilities 設定為 24 (十進位) 可從底層禁止 Windows 關閉該網卡以節省電源。此舉可繞過 Modern Standby 的限制，確保即使重啟後，網卡電源依然處於「永遠開啟」狀態。

2. 服務持續性防護 (Service Recovery)

• 對象: WLAN AutoConfig (wlansvc)

• 指令: sc failure wlansvc reset= 0 actions= restart/60000/restart/60000/restart/60000

• 理由: 針對事件 Id: 4000 顯示的服務崩潰問題，將失敗恢復動作設為「自動重新啟動」。若服務意外停止，系統將在 60 秒內自動拉回服務，無需手動介入。

---

🔍 服務檢查清單 (Services Verification)

檢視WI-FI服務 : (開始 | 執行 | services.msc) ，確保以下核心服務的狀態符合配置：

服務名稱	顯示名稱	建議啟動類型	建議狀態
WlanSvc	WLAN AutoConfig	自動 (Automatic)	執行中
RmSvc	Radio Management Service	自動 (Automatic)	執行中
Dot3Svc	Wired AutoConfig	手動 (Manual)	視環境而定

提示： RmSvc (無線電管理服務) 負責處理飛航模式及無線收發器的切換，若此服務未設為自動，可能導致網卡在休眠喚醒後無法正確初始化無線電訊號。

 

系統相關參考指令

列舉個人所遇到Hallucination幻覺問題(🤖變形金剛系統 歷史偏移記錄)

                                                                                                                                      

類型	幻覺樣態	說明	造成原因與模式 (Patterns)	解決建議 (Mitigation)
程序邏輯類	元認知幻覺 (METACOGNITIVE)	系統操作不存在的機制，或在流程未完成時提前跳轉相位。	提前跳轉、使用未授權機制、進入 Debug 模式、IPAS 數據異常。	執行 STRICT_L1_CHECK（通常指的是第一道防線的自動化校驗。它的核心邏輯是：只要有任何一項基礎規則不符，系統會立即「報錯並中斷」，不允許進入後續更複雜的邏輯處理）。
	慣性偏移 (PROCEDURAL_INERTIA)	輸出過度受前文格式制約，忽略了最新的約束條件。	模式鎖定 (Pattern Lock-in)、上下文重力漂移、重複循環相位。	啟動 ATTENTION_RESET_TRIGGER（注意力機制重置觸發）。  Hard Reset: 直接將所有權重矩陣歸零（像是開啟新的對話視窗）。 Soft Reset: 透過門控機制（Gating Mechanism）衰減舊權重，讓新資訊的權重（Weight）瞬間蓋過舊資訊。
語義結構類	語義偏移 (SEMANTIC_DRIFT)	術語誤用、考點對標錯誤或出現 L-Code 大綱對應JSON檔之亂碼。	L-Code (JSON格式)匹配失敗、概念污染、術語毒性、緩衝區重疊、QID 格式漂移。	進行 SEMANTIC_FINGERPRINT_REMATCH（語義指紋重新比對）。  特徵提取： 將文字轉成一串數字（Vector）。 指紋生成： 壓縮成一組唯一的 Hash 值或特徵向量。 重新比對： 計算新舊指紋之間的「距離」（如餘弦相似度 Cosine Similarity）
	結構性幻覺 (STRUCTURAL_INDEX_SHIFT)	條文編號、層級嵌套或索引標籤發生遞增/遞減錯誤。	差一錯誤 (Off-by-one)、嵌套崩潰、保留了過時的舊編號。	執行 CROSS_REFERENCE_VAL_STRICT（嚴格交叉引用校驗）。
	缺失值補全幻覺 (VACUUM_FABRICATION)	檢索不到實體資產時，依據機率強行生成虛假替代品。	概論性填充、預位符幻覺、偽陽性檢索。	設置 NULL_THRESHOLD_FORCED_STOP（空值門檻強制停止）。
環境交互類	執行幻覺 (EXECUTION_HALLUCINATION)	系統宣告已完成物理執行，但實際實體資產並未變動。	說做不一 (Say-Do Mismatch)、幽靈同步失敗、產生幽靈腳本。	強制執行 MANDATORY_READ_BACK（強制讀回驗證）。  發送訊息 (Call out): 發送者清晰傳達指令（包含數據、時間或動作）。 強制讀回 (Read back): 接收者原樣重複關鍵資訊，不能只說「收到」或「OK」。  確認閉環 (Confirm/Check): 發送者確認讀回內容正確，說出「正確」或「收到」
	外部程式依賴幻覺	系統誤判宿主環境具備特定 CLI 工具（如 sqlite3.exe）。	環境慣性、字元脫逸避險心理。	執行 WIN32_NATIVE_MANDATE (強制 Python 原生驅動)。
	上下文腦補式資產幻覺	系統假設不存在的檔案路徑或模組已存在並調用。	基於對話上下文的腦補、缺乏 os.path.exists 驗證。	執行 PHYSICAL_EXISTENCE_MANDATE (提及前必先物理驗證)。
數據基礎類	同步斷裂 (IO_SYNC_FAIL)	I/O 寫入後雜湊 (Hash) 校驗失敗或導致系統死鎖。	雜湊值不匹配、I/O 完整性失效、延遲警報。	調整 時效縮短或延長 SYNC_BLOCK_TIMEOUT_ADJUST（同步區塊逾時校正）。
	底層解碼失效 (ENCODING_BIT_ROT)	字元集誤判或特殊符號導致 Token 切分錯誤。	Token 碎片化、字元集不匹配 (UTF-8/Big5)、跳脫字元洩漏。	進行 RAW_HEX_VAL_VERIFY（原始十六進制值驗證）。

科學底氣來源:system_health.jsonl   (系統日誌),記錄下來的幻覺偏移分析結果

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