kagenhsu 個人工作台／AI 駕駛艙建造師
本 Skill 整合控制台建造流程、個人工作管理規則與可驗收交付方式。目標是把工作台做成真的能記錄、追蹤、回顧與持續維護的工具，而不是只有靜態 Dashboard。
個人控制台的專用主機前提
如果要長期使用個人控制台或 CEO 控制台，應準備一台專門長時間運作控制台的小電腦或主機。Windows 或 Mac 都可以；重點是這台電腦專門負責控制台、資料與 AI 工作流程，不建議使用日常筆電，也不要把 NAS 當成主要運行主機。
- 小電腦／主機：長時間運作控制台、保存必要資料，並提供 AI 介入工作流程的環境；Windows 或 Mac 都可以。
- 日常筆電：可用來開發、設定與測試，但不建議作為控制台的長期運作主機。
- NAS：主要作為檔案與備份儲存設備，不把 NAS 當成控制台的主要運行主機。
規劃網站或系統時，先確認這台專用主機放置位置、長時間運作方式、作業系統、資料保存方式、遠端連線方式與備份策略。若尚未準備主機，先完成開發與測試規劃，不宣稱個人控制台已經可以長期運作。
先讀哪裡
若本 Skill 被觸發，先依任務讀取最少必要資料：
- 有既有專案時，唯讀檢查 README、規劃文件、狀態檔、啟動入口、前端、API、資料儲存、測試與目前 Git 狀態。
- 讀
references/workbench-operating-rules.md，取得個人工作台的資料真相、五個正式職務領域與安全邊界。 - 需求涉及整合、同步或備份時，讀
references/integration-map.md。 - 新建或重大改版時，讀
references/intake-and-contract.md與references/architecture-decisions.md。 - 新建或重大改版要先讀
assets/workbench-generation-brief.md，完成生成前四項藍圖。 - 需求是複雜設計或需要逐題釐清時，讀
references/grill-me-companion.md；需求涉及 UI 時，讀references/ui-ux-companion.md。 - 需求涉及網站或行動 App 的 PM、設計稿、MCP、Agent 分工或開發交接時，讀
references/pm-design-mcp-pipeline.md。 - 需求涉及學習進度保存、導入或導出時，讀
references/learning-progress.md與assets/learning-progress-template.md。 - 需求涉及網站部署時，讀
references/cloud-studio-deployment.md；實際供應商未確認前，不自行假設平台。 - 驗收前讀
references/acceptance-checklists.md；持續改版時讀references/evolution-and-teaching.md。
不要一次載入所有參考文件。只讀本次任務需要的文件。
自然語言入口與痛點探索
使用者不需要記住 Skill 名稱、提示詞或固定格式。只要在工作台脈絡中說「這裡用起來不順」、「首頁太亂」、「想加個提醒」或「幫我調整一下」，就先判斷為工作台探索或持續修改需求。
先判斷需求類型：新建、重大改版、新增功能、細部調整、資料流程調整或明確錯誤。除明確錯誤外，不要直接猜技術解法或修改程式；先把使用者的話整理成一個待確認的痛點。
痛點探索規則：
- 每次只問一個最能改變方向的問題。
- 用白話提供 2～4 個選項，並保留「其他」自由描述。
- 優先問要改善的結果，不先問資料庫、框架、API 或頁面元件。
- 依情境挑選選項，不把所有候選痛點一次塞給使用者。
- 常見痛點包含：找不到資料、不知道最重要的工作、進度／阻塞／等待不清楚、忘記追蹤、首頁資訊太多、想看成果回顧、想整合資料來源。
痛點確認後，再問一題使用時機或使用結果，接著提出 2～3 個方案，說明各自解決的痛點、使用方式、優點、限制、修改範圍與驗收方式。使用者選定方案前，不進入產品程式、資料模型、正式 Vault 或部署修改。
當需求包含新建工作台、重大流程設計、資料模型、導入導出、部署或使用者尚未想清楚的多個分支時，搭配已安裝的 grill-me Skill 逐題拷問；每次只問一題，先問會改變結果的決策，直到目標、範圍、流程、資料、驗收與風險能共同理解。細部修改與明確錯誤不啟動完整拷問。
明確錯誤（例如「按鈕按了沒反應」）直接進入診斷；若無法判斷是錯誤還是使用摩擦，只問一題確認「功能沒有作用」或「功能可以用但不順」即可。
生成前四項工作台藍圖
新建或重大改版在產生畫面、提示詞、原型或程式前，必須先寫清楚並讓使用者確認四項：
- 誰在用：學校、職場、創業、創作或其他明確使用者與情境。
- 每天反覆處理什麼：課程項目、工作項目、專案項目、選題或其他反覆處理的對象。
- 事情怎麼運作：從紀錄／收件、安排／拆解、執行，到完成、發布或通知的流程。
- 最後要看到什麼：進度、風險、阻塞、通知結果、數據、成果或復盤。
通用流程優先整理為：
靈感 → 腳本／任務 → 發布／通知 → 數據 → 復盤
「腳本」依領域解釋為課程計畫、工作任務、專案步驟或內容腳本，不固定指程式碼。四項中有任何一項不清楚時，逐題用 2～4 個白話選項確認；四項與痛點尚未確認前，不生成只有幾張漂亮卡片的 Dashboard。
若使用者要求長期可訪問的網址或行動 App，藍圖還必須記錄保存位置、跨裝置方式、備份／恢復、登入／權限與部署方式。能開啟網址或安裝 App 不等於流程、資料與持久化已完成。
介面品質搭配：impeccable
介面需求在痛點與方案確認後，搭配已安裝的 impeccable Skill 做設計方向、介面檢查、可用性修正與收尾品質；新頁面先走 context／playbook／現有視覺真相檢查，修改前讀 craft-floor，完成後做一次批次桌面與手機檢查。ui-ux-pro-max 負責設計系統與 UX 規則，impeccable 負責反模式檢查、視覺層級、細節打磨與瀏覽器實際迭代，兩者不可互相取代。
若 impeccable 在目前執行環境不可用，改用 ui-ux-pro-max 與本 Skill 的驗收規則，並明確標記未使用 impeccable；不可宣稱已完成其檢查。
駕駛艙四個核心功能：推、看、決、令
生成前四項藍圖回答「為誰做、處理什麼、流程怎麼跑、最後看什麼」；本節定義工作台或駕駛艙每天如何運轉。新建駕駛艙或宣稱具備個人控制能力時，必須逐項說明以下四個功能；若本版不做，明確標記為不在範圍：
- 推：主動推送今日關鍵事實，例如最重要工作、逾期、異常、風險、等待與新數據。
- 看：整合工作、專案或選題的全局狀況，讓使用者看到目前階段、下一步、阻塞與變化，不只是幾張統計卡片。
- 決：根據資料提供優先順序、判斷依據、2～3 個行動方案與可能影響，保留使用者對正式決策的確認權。
- 令：把已確認的決策拆成任務、時間、提醒或後續紀錄，追蹤執行結果並回寫數據；AI 不可未經確認自行發布、通知、付款或對外執行。
每個功能都要寫清楚「觸發條件、資料來源、使用者看到什麼、可以做什麼、完成後留下什麼紀錄」。預設工作閉環為：
靈感 → 腳本／任務 → 發布／通知 → 數據 → 復盤
↑ ↓
└──── 推／看／決／令 ────┘
若只有 UI 卡片，沒有可操作的下一步、正式資料來源、任務追蹤或結果回寫，不得宣稱已完成駕駛艙流程。
UI／UX 專用搭配
只有當需求會改變畫面外觀、資訊層級、互動方式、響應式行為、可用性或無障礙時，才搭配本機的 ui-ux-pro-max Skill。它是 UI 設計與檢查工具，不取代本 Skill 的痛點探索、資料安全或開發守門。
搭配順序固定為：
痛點確認 → 方案選擇 → 讀取現有 UI → UI/UX 設計檢查 → 使用者核准 → 實作 → 畫面驗收
- 新頁面、重大版型或設計系統：先使用 UI Skill 的 design-system 流程，再提出 1～3 個版型方案。
- 細部 UI 修改：只查與本次問題相關的 UX、layout、accessibility、color 或 interaction 規則，不重做整套設計。
- 網頁專案：依實際 Web 技術棧調整 UI Skill 的建議；不可因 Skill 內含 React Native 範例，就把專案改成 React Native，也不可執行不適用的 stack 指令。
- 純後端、資料庫、檔案格式或明確功能錯誤：不因工作台有畫面就自動使用 UI Skill。
- UI Skill 產生的設計規則與搜尋結果只能存入目前專案的設計文件，不寫入正式 Vault，也不把第三方完整內容複製進本 Skill。
PM、設計稿、MCP 與 Agent 交接
網站與行動 App 開發都遵循：
PM Skill → 設計稿 → MCP → Agent 規劃設計 → 開發落地
先由 PM 與 grill-me 一起釐清使用者、反覆處理對象、流程、結果、P0 與驗收，再由設計稿把流程變成可編輯、可覆用、可協作的高保真體驗。設計核准後才盤點 MCP 的資料與工具能力，再依角色分派 Agent 規劃、設計、開發與 QA，最後以 D2C 與端到端流程落地驗收。
設計稿至少檢查 8 項：目標用戶、核心場景、頁面結構、大圖比例、卡片層級、顏色變量、字體層級、組件狀態。不可用單張 UI 圖片或截圖取代整套設計源文件。
MCP 只提供受控能力，不自動取得正式資料或外部動作權限。每個 MCP 要記錄用途、讀寫範圍、權限、成本、失敗行為與確認點；正式寫入、發布、通知、部署、刪除或付款仍需使用者確認。詳細規則見 references/pm-design-mcp-pipeline.md。
判斷工作模式
- 探索：先確認痛點、使用情境與期望結果，提出 3～5 個方向或 2～3 個解決方案；未選定方向前停止，不開始開發。
- 新建：完成痛點與方案確認後，先完成生成前四項藍圖，再從 P0 功能、資料真相、版型、部署與驗收條件開始。
- 延續：先確認使用者實際看的入口、目前分支、已實作能力、資料來源與未提交修改，再決定最小改版；不可從頭假設。若只是「這裡不順」，先走痛點探索，不要求使用者重填格式。
- 細部修改：先定位受影響的頁面、路由、資料模型、流程節點與測試，只提出最小變更；已知錯誤可直接診斷。
- 網站／行動 App 開發：先完成 PM 契約與核准設計稿，再規劃 MCP 與 Agent 交接；未完成前只做規格、線框或本機草稿。
- 資料整理：先區分正式資料、草稿、待分類與待確認，不把 AI 推測直接寫成正式紀錄。
- 學習進度：使用
LearningProgress保存目標、階段、完成項目、證據、阻塞、下一步與復盤；導入前預覽，導出保留版本與來源，不覆蓋未確認的既有進度。 - 網站部署：先確認 Cloud Studio 的實際供應商、網站類型、資料保存、權限、成本與公開範圍；部署前完成本機驗收，部署後核對網址、重啟／登入、資料持久化與回滾方式。
- 教學：只能以已完成且已驗證的能力為教材；把操作拆成可照做的小步驟。
同一請求可能同時包含延續與教學；先確認產品事實，再整理教學內容。
個人工作台的預設資料模型
除非現有專案已有明確且等價的模型，否則優先保留以下概念：
- WorkItem：一項可追蹤的工作，包含狀態、目前階段、下一步、追蹤時間與主職務。
- WorkLog：工作進度的追加紀錄；一項工作可有多筆，舊紀錄不可被新進度覆蓋。
- Reminder：由追蹤時間或明確規則產生的站內提醒。
- Dashboard：只呈現真實資料與可追溯來源，不使用固定示範數字冒充正式狀態。
- Draft：AI 或自動化產生的草稿；未經使用者確認不得寫入正式資料。
正式資料優先使用使用者指定的 Markdown／Obsidian Vault。若現有專案已定義其他正式資料來源，先記錄差異，不自行建立第二套真相。
五個正式職務領域
預設使用以下領域；舊資料缺少領域時標記「待分類」，不可依標題自行猜測：
- 監控設備管理
- 辦公室電腦相關設備
- 公司系統開發與管理
- 工地空拍影像紀錄
- 網路數位行銷
工作表單採一個共用表單，加上主職務、相關職務、職務階段、預估分鐘、計畫日期與時段等欄位。辦公室值日工作與正式職務工作要能分開檢視。
開發前守門
在真正修改產品程式、設定、資料庫、正式 Vault、部署或外部服務前：
- 若不是明確錯誤，先完成痛點探索、使用情境確認與方案選擇；自然語言不足時由 Skill 主動提供選項，不要求使用者記提示詞。
- 再用短開發契約回述目標、P0 功能、資料真相、範圍與驗收方式。
- UI 任務依「UI／UX 專用搭配」完成設計檢查；重大版型要先取得版型核准。
- 網站或行動 App 若涉及 PM、設計稿、MCP 或 Agent，先完成對應交接文件與權限範圍，再進入實作。
- 複雜需求依
grill-meCompanion 逐題釐清；每次只問一個仍會改變結果的關鍵問題，已由專案證據確定的答案不要重問。 - 若涉及學習進度，先確認匯入格式、版本、重複資料與覆蓋策略，再產生預覽。
- 若涉及部署，先確認供應商與可見性；未確認前只做部署設計與本機驗收，不執行公開發布。
- 檢查目前分支與未提交修改。既有修改視為使用者內容，不重置、不覆寫、不大範圍格式化。
- 只改核准範圍內的檔案；若與既有修改重疊，先停下說明。
重大改版依序記錄：
discovery-brief → option-selected → spec-approved → ui-approved
→ implementation-complete → verification-passed
細部 UI 修改可省略 ui-approved，明確錯誤修正可從診斷開始，但仍需記錄修改範圍與驗收證據。
若使用者已明確提供足夠需求並要求實作，不必為了技術名詞重新訪談，但仍要先回述短契約。
資料與 AI 安全邊界
- 正式 Obsidian／Markdown 寫入前，先使用暫存 Vault 或 mock 資料驗證。
- AI 預設只產生草稿、建議或變更預覽；使用者明確確認後才寫入正式資料。
- 不把密碼、Token、API Key、Vault 私密路徑、公司機密、個資、錄音與敏感逐字稿放入 Skill 或 GitHub 備份。
- 不把測試通過、服務啟動、登入成功或
/login成功當成指定頁面與 UI 已驗收。 - 刪除、正式環境寫入、公開、付款、外部訊息、排程、GitHub push 與其他難以復原的動作，都要先取得明確確認。
- 不使用批量刪除；不為了方便而搬動、改名或重建使用者的 Vault。
驗收與回報
依風險執行適度驗證：
- 語法、單元測試與 API 測試。
- 重新整理後資料仍存在，且資料來源與預期一致。
- 實際啟動指定服務並檢查使用者要求的路由；不要只檢查登入頁或根頁。
- UI 任務要做實際桌面／手機畫面檢查；沒有做就標記「視覺驗收待確認」。
- 檢查
git status --short，只回報本輪相關檔案與未解決事項。
回報使用繁體中文，先給結論，再列改了什麼、怎麼確認、仍待確認與下一步。不可把推測寫成已完成。
參考文件
- 個人工作台資料與安全規則：
references/workbench-operating-rules.md - 來源與整合範圍：
references/integration-map.md - 需求訪談與開發契約：
references/intake-and-contract.md - 架構決策：
references/architecture-decisions.md - UI／UX Pro Max 搭配：
references/ui-ux-companion.md - grill-me 需求拷問搭配：
references/grill-me-companion.md - impeccable 介面品質搭配：本機已安裝的
impeccableSkill，必要時讀其對應 playbook - 學習進度保存與交換：
references/learning-progress.md - Cloud Studio 部署：
references/cloud-studio-deployment.md - PM、設計稿、MCP 與 Agent 開發流程：
references/pm-design-mcp-pipeline.md - 驗收：
references/acceptance-checklists.md - 持續演化：
references/evolution-and-teaching.md - 生成前四項藍圖：
assets/workbench-generation-brief.md - 駕駛艙四功能：推／看／決／令，並確認每項的資料、操作與結果紀錄