[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CEEW71AJDMZMXCSMXJD705":3,"skill-same:01M6CEEW71AJDMZMXCSMXJD705":153},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":22,"publishedAt":35,"linkOnly":36,"markdownContent":37,"markdownBody":38,"frontMatter":39,"refName":46,"commitSha":47,"skillDirectory":48,"forksCount":49,"repositoryHtmlUrl":50,"repositoryHomepageUrl":6,"ownerHtmlUrl":51,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":52,"install":53,"resources":66},"01M6CEEW71AJDMZMXCSMXJD705","vibe-coding-guidelines",null,"在非程式開發者要用 vibe coding 與 coding agent 協作時使用。常見觸發像「幫我整理開發準則」「定義交付邊界」「規劃驗證方式」。輸出需求表達、邊界與風險控管準則；不直接取代實作。","AllanYiin\u002FAmon","AllanYiin","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F13088261?v=4","01M6CECQFHKWW6YE0N7FDKSKYB","01M6CECQKTJSCPC7EA3YDHXR7N",2,"MIT","https:\u002F\u002Fgithub.com\u002FAllanYiin\u002FAmon\u002Fblob\u002Fmain\u002Fsrc\u002Famon\u002Fresources\u002Fskills\u002Fvibe-coding-guidelines\u002FSKILL.md",[17],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[23,24,25,26,27,28,29,30,31,32,33,34],"guidelines","coding","coding guidelines","vibe coding","vibe","vibe coding guidelines","coding agent","github","https","engineering","zh","coding-guidelines","2026-11-10 10:12:30",false,"---\nname: vibe-coding-guidelines\ndescription: 在非程式開發者要用 vibe coding 與 coding agent 協作時使用。常見觸發像「幫我整理開發準則」「定義交付邊界」「規劃驗證方式」。輸出需求表達、邊界與風險控管準則；不直接取代實作。\nversion: 2026.3.26\nhomepage: https:\u002F\u002Fgithub.com\u002FAllanYiin\u002Fskills\u002Ftree\u002Fmain\u002Fskills\u002Fvibe-coding-guidelines\nlicense: MIT\nmetadata: {\"author\":\"Allan Yiin\",\"language\":\"zh-TW\",\"category\":\"engineering\",\"short-description\":\"非程式開發者進行 vibe coding 時給 coding agent 的開發準則\"}\n---\n\n# Vibe Coding Guidelines\n\n## Purpose\n\n把「不懂程式的使用者」的需求，交付成一個可解壓縮後直接點一下就能啟動的專案：\n- Windows：雙擊 `run_app.bat`（它是 `scripts\u002Fproject_launcher.py` 生成\u002F維護的 Windows wrapper，不是另一份可自由發明的新主入口）\n- macOS：雙擊 `run_app.command`（若無法執行，請先 `chmod +x run_app.command`；若首次被系統阻擋，依提示到「系統設定 > 隱私權與安全性」允許後再執行）\n- Linux：雙擊或執行 `run_app.sh`（若無法執行，請先 `chmod +x run_app.sh`）\n\n同時提供繁體中文介面、狀態持久化、友善錯誤訊息與 logs；若使用者提供 SVG \u002F mockup \u002F 畫面規格，介面方向必須尊重原規格，不能擅自改風格。若是工作台型 UI，嚴格禁止 stacked UI \u002F stacked cards 疊首頁；必須先定義唯一主任務，並讓該功能盡量佔據最大、最中央、最先被看的畫面區域。任何工作台或流程頁都要把 task model、state model、資訊分類與 visibility plan 寫進規格與 `AGENTS.md`，不能只留一句「請簡潔」。\n\n## Scope\n\n### In scope\n\n- 以 Windows \u002F Linux \u002F macOS 為目標的 Python（優先）或必要時的 Python+Node 專案交付\n- 一鍵啟動（自建 venv、自裝 requirements、自動開瀏覽器\u002F視窗）\n- 專案規格→開發計畫→`todo.md` 檢核→逐檔寫入→測試→打包 ZIP\n- 各平台坑位（編碼、路徑、port、權限、防毒\u002F權限政策）避雷；Windows 特例會額外標註\n- OpenAI Responses 串流對話、Whisper STT、Nano Banana 2（Gemini 3.1 Flash Image）圖像（T2I\u002FI2I）整合規範\n\n### Out of scope\n\n- 需要使用者自行開 cmd\u002FPowerShell 手動輸入指令才能完成的交付\n- 需要 WSL\u002FLinux 才能執行的方案\n- 需要使用者自行調整系統環境變數才能運作的方案（除非已提供 UI 內設定流程）\n\n## Primary use cases\n\n1) **交付可一鍵啟動的 Windows 應用（ZIP）**\n- Trigger examples: 「幫我做一個 Windows 工具\u002F小程式」「我要下載解壓後直接點 run 就能跑」「打包成 ZIP 給我」\n- Expected result: ZIP 內含 `run_app.bat`、`requirements.txt`、`README.md`、`todo.md`；解壓後雙擊可啟動；錯誤寫入 `logs\u002F` 且 UI 以繁中提示。\n\n2) **既有專案的最小修改（不重構）**\n- Trigger examples: 「這個專案在 Windows 跑不起來」「中文亂碼」「port 被佔用」「缺套件\u002Frequirements 不對」\n- Expected result: 保持原 UI\u002F介面\u002FAPI 不變，做最小改動修好；提供被修改檔案的完整內容；再打包 ZIP。\n\n3) **加入 AI 功能且強制串流**\n- Trigger examples: 「加 ChatGPT 串流」「加語音轉文字」「加生圖\u002F修圖」「用 OpenAI Responses API」\n- Expected result: 所有 LLM 文字輸出皆 streaming；金鑰不硬編碼；model 由 env\u002Fconfig 管；STT\u002FT2I\u002FI2I 依規範接入。\n\n## Workflow overview\n\n最新流程以這個順序為準：\n\n1) 先釐清\u002F補齊規格，並把需求整理到 `specs\u002Frequirements.md`；至少寫清楚功能、輸入輸出、UI、資料保存、錯誤處理、打包方式，以及使用情境判定需要的四個軸。\n2) 產出並寫入 `todo.md`，後續以它作為唯一工作清單；若需求變動，先更新 `specs\u002Frequirements.md`，再更新 `todo.md`。\n3) 先讀 `references\u002Fusage_scene_decision_tree.md`，判定 `usage_scene` 與 `project_profile`；資訊不足時才反問最少問題，並把結果寫入根目錄 `project.config.json`。\n4) 依使用情境先生成根目錄 `AGENTS.md`，組成固定為「核心規則 + 使用情境規則 + 技術補充規則 + 專案特例」。\n5) 再讀 `references\u002Fapsm_decision_tree.md` 做 APSM 技術選型，決定 `archetype` \u002F `architecture` \u002F `frontend` \u002F `backend` \u002F `apsm_version`，並補完 `project.config.json`。\n6) 根據使用情境與 APSM 一起選目錄模板並建立骨架，至少補齊固定檔案、`README.md`、`specs\u002Frequirements.md`、`todo.md`、`.env.example`、`scripts\u002Fproject_launcher.py`、`scripts\u002Fapsm_validate.py` 與 `.venv\u002F`。\n7) 立刻執行 `python scripts\u002Fapsm_validate.py --project \u003Ctarget-project>`；先修完結構 errors，再繼續功能實作。\n8) 逐檔完成實作與必要測試，避免 placeholder；若需求包含 AI，再依規範整合 Responses 串流、Whisper、Nano Banana 2，並確保金鑰與設定管理合規。\n9) 在目標專案根目錄執行 `python scripts\u002Fproject_launcher.py`，完成依賴驗證、launcher 生成、runtime metadata 建立與常見啟動修正；之後至少做一次本機啟動驗證，並再跑 `python scripts\u002Fapsm_validate.py --project \u003Ctarget-project> --strict`。\n10) 確認 launcher、logs、runtime metadata 與錯誤訊息都符合規範後，壓縮成 ZIP 交付。\n\n## Routing boundaries\n\n- Neighboring skills \u002F workflows:\n  - `spec-organizer`：需求還沒整理成可開發規格。\n  - `frontend-design`：重點是前端視覺與互動，而不是整個可執行專案交付規範。\n  - `technical-documentation-writer`：只需要文件，不需要交付可啟動專案。\n- Negative triggers:\n  - 「幫我只做一段文案」\n  - 「只討論概念，不要產出專案」\n  - 「只改一個元件顏色，不做整體交付」\n- Handoff rule: 若任務不涉及可執行專案交付、啟動器、打包或新手協作規範，就不應啟動這個 skill。\n\n## Language coverage\n\n- Primary language(s): 繁體中文、英文。\n- Mixed-language trigger phrases: vibe coding、run_app.bat、ZIP delivery、project launcher、streaming chat、Windows tool。\n- Locale-specific wording risks: 使用者說「做個小工具」常隱含 Windows 一鍵啟動與零指令體驗，需要主動寫進規格。\n\n## Success criteria\n\n- `project.config.json` 除了 APSM 欄位外，還要包含 `usage_scene` 與 `project_profile`。\n- 根目錄必須存在 `AGENTS.md`，而且內容要對齊使用情境、技術選型與專案特例。\n- 預設場景必須是 `scene_b_shared_tool`，只有明確符合個人黑盒工具時才降到場景 A。\n\n- 使用者不需手動安裝依賴、不需手動輸入指令；只需解壓縮→點一下啟動（Windows：`run_app.bat`／macOS：`run_app.command`／Linux：`run_app.sh`）。\n- 跨平台可啟動：ZIP 內同時包含 `run_app.bat` \u002F `run_app.command` \u002F `run_app.sh`，且三者皆可在對應平台啟動。\n- `run_app.bat` \u002F `run_app.command` \u002F `run_app.sh` 都是由 `scripts\u002Fproject_launcher.py`（必要時搭配 `scripts\u002Fproject_launcher_posix.py`）生成或維護的 launcher wrapper；agent 應沿用或修改這條生成鏈，不得另外自創平行的 `run_app.bat` 主流程。\n- 編碼穩定：`.py\u002F.json\u002F.md` 為 UTF-8（建議無 BOM）；`run_app.bat` 預設 ASCII-only，不以 ANSI\u002FCP950 為策略，也不預設加入 `chcp 65001`；`run_app.command` \u002F `run_app.sh` 使用 UTF-8 LF。\n- 重要流程（I\u002FO、網路、LLM）不閃退：有全域 try\u002Fexcept、UI 友善錯誤、`logs\u002F` 有 stack trace。\n- port 衝突不可假裝已自動處理；若尚未實作完整動態 port 協調，至少要清楚提示衝突原因與下一步。若要支援動態 port，必須以服務實際綁定後回報的 port 為單一事實來源，並同步更新 URL \u002F API base \u002F log \u002F 啟動器狀態。\n- AI 回應必為 streaming；金鑰不出現在 logs。\n- 在規劃目錄前已完成 APSM 選型，且根目錄有可機器判讀的 `project.config.json`（含 `apsm_version` 與 `archetype`）；agent 不需要靠猜測目錄來反推架構。\n- `python scripts\u002Fapsm_validate.py --project \u003Ctarget-project> --strict` 可通過，代表 `project.config.json`、目錄結構、必要啟動檔與 `.env` 關鍵欄位一致。\n- 已執行過 `project_launcher.py` 的專案，必須另外具備 `.runtime\u002Fports.json`、`.runtime\u002Flauncher_state.json` 與 `logs\u002Flauncher.log` 等 machine-readable runtime metadata。\n- 若有 viewer \u002F editor \u002F diff \u002F preview 類工作台，必須只聚焦一個唯一主任務；主任務必須佔據最大、最中央、最先被看的區域，次要資訊退到側欄、drawer、tab 或折疊層，不得做成 stacked UI \u002F stacked cards 首頁。\n- 若有 viewer \u002F editor \u002F diff \u002F preview 類工作台，`specs\u002Frequirements.md` 與 `AGENTS.md` 必須都寫出：primary task、task model、state model、資訊角色分類、首屏主要群組上限與 disclosure 規則。\n- 工作台首頁預設只允許 2-3 個主要視覺群組，且只有 1 個主 CTA；`reference` 類資訊不得長期佔據主舞台。\n- 空狀態不可只留白；必須清楚說明缺少什麼、為何沒有內容、下一步要做什麼。\n\n## Instructions\n\n### Step 0: Inputs 期望\n\n- 若使用者有提供規格：直接進入 Step 1。\n- 若規格不足：自行補齊並以「白話文確認」列出：核心功能、限制、UI 版型（只有在未指定時才預設左右分欄；若規格已指定結構，不得擅改）、資料保存方式、輸出檔案（ZIP）。\n- 若屬工作台、dashboard、viewer、editor、review tool 或 setup flow，額外補齊：唯一主任務、task model、state model、資訊分類、visibility plan。\n\n### Step 1: 產生並維護 todo.md 與 specs\u002Frequirements.md\n\n- 在 `specs\u002Frequirements.md` 內另外整理四個判定軸，並直接對應到 `project_profile` 四欄：使用者是誰（`user_type`）、使用週期（`usage_duration`）、修改頻率（`change_frequency`）、壞掉代價（`failure_cost`）。\n- 若描述已足夠，直接推定；若資訊不足且會影響場景分類，再反問最少問題。\n\n- 把所有子任務寫成 checklist。\n- 把當前確認過的規格整理到根目錄 `specs\u002Frequirements.md`；至少包含：功能範圍、輸入輸出、UI\u002F互動、資料保存、外部依賴、驗收條件。\n- 若有工作台型 UI（viewer、editor、diff、preview、審閱台），規格內必須額外寫明：唯一主任務、主畫面責任、task model、state model、各資訊區塊的角色（`action-critical`、`decision-supporting`、`status-feedback`、`reference`、`exception-handling`、`audit\u002Fhistory`）、次要資訊應退到哪裡、首屏最多 2-3 個主要視覺群組、空狀態的下一步指引；嚴格禁止 stacked UI \u002F stacked cards 疊首頁。\n- 若使用者後續補需求，先更新 `specs\u002Frequirements.md`，再更新 `todo.md`；不要讓規格只散落在對話裡。\n- 後續每完成一項就打勾；任何新需求都先更新 todo.md。\n\n### Step 2: 使用情境判定與 AGENTS.md 組裝\n\n- 先讀 `references\u002Fusage_scene_decision_tree.md`，判斷 `usage_scene`，不要直接從技術棧反推場景。\n- `usage_scene` 只能是：\n  - `scene_a_personal_blackbox`\n  - `scene_b_shared_tool`\n  - `scene_c_internal_tool`\n  - `scene_d_engineer_maintained`\n- `project_profile` 至少包含：\n  - `user_type`\n  - `usage_duration`\n  - `change_frequency`\n  - `failure_cost`\n- 上述四欄就是 Step 1 提到的四個判定軸；欄位值域與判定規則以 `references\u002Fusage_scene_decision_tree.md` 為準。\n- 資訊不足時，預設 `scene_b_shared_tool`，不要預設 A。\n- 把 `usage_scene` 與 `project_profile` 寫進根目錄 `project.config.json`。\n- 在 APSM 技術選型之前，先產生根目錄 `AGENTS.md`。\n- `AGENTS.md` 的組成固定為：\n  - 核心規則\n  - 使用情境規則\n  - 技術補充規則\n  - 專案特例\n- `AGENTS.md` 至少要寫出：專案定位、最高原則、目錄與檔案規範、實作規範、UI \u002F UX 規範、修改規範、測試與打包規範、專案特例。\n- 若專案有主工作台，`AGENTS.md` 的 UI \u002F UX 規範必須額外包含：\n  - 先定義唯一主任務，再畫版面；盡量一次只聚焦一個功能\n  - 先寫 task model、state model、資訊分類與 visibility plan，再允許切版\n  - 主畫面只能讓主任務佔據中央、首要視線與最大化畫面區域\n  - 次要資訊退到側欄、drawer、tab 或折疊層；`reference` 類資訊預設 on-demand\n  - `exception-handling` 類資訊只在對應 state 顯示\n  - 首屏最多 2-3 個主要視覺群組，且只能有 1 個主 CTA\n  - 嚴格禁止 stacked UI \u002F stacked cards 首頁\n  - 空狀態要交代缺少內容、原因與下一步\n\n### Step 3: APSM 技術選型與專案類型宣告\n\n- APSM 是技術補充層，不是主分類；主分類先看使用情境。\n- `project.config.json` 除了 APSM 欄位外，還要保留 `usage_scene` 與 `project_profile`，讓場景規則、技術規則與 validator 對齊。\n\n- APSM（AI Project Structure Model）是這個 skill 的目錄規劃中樞。先定義 machine-readable config，再映射到目錄模板；不要跳過這一步。\n- 選型時先走 `references\u002Fapsm_decision_tree.md`；決策樹只負責篩選，不能取代完整模板矩陣。\n- APSM 是兩層模型：`archetype` 負責 AI\u002F新手入口分類，`architecture\u002Ffrontend\u002Fbackend` 負責精確技術組合。不要把這兩層混在一起。\n- 在規劃任何目錄結構前，先明確決定五個欄位：`archetype`、`architecture`、`frontend`、`backend`、`apsm_version`；不要直接從 A1\u002FB3 之類模板反推需求。\n- 技術選型原則：\n  - 預設以 Python 優先；只有在需要瀏覽器級 SPA、SSR\u002FMPA 框架能力，或明確需要 Node 生態時，才引入 Node。\n  - 若只是簡單表單、內部工具或模板渲染頁面，優先考慮 `single_service + python_templates + python_api`。\n  - 若前端與後端需要獨立啟動、獨立部署或 API 本身要獨立存在，才選 `separated`。\n  - 若仍想維持單一 repo 但前後端要分開組織，選 `monorepo`（`src\u002Fserver` + `src\u002Fweb`）。\n  - `archetype` 推薦值：\n  - `web_app`：`separated` 類型的 Web 前端 + API\n  - `monorepo`：前後端都放在 `src\u002F`\n  - `python_fullstack`：Python template rendering\n  - `fullstack_app`：目前此 skill 為相容既有 B4 模板保留的延伸 archetype（`single_service + node_ssr + node_api`）\n  - `service_api`：API-only 單體服務（`single_service + none + python_api\u002Fnode_api`）\n- 根目錄必須寫入 `project.config.json`，至少包含：\n  ```json\n  {\n    \"name\": \"my-vibe-app\",\n    \"apsm_version\": \"1.0\",\n    \"archetype\": \"web_app\",\n    \"architecture\": \"separated\",\n    \"frontend\": \"node_spa\",\n    \"backend\": \"python_api\",\n    \"version\": \"0.1.0\"\n  }\n  ```\n- `project.config.json` 是 APSM 的單一真相來源；`specs\u002Frequirements.md` 是需求真相來源。後續 `README.md` 的目錄說明、啟動入口與 `.env` 規劃都必須與兩者一致。\n- 可接受的 canonical 組合與對應模板，見 `references\u002Fdirectory_structure_recommendations.md`；若需求不吻合，先調整選型，再選最接近的模板，不要擅自發明新 root 規則。\n\n### Step 4: 目錄與固定檔案規範\n\n- 固定檔案除了 `project.config.json`、`specs\u002Frequirements.md`、`README.md`、`todo.md` 外，還要包含根目錄 `AGENTS.md`。\n- `AGENTS.md` 是正式產物，不是可有可無的補充說明。\n\n- 目標專案的相對路徑 `scripts\u002Fproject_launcher.py` 必須存在；這支檔案來自此 skill 內的 `scripts\u002Fproject_launcher.py`。\n- 目標專案的相對路徑 `scripts\u002Fapsm_validate.py` 也必須存在；這支檔案負責做 APSM 結構檢核。\n- 交付完成時，目標專案根目錄必有：`project.config.json`、`specs\u002Frequirements.md`、`.venv\u002F`（不打包）、`requirements.txt`、`run_app.bat`、`run_app.command`、`run_app.sh`、`.env`（不進版控）、`.env.example`、`README.md`、`todo.md`。\n- `run_app.bat` 是根目錄 `scripts\u002Fproject_launcher.py` 的 Windows 啟動 wrapper；若需要修 launcher 行為，優先修改\u002F重跑 `project_launcher.py`，不要另外手寫一份脫鉤的 `run_app.bat`。\n- 執行過 `project_launcher.py` 後，專案還應該有 `.runtime\u002Fports.json`、`.runtime\u002Flauncher_state.json` 與 `logs\u002Flauncher.log` 等 runtime metadata；這些檔案是 APSM Runtime 的機器判讀介面。\n- 目錄結構是技術選型結果，不是起點；必須先完成 Step 2，再依專案型態（前後端分離 \u002F monorepo \u002F single-service）選擇目錄。\n- 規範細節放在 `references\u002Fdirectory_structure_recommendations.md`。\n\n### Step 5: APSM 目錄結構檢核\n\n- validator 也要檢查 `usage_scene` \u002F `project_profile` \u002F `AGENTS.md`，避免只有技術模板對齊、但場景規則沒有落地。\n\n- 建立骨架後，立刻執行：\n  ```bash\n  python scripts\u002Fapsm_validate.py --project \u003Ctarget-project>\n  ```\n- validator 至少要檢查：\n  - `project.config.json` 是否存在、JSON 是否合法、`apsm_version` 是否支援、`archetype` 是否與組合一致\n  - `architecture\u002Ffrontend\u002Fbackend` 組合是否在 skill 支援清單內\n  - 根目錄固定檔案是否齊全\n  - 對應模板的關鍵目錄與關鍵入口檔是否存在\n  - `.env` 是否具備該組合所需的 host\u002Fport key\n  - 若已執行過 launcher，`.runtime\u002Fports.json` 與 `.runtime\u002Flauncher_state.json` 也要能通過 JSON 與 key 檢查\n- 若 validator 報錯，先修結構，再繼續開發；不要把結構錯誤帶到功能實作階段。\n\n### Step 5: Windows 專屬硬規則\n\n- `.bat` 只能用 Windows 指令（`dir\u002Fcopy\u002Fdel\u002Frmdir\u002Fset`），禁止 `ls\u002Frm\u002Fcp\u002Fexport`。\n- Python 路徑一律用 `os.path.join`\u002F`pathlib`；禁止手寫 `\\\\`。\n- 檔案讀寫顯式指定 `encoding='utf-8'`。\n- `run_app.bat` 預設只放 ASCII 文案；若真的要輸出中文等非 ASCII，才允許例外採 `chcp 65001` + UTF-8，且必須在實際 Windows 環境驗證。\n- 避免過深目錄以免 260 字元限制；遇到 Defender 阻擋要在 README 說明操作。\n\n### Step 6: AI 功能整合規範（需要才用）\n\n- Chat：一律 OpenAI Responses API + streaming；對話\u002F視覺用 `input` messages + parts。\n- STT：先 Whisper（`whisper-1`），失敗再用 Responses `input_audio` fallback。\n- 圖像：預設 Nano Banana 2（Gemini 3.1 Flash Image）做 T2I\u002FI2I；加上 no-text guardrail。\n- 若需要本地模型\u002F離線推論，優先評估 ONNX + ONNX Runtime；除非有明確理由，避免把 PyTorch 當成預設交付依賴。\n- 金鑰：只從 env\u002Fconfig 讀；不要硬編碼。\n- 若是前後端分離（例如 FastAPI\u002FFlask + React\u002FVue），後端必須處理 CORS，至少允許本機前端開發位址；前端 API base 必須和根目錄設定一致。\n\n（詳細程式型樣與封裝策略見 `references\u002Fopenai_nanobanana_guidelines.md`。）\n\n### Step 7: 錯誤處理與 logging\n\n- 主入口必包 `try\u002Fexcept`，禁止閃退。\n- UI 顯示「白話錯誤 + 請複製以下訊息給 AI 助手」；下方附完整 traceback。\n- logs 目錄分級記錄（INFO\u002FERROR），不得寫入 API key。\n- 若用 toast 顯示錯誤，停留時間要足夠，且內容應可選取\u002F複製；不要讓錯誤訊息一閃而過。\n- 若有使用 mocking \u002F 假資料 \u002F 假 API，必須在對話、README 或 UI 中明確揭露，不可讓使用者誤以為是真實資料流。\n\n### Step 8: 一鍵啟動與打包\n\n- 先將此 skill 內相對路徑 `scripts\u002Fproject_launcher.py` 與 `scripts\u002Fapsm_validate.py` 的內容寫入目標專案的相對路徑。\n- 主入口請維持 `scripts\u002Fproject_launcher.py`；它負責跨平台高階分類、修復與 launcher 生成，不應改成平台後綴名稱。\n- 雖然 PDF 原始規格傾向單一 `run_app`，但此 skill 為了維持 Windows\u002FmacOS\u002FLinux 的零指令雙擊體驗，仍保留 `run_app.bat` \u002F `run_app.command` \u002F `run_app.sh` 三入口；不要擅自改回單檔。\n- `run_app.bat` 是由 `scripts\u002Fproject_launcher.py` 生成\u002F維護的 Windows wrapper，不是獨立規格或另一套 hand-written launcher；若專案內已存在這條鏈，禁止 agent 自作主張另外寫一份新的 `run_app.bat` 取代它。\n- 若要沿用來源 skill 的分平台流程，或要在 POSIX 環境單獨驗證，也可一併帶入此 skill 內的 `scripts\u002Fproject_launcher_posix.py`，並以 `python scripts\u002Fproject_launcher_posix.py` 生成\u002F檢查 `run_app.sh` 與 `run_app.command`。舊名 `scripts\u002Fproject_launcher_linux.py` 僅保留相容別名，不建議再當主名稱。\n- 再於目標專案根目錄執行：`python scripts\u002Fproject_launcher.py` 以：\n  - 自動掃描 imports → 修正\u002F生成 `requirements.txt`\n  - 保守修正入口檔常見的 relative import 問題，並在改寫前產生 `.bak` 備份\n  - 建立 venv、安裝依賴、`pip check`、import test\n  - seed `.runtime\u002Fports.json`、`.runtime\u002Flauncher_state.json` 與必要 log 檔，讓 validator 與後續除錯都有單一可讀位置\n  - 偵測後端\u002F前端入口與設定中可推得的 host\u002Fport\n  - 生成 `run_app.bat` \u002F `run_app.command` \u002F `run_app.sh`；只有在 URL 可推得時才嘗試自動開瀏覽器。啟動器應先做 readiness probe 並把結果寫進 log 與終端，但即使 probe 失敗也仍要嘗試開瀏覽器，避免使用者誤以為系統卡死\n- 交付前打包 ZIP：在根目錄執行 `python scripts\u002Fproject_launcher.py --package`\n  - 預設輸出：`release\u002F\u003C資料夾名>.zip`\n  - 可用 `--package-out` 指定 ZIP 路徑\n  - ZIP 會排除：`.venv\u002F`、`__pycache__\u002F`、`node_modules\u002F`、`logs\u002F`、`.env`、`.launcher.env`\n  - ZIP 會保留：`dist\u002F`、`build\u002F`（靜態站\u002F前端成品常用）\n- 若要支援真正安全的動態 port：\n  - 優先讓服務自行綁定可用 port，之後再回讀實際 port；不要先掃描一個空 port 再假設仍可用\n  - 將實際 port 同步回寫到瀏覽器 URL、前端 API base、log、以及啟動器自己的狀態檔\n  - 在開瀏覽器前做 readiness check；若服務尚未 ready，就不要自動打開錯誤頁面\n\n### Step 9: Finalization and QA\n\n- 對照 `references\u002Fquality_checklist.md` 全部通過。\n- `python scripts\u002Fapsm_validate.py --project \u003Ctarget-project> --strict` 必須在交付前通過一次。\n- `.runtime\u002Fports.json` 與 `.runtime\u002Flauncher_state.json` 必須存在且為合法 JSON；若 launcher 已寫入 runtime state，就不能留空殼檔。\n- 至少做一次「解壓到新資料夾→雙擊 run_app.bat」的乾淨啟動驗證。\n\n## Testing plan\n\n### Triggering tests\n\n- Should trigger:\n  - 「幫我做一個 Windows 小工具，解壓後直接雙擊就能跑」\n  - 「這個專案 Windows 上中文亂碼\u002Fport 衝突，幫我修」\n  - 「加 OpenAI 串流對話 + 語音轉文字 + 生圖」\n- Should NOT trigger:\n  - 純概念性討論（不需要交付可執行專案）\n  - 純翻譯\u002F摘要，且不涉及 Windows 交付\n\n### Functional tests\n\n- Test case: 一鍵啟動\n  - Given: 新解壓縮的專案資料夾\n  - When: 點一下啟動（Windows：`run_app.bat`／macOS：`run_app.command`／Linux：`run_app.sh`）\n  - Then: 自動建立 venv、安裝依賴、啟動服務\u002F視窗；只有在 URL 可推得且已通過 readiness check 的設計下才自動開啟前端。失敗時顯示繁中說明並寫入 `logs\u002F`。\n\n- Test case: APSM 結構檢核\n  - Given: 已產生 `project.config.json` 與目錄骨架的專案\n  - When: 執行 `python scripts\u002Fapsm_validate.py --project \u003Ctarget-project> --strict`\n  - Then: 輸出 valid 結果；若缺檔、組合非法、`.env` key 不完整、或 `.runtime\u002F*.json` 結構不合法，會以 error code 與路徑回報。\n\n- Test case: 串流輸出\n  - Given: 啟用 OpenAI Responses chat\n  - When: 發送訊息\n  - Then: UI 逐 token 更新；中斷或錯誤可保留已生成內容。\n\n## Troubleshooting\n\n- 症狀：macOS\u002FLinux 雙擊 `run_app.*` 沒反應或提示沒有執行權限\n  - 修正：在 Terminal 執行 `chmod +x run_app.sh run_app.command` 後再執行\u002F雙擊。\n- 症狀：macOS 雙擊 `.command` 被系統阻擋\n  - 修正：依 README 指引到「系統設定 > 隱私權與安全性」允許開啟；必要時再補 `chmod +x`。\n\n- 症狀：`attempted relative import with no known parent package`\n  - 原因：入口檔相對匯入\n  - 修正：`project_launcher.py` 會保守修正常見入口檔的 relative import，並先寫出 `.bak` 備份；若仍失敗，再改成套件入口（例如 `python -m package.module`）或手動修正。\n\n## Resources\n\n- `references\u002Fusage_scene_decision_tree.md`：先判斷使用情境 A\u002FB\u002FC\u002FD，再輸出 `usage_scene`、`project_profile` 與 `AGENTS.md`\n\n- 以下皆為此 skill 目錄內的相對路徑；若要套用到目標專案，需先把對應內容寫入目標專案的相對位置。\n- `scripts\u002Fproject_launcher.py`：一鍵啟動腳本生成與依賴驗證；實際使用時應寫入目標專案的 `scripts\u002Fproject_launcher.py`\n- `scripts\u002Fapsm_validate.py`：APSM 結構檢核器；驗證 `project.config.json`、目錄模板與必要檔案是否一致\n- `scripts\u002Fproject_launcher_posix.py`：POSIX 相容入口；適合保留 split-platform 流程或在 Linux\u002FmacOS 上單獨驗證 launcher 行為\n- `scripts\u002Fproject_launcher_linux.py`：僅供相容舊流程的別名；名稱容易誤導，不建議作為新的主要引用\n- `references\u002Fopenai_nanobanana_guidelines.md`：OpenAI Responses 串流 + Nano Banana 2 圖像 + STT 規範\n- `references\u002Fapsm_decision_tree.md`：APSM 決策樹；先用它篩選 `archetype` \u002F `architecture` \u002F `frontend` \u002F `backend`，再去查模板細節\n- `references\u002Flinux_platform_pitfalls.md`：Linux 權限、Shell 啟動、`xdg-open` 與背景執行避雷\n- `references\u002Fmacos_platform_pitfalls.md`：macOS Finder、`.command`、Gatekeeper、`open` 與權限避雷\n- `references\u002Flinux_macos_platform_pitfalls.md`：Linux\u002FmacOS 導讀與共通原則，相容舊連結用\n- `references\u002Fwindows_platform_pitfalls.md`：Windows 常見錯誤與硬規則\n- `references\u002Fdirectory_structure_recommendations.md`：目錄結構建議與 port\u002Fenv 規範\n- `references\u002Fquality_checklist.md`：交付前 QA 清單\n","# Vibe Coding Guidelines\n\n## Purpose\n\n把「不懂程式的使用者」的需求，交付成一個可解壓縮後直接點一下就能啟動的專案：\n- Windows：雙擊 `run_app.bat`（它是 `scripts\u002Fproject_launcher.py` 生成\u002F維護的 Windows wrapper，不是另一份可自由發明的新主入口）\n- macOS：雙擊 `run_app.command`（若無法執行，請先 `chmod +x run_app.command`；若首次被系統阻擋，依提示到「系統設定 > 隱私權與安全性」允許後再執行）\n- Linux：雙擊或執行 `run_app.sh`（若無法執行，請先 `chmod +x run_app.sh`）\n\n同時提供繁體中文介面、狀態持久化、友善錯誤訊息與 logs；若使用者提供 SVG \u002F mockup \u002F 畫面規格，介面方向必須尊重原規格，不能擅自改風格。若是工作台型 UI，嚴格禁止 stacked UI \u002F stacked cards 疊首頁；必須先定義唯一主任務，並讓該功能盡量佔據最大、最中央、最先被看的畫面區域。任何工作台或流程頁都要把 task model、state model、資訊分類與 visibility plan 寫進規格與 `AGENTS.md`，不能只留一句「請簡潔」。\n\n## Scope\n\n### In scope\n\n- 以 Windows \u002F Linux \u002F macOS 為目標的 Python（優先）或必要時的 Python+Node 專案交付\n- 一鍵啟動（自建 venv、自裝 requirements、自動開瀏覽器\u002F視窗）\n- 專案規格→開發計畫→`todo.md` 檢核→逐檔寫入→測試→打包 ZIP\n- 各平台坑位（編碼、路徑、port、權限、防毒\u002F權限政策）避雷；Windows 特例會額外標註\n- OpenAI Responses 串流對話、Whisper STT、Nano Banana 2（Gemini 3.1 Flash Image）圖像（T2I\u002FI2I）整合規範\n\n### Out of scope\n\n- 需要使用者自行開 cmd\u002FPowerShell 手動輸入指令才能完成的交付\n- 需要 WSL\u002FLinux 才能執行的方案\n- 需要使用者自行調整系統環境變數才能運作的方案（除非已提供 UI 內設定流程）\n\n## Primary use cases\n\n1) **交付可一鍵啟動的 Windows 應用（ZIP）**\n- Trigger examples: 「幫我做一個 Windows 工具\u002F小程式」「我要下載解壓後直接點 run 就能跑」「打包成 ZIP 給我」\n- Expected result: ZIP 內含 `run_app.bat`、`requirements.txt`、`README.md`、`todo.md`；解壓後雙擊可啟動；錯誤寫入 `logs\u002F` 且 UI 以繁中提示。\n\n2) **既有專案的最小修改（不重構）**\n- Trigger examples: 「這個專案在 Windows 跑不起來」「中文亂碼」「port 被佔用」「缺套件\u002Frequirements 不對」\n- Expected result: 保持原 UI\u002F介面\u002FAPI 不變，做最小改動修好；提供被修改檔案的完整內容；再打包 ZIP。\n\n3) **加入 AI 功能且強制串流**\n- Trigger examples: 「加 ChatGPT 串流」「加語音轉文字」「加生圖\u002F修圖」「用 OpenAI Responses API」\n- Expected result: 所有 LLM 文字輸出皆 streaming；金鑰不硬編碼；model 由 env\u002Fconfig 管；STT\u002FT2I\u002FI2I 依規範接入。\n\n## Workflow overview\n\n最新流程以這個順序為準：\n\n1) 先釐清\u002F補齊規格，並把需求整理到 `specs\u002Frequirements.md`；至少寫清楚功能、輸入輸出、UI、資料保存、錯誤處理、打包方式，以及使用情境判定需要的四個軸。\n2) 產出並寫入 `todo.md`，後續以它作為唯一工作清單；若需求變動，先更新 `specs\u002Frequirements.md`，再更新 `todo.md`。\n3) 先讀 `references\u002Fusage_scene_decision_tree.md`，判定 `usage_scene` 與 `project_profile`；資訊不足時才反問最少問題，並把結果寫入根目錄 `project.config.json`。\n4) 依使用情境先生成根目錄 `AGENTS.md`，組成固定為「核心規則 + 使用情境規則 + 技術補充規則 + 專案特例」。\n5) 再讀 `references\u002Fapsm_decision_tree.md` 做 APSM 技術選型，決定 `archetype` \u002F `architecture` \u002F `frontend` \u002F `backend` \u002F `apsm_version`，並補完 `project.config.json`。\n6) 根據使用情境與 APSM 一起選目錄模板並建立骨架，至少補齊固定檔案、`README.md`、`specs\u002Frequirements.md`、`todo.md`、`.env.example`、`scripts\u002Fproject_launcher.py`、`scripts\u002Fapsm_validate.py` 與 `.venv\u002F`。\n7) 立刻執行 `python scripts\u002Fapsm_validate.py --project \u003Ctarget-project>`；先修完結構 errors，再繼續功能實作。\n8) 逐檔完成實作與必要測試，避免 placeholder；若需求包含 AI，再依規範整合 Responses 串流、Whisper、Nano Banana 2，並確保金鑰與設定管理合規。\n9) 在目標專案根目錄執行 `python scripts\u002Fproject_launcher.py`，完成依賴驗證、launcher 生成、runtime metadata 建立與常見啟動修正；之後至少做一次本機啟動驗證，並再跑 `python scripts\u002Fapsm_validate.py --project \u003Ctarget-project> --strict`。\n10) 確認 launcher、logs、runtime metadata 與錯誤訊息都符合規範後，壓縮成 ZIP 交付。\n\n## Routing boundaries\n\n- Neighboring skills \u002F workflows:\n  - `spec-organizer`：需求還沒整理成可開發規格。\n  - `frontend-design`：重點是前端視覺與互動，而不是整個可執行專案交付規範。\n  - `technical-documentation-writer`：只需要文件，不需要交付可啟動專案。\n- Negative triggers:\n  - 「幫我只做一段文案」\n  - 「只討論概念，不要產出專案」\n  - 「只改一個元件顏色，不做整體交付」\n- Handoff rule: 若任務不涉及可執行專案交付、啟動器、打包或新手協作規範，就不應啟動這個 skill。\n\n## Language coverage\n\n- Primary language(s): 繁體中文、英文。\n- Mixed-language trigger phrases: vibe coding、run_app.bat、ZIP delivery、project launcher、streaming chat、Windows tool。\n- Locale-specific wording risks: 使用者說「做個小工具」常隱含 Windows 一鍵啟動與零指令體驗，需要主動寫進規格。\n\n## Success criteria\n\n- `project.config.json` 除了 APSM 欄位外，還要包含 `usage_scene` 與 `project_profile`。\n- 根目錄必須存在 `AGENTS.md`，而且內容要對齊使用情境、技術選型與專案特例。\n- 預設場景必須是 `scene_b_shared_tool`，只有明確符合個人黑盒工具時才降到場景 A。\n\n- 使用者不需手動安裝依賴、不需手動輸入指令；只需解壓縮→點一下啟動（Windows：`run_app.bat`／macOS：`run_app.command`／Linux：`run_app.sh`）。\n- 跨平台可啟動：ZIP 內同時包含 `run_app.bat` \u002F `run_app.command` \u002F `run_app.sh`，且三者皆可在對應平台啟動。\n- `run_app.bat` \u002F `run_app.command` \u002F `run_app.sh` 都是由 `scripts\u002Fproject_launcher.py`（必要時搭配 `scripts\u002Fproject_launcher_posix.py`）生成或維護的 launcher wrapper；agent 應沿用或修改這條生成鏈，不得另外自創平行的 `run_app.bat` 主流程。\n- 編碼穩定：`.py\u002F.json\u002F.md` 為 UTF-8（建議無 BOM）；`run_app.bat` 預設 ASCII-only，不以 ANSI\u002FCP950 為策略，也不預設加入 `chcp 65001`；`run_app.command` \u002F `run_app.sh` 使用 UTF-8 LF。\n- 重要流程（I\u002FO、網路、LLM）不閃退：有全域 try\u002Fexcept、UI 友善錯誤、`logs\u002F` 有 stack trace。\n- port 衝突不可假裝已自動處理；若尚未實作完整動態 port 協調，至少要清楚提示衝突原因與下一步。若要支援動態 port，必須以服務實際綁定後回報的 port 為單一事實來源，並同步更新 URL \u002F API base \u002F log \u002F 啟動器狀態。\n- AI 回應必為 streaming；金鑰不出現在 logs。\n- 在規劃目錄前已完成 APSM 選型，且根目錄有可機器判讀的 `project.config.json`（含 `apsm_version` 與 `archetype`）；agent 不需要靠猜測目錄來反推架構。\n- `python scripts\u002Fapsm_validate.py --project \u003Ctarget-project> --strict` 可通過，代表 `project.config.json`、目錄結構、必要啟動檔與 `.env` 關鍵欄位一致。\n- 已執行過 `project_launcher.py` 的專案，必須另外具備 `.runtime\u002Fports.json`、`.runtime\u002Flauncher_state.json` 與 `logs\u002Flauncher.log` 等 machine-readable runtime metadata。\n- 若有 viewer \u002F editor \u002F diff \u002F preview 類工作台，必須只聚焦一個唯一主任務；主任務必須佔據最大、最中央、最先被看的區域，次要資訊退到側欄、drawer、tab 或折疊層，不得做成 stacked UI \u002F stacked cards 首頁。\n- 若有 viewer \u002F editor \u002F diff \u002F preview 類工作台，`specs\u002Frequirements.md` 與 `AGENTS.md` 必須都寫出：primary task、task model、state model、資訊角色分類、首屏主要群組上限與 disclosure 規則。\n- 工作台首頁預設只允許 2-3 個主要視覺群組，且只有 1 個主 CTA；`reference` 類資訊不得長期佔據主舞台。\n- 空狀態不可只留白；必須清楚說明缺少什麼、為何沒有內容、下一步要做什麼。\n\n## Instructions\n\n### Step 0: Inputs 期望\n\n- 若使用者有提供規格：直接進入 Step 1。\n- 若規格不足：自行補齊並以「白話文確認」列出：核心功能、限制、UI 版型（只有在未指定時才預設左右分欄；若規格已指定結構，不得擅改）、資料保存方式、輸出檔案（ZIP）。\n- 若屬工作台、dashboard、viewer、editor、review tool 或 setup flow，額外補齊：唯一主任務、task model、state model、資訊分類、visibility plan。\n\n### Step 1: 產生並維護 todo.md 與 specs\u002Frequirements.md\n\n- 在 `specs\u002Frequirements.md` 內另外整理四個判定軸，並直接對應到 `project_profile` 四欄：使用者是誰（`user_type`）、使用週期（`usage_duration`）、修改頻率（`change_frequency`）、壞掉代價（`failure_cost`）。\n- 若描述已足夠，直接推定；若資訊不足且會影響場景分類，再反問最少問題。\n\n- 把所有子任務寫成 checklist。\n- 把當前確認過的規格整理到根目錄 `specs\u002Frequirements.md`；至少包含：功能範圍、輸入輸出、UI\u002F互動、資料保存、外部依賴、驗收條件。\n- 若有工作台型 UI（viewer、editor、diff、preview、審閱台），規格內必須額外寫明：唯一主任務、主畫面責任、task model、state model、各資訊區塊的角色（`action-critical`、`decision-supporting`、`status-feedback`、`reference`、`exception-handling`、`audit\u002Fhistory`）、次要資訊應退到哪裡、首屏最多 2-3 個主要視覺群組、空狀態的下一步指引；嚴格禁止 stacked UI \u002F stacked cards 疊首頁。\n- 若使用者後續補需求，先更新 `specs\u002Frequirements.md`，再更新 `todo.md`；不要讓規格只散落在對話裡。\n- 後續每完成一項就打勾；任何新需求都先更新 todo.md。\n\n### Step 2: 使用情境判定與 AGENTS.md 組裝\n\n- 先讀 `references\u002Fusage_scene_decision_tree.md`，判斷 `usage_scene`，不要直接從技術棧反推場景。\n- `usage_scene` 只能是：\n  - `scene_a_personal_blackbox`\n  - `scene_b_shared_tool`\n  - `scene_c_internal_tool`\n  - `scene_d_engineer_maintained`\n- `project_profile` 至少包含：\n  - `user_type`\n  - `usage_duration`\n  - `change_frequency`\n  - `failure_cost`\n- 上述四欄就是 Step 1 提到的四個判定軸；欄位值域與判定規則以 `references\u002Fusage_scene_decision_tree.md` 為準。\n- 資訊不足時，預設 `scene_b_shared_tool`，不要預設 A。\n- 把 `usage_scene` 與 `project_profile` 寫進根目錄 `project.config.json`。\n- 在 APSM 技術選型之前，先產生根目錄 `AGENTS.md`。\n- `AGENTS.md` 的組成固定為：\n  - 核心規則\n  - 使用情境規則\n  - 技術補充規則\n  - 專案特例\n- `AGENTS.md` 至少要寫出：專案定位、最高原則、目錄與檔案規範、實作規範、UI \u002F UX 規範、修改規範、測試與打包規範、專案特例。\n- 若專案有主工作台，`AGENTS.md` 的 UI \u002F UX 規範必須額外包含：\n  - 先定義唯一主任務，再畫版面；盡量一次只聚焦一個功能\n  - 先寫 task model、state model、資訊分類與 visibility plan，再允許切版\n  - 主畫面只能讓主任務佔據中央、首要視線與最大化畫面區域\n  - 次要資訊退到側欄、drawer、tab 或折疊層；`reference` 類資訊預設 on-demand\n  - `exception-handling` 類資訊只在對應 state 顯示\n  - 首屏最多 2-3 個主要視覺群組，且只能有 1 個主 CTA\n  - 嚴格禁止 stacked UI \u002F stacked cards 首頁\n  - 空狀態要交代缺少內容、原因與下一步\n\n### Step 3: APSM 技術選型與專案類型宣告\n\n- APSM 是技術補充層，不是主分類；主分類先看使用情境。\n- `project.config.json` 除了 APSM 欄位外，還要保留 `usage_scene` 與 `project_profile`，讓場景規則、技術規則與 validator 對齊。\n\n- APSM（AI Project Structure Model）是這個 skill 的目錄規劃中樞。先定義 machine-readable config，再映射到目錄模板；不要跳過這一步。\n- 選型時先走 `references\u002Fapsm_decision_tree.md`；決策樹只負責篩選，不能取代完整模板矩陣。\n- APSM 是兩層模型：`archetype` 負責 AI\u002F新手入口分類，`architecture\u002Ffrontend\u002Fbackend` 負責精確技術組合。不要把這兩層混在一起。\n- 在規劃任何目錄結構前，先明確決定五個欄位：`archetype`、`architecture`、`frontend`、`backend`、`apsm_version`；不要直接從 A1\u002FB3 之類模板反推需求。\n- 技術選型原則：\n  - 預設以 Python 優先；只有在需要瀏覽器級 SPA、SSR\u002FMPA 框架能力，或明確需要 Node 生態時，才引入 Node。\n  - 若只是簡單表單、內部工具或模板渲染頁面，優先考慮 `single_service + python_templates + python_api`。\n  - 若前端與後端需要獨立啟動、獨立部署或 API 本身要獨立存在，才選 `separated`。\n  - 若仍想維持單一 repo 但前後端要分開組織，選 `monorepo`（`src\u002Fserver` + `src\u002Fweb`）。\n  - `archetype` 推薦值：\n  - `web_app`：`separated` 類型的 Web 前端 + API\n  - `monorepo`：前後端都放在 `src\u002F`\n  - `python_fullstack`：Python template rendering\n  - `fullstack_app`：目前此 skill 為相容既有 B4 模板保留的延伸 archetype（`single_service + node_ssr + node_api`）\n  - `service_api`：API-only 單體服務（`single_service + none + python_api\u002Fnode_api`）\n- 根目錄必須寫入 `project.config.json`，至少包含：\n  ```json\n  {\n    \"name\": \"my-vibe-app\",\n    \"apsm_version\": \"1.0\",\n    \"archetype\": \"web_app\",\n    \"architecture\": \"separated\",\n    \"frontend\": \"node_spa\",\n    \"backend\": \"python_api\",\n    \"version\": \"0.1.0\"\n  }\n  ```\n- `project.config.json` 是 APSM 的單一真相來源；`specs\u002Frequirements.md` 是需求真相來源。後續 `README.md` 的目錄說明、啟動入口與 `.env` 規劃都必須與兩者一致。\n- 可接受的 canonical 組合與對應模板，見 `references\u002Fdirectory_structure_recommendations.md`；若需求不吻合，先調整選型，再選最接近的模板，不要擅自發明新 root 規則。\n\n### Step 4: 目錄與固定檔案規範\n\n- 固定檔案除了 `project.config.json`、`specs\u002Frequirements.md`、`README.md`、`todo.md` 外，還要包含根目錄 `AGENTS.md`。\n- `AGENTS.md` 是正式產物，不是可有可無的補充說明。\n\n- 目標專案的相對路徑 `scripts\u002Fproject_launcher.py` 必須存在；這支檔案來自此 skill 內的 `scripts\u002Fproject_launcher.py`。\n- 目標專案的相對路徑 `scripts\u002Fapsm_validate.py` 也必須存在；這支檔案負責做 APSM 結構檢核。\n- 交付完成時，目標專案根目錄必有：`project.config.json`、`specs\u002Frequirements.md`、`.venv\u002F`（不打包）、`requirements.txt`、`run_app.bat`、`run_app.command`、`run_app.sh`、`.env`（不進版控）、`.env.example`、`README.md`、`todo.md`。\n- `run_app.bat` 是根目錄 `scripts\u002Fproject_launcher.py` 的 Windows 啟動 wrapper；若需要修 launcher 行為，優先修改\u002F重跑 `project_launcher.py`，不要另外手寫一份脫鉤的 `run_app.bat`。\n- 執行過 `project_launcher.py` 後，專案還應該有 `.runtime\u002Fports.json`、`.runtime\u002Flauncher_state.json` 與 `logs\u002Flauncher.log` 等 runtime metadata；這些檔案是 APSM Runtime 的機器判讀介面。\n- 目錄結構是技術選型結果，不是起點；必須先完成 Step 2，再依專案型態（前後端分離 \u002F monorepo \u002F single-service）選擇目錄。\n- 規範細節放在 `references\u002Fdirectory_structure_recommendations.md`。\n\n### Step 5: APSM 目錄結構檢核\n\n- validator 也要檢查 `usage_scene` \u002F `project_profile` \u002F `AGENTS.md`，避免只有技術模板對齊、但場景規則沒有落地。\n\n- 建立骨架後，立刻執行：\n  ```bash\n  python scripts\u002Fapsm_validate.py --project \u003Ctarget-project>\n  ```\n- validator 至少要檢查：\n  - `project.config.json` 是否存在、JSON 是否合法、`apsm_version` 是否支援、`archetype` 是否與組合一致\n  - `architecture\u002Ffrontend\u002Fbackend` 組合是否在 skill 支援清單內\n  - 根目錄固定檔案是否齊全\n  - 對應模板的關鍵目錄與關鍵入口檔是否存在\n  - `.env` 是否具備該組合所需的 host\u002Fport key\n  - 若已執行過 launcher，`.runtime\u002Fports.json` 與 `.runtime\u002Flauncher_state.json` 也要能通過 JSON 與 key 檢查\n- 若 validator 報錯，先修結構，再繼續開發；不要把結構錯誤帶到功能實作階段。\n\n### Step 5: Windows 專屬硬規則\n\n- `.bat` 只能用 Windows 指令（`dir\u002Fcopy\u002Fdel\u002Frmdir\u002Fset`），禁止 `ls\u002Frm\u002Fcp\u002Fexport`。\n- Python 路徑一律用 `os.path.join`\u002F`pathlib`；禁止手寫 `\\\\`。\n- 檔案讀寫顯式指定 `encoding='utf-8'`。\n- `run_app.bat` 預設只放 ASCII 文案；若真的要輸出中文等非 ASCII，才允許例外採 `chcp 65001` + UTF-8，且必須在實際 Windows 環境驗證。\n- 避免過深目錄以免 260 字元限制；遇到 Defender 阻擋要在 README 說明操作。\n\n### Step 6: AI 功能整合規範（需要才用）\n\n- Chat：一律 OpenAI Responses API + streaming；對話\u002F視覺用 `input` messages + parts。\n- STT：先 Whisper（`whisper-1`），失敗再用 Responses `input_audio` fallback。\n- 圖像：預設 Nano Banana 2（Gemini 3.1 Flash Image）做 T2I\u002FI2I；加上 no-text guardrail。\n- 若需要本地模型\u002F離線推論，優先評估 ONNX + ONNX Runtime；除非有明確理由，避免把 PyTorch 當成預設交付依賴。\n- 金鑰：只從 env\u002Fconfig 讀；不要硬編碼。\n- 若是前後端分離（例如 FastAPI\u002FFlask + React\u002FVue），後端必須處理 CORS，至少允許本機前端開發位址；前端 API base 必須和根目錄設定一致。\n\n（詳細程式型樣與封裝策略見 `references\u002Fopenai_nanobanana_guidelines.md`。）\n\n### Step 7: 錯誤處理與 logging\n\n- 主入口必包 `try\u002Fexcept`，禁止閃退。\n- UI 顯示「白話錯誤 + 請複製以下訊息給 AI 助手」；下方附完整 traceback。\n- logs 目錄分級記錄（INFO\u002FERROR），不得寫入 API key。\n- 若用 toast 顯示錯誤，停留時間要足夠，且內容應可選取\u002F複製；不要讓錯誤訊息一閃而過。\n- 若有使用 mocking \u002F 假資料 \u002F 假 API，必須在對話、README 或 UI 中明確揭露，不可讓使用者誤以為是真實資料流。\n\n### Step 8: 一鍵啟動與打包\n\n- 先將此 skill 內相對路徑 `scripts\u002Fproject_launcher.py` 與 `scripts\u002Fapsm_validate.py` 的內容寫入目標專案的相對路徑。\n- 主入口請維持 `scripts\u002Fproject_launcher.py`；它負責跨平台高階分類、修復與 launcher 生成，不應改成平台後綴名稱。\n- 雖然 PDF 原始規格傾向單一 `run_app`，但此 skill 為了維持 Windows\u002FmacOS\u002FLinux 的零指令雙擊體驗，仍保留 `run_app.bat` \u002F `run_app.command` \u002F `run_app.sh` 三入口；不要擅自改回單檔。\n- `run_app.bat` 是由 `scripts\u002Fproject_launcher.py` 生成\u002F維護的 Windows wrapper，不是獨立規格或另一套 hand-written launcher；若專案內已存在這條鏈，禁止 agent 自作主張另外寫一份新的 `run_app.bat` 取代它。\n- 若要沿用來源 skill 的分平台流程，或要在 POSIX 環境單獨驗證，也可一併帶入此 skill 內的 `scripts\u002Fproject_launcher_posix.py`，並以 `python scripts\u002Fproject_launcher_posix.py` 生成\u002F檢查 `run_app.sh` 與 `run_app.command`。舊名 `scripts\u002Fproject_launcher_linux.py` 僅保留相容別名，不建議再當主名稱。\n- 再於目標專案根目錄執行：`python scripts\u002Fproject_launcher.py` 以：\n  - 自動掃描 imports → 修正\u002F生成 `requirements.txt`\n  - 保守修正入口檔常見的 relative import 問題，並在改寫前產生 `.bak` 備份\n  - 建立 venv、安裝依賴、`pip check`、import test\n  - seed `.runtime\u002Fports.json`、`.runtime\u002Flauncher_state.json` 與必要 log 檔，讓 validator 與後續除錯都有單一可讀位置\n  - 偵測後端\u002F前端入口與設定中可推得的 host\u002Fport\n  - 生成 `run_app.bat` \u002F `run_app.command` \u002F `run_app.sh`；只有在 URL 可推得時才嘗試自動開瀏覽器。啟動器應先做 readiness probe 並把結果寫進 log 與終端，但即使 probe 失敗也仍要嘗試開瀏覽器，避免使用者誤以為系統卡死\n- 交付前打包 ZIP：在根目錄執行 `python scripts\u002Fproject_launcher.py --package`\n  - 預設輸出：`release\u002F\u003C資料夾名>.zip`\n  - 可用 `--package-out` 指定 ZIP 路徑\n  - ZIP 會排除：`.venv\u002F`、`__pycache__\u002F`、`node_modules\u002F`、`logs\u002F`、`.env`、`.launcher.env`\n  - ZIP 會保留：`dist\u002F`、`build\u002F`（靜態站\u002F前端成品常用）\n- 若要支援真正安全的動態 port：\n  - 優先讓服務自行綁定可用 port，之後再回讀實際 port；不要先掃描一個空 port 再假設仍可用\n  - 將實際 port 同步回寫到瀏覽器 URL、前端 API base、log、以及啟動器自己的狀態檔\n  - 在開瀏覽器前做 readiness check；若服務尚未 ready，就不要自動打開錯誤頁面\n\n### Step 9: Finalization and QA\n\n- 對照 `references\u002Fquality_checklist.md` 全部通過。\n- `python scripts\u002Fapsm_validate.py --project \u003Ctarget-project> --strict` 必須在交付前通過一次。\n- `.runtime\u002Fports.json` 與 `.runtime\u002Flauncher_state.json` 必須存在且為合法 JSON；若 launcher 已寫入 runtime state，就不能留空殼檔。\n- 至少做一次「解壓到新資料夾→雙擊 run_app.bat」的乾淨啟動驗證。\n\n## Testing plan\n\n### Triggering tests\n\n- Should trigger:\n  - 「幫我做一個 Windows 小工具，解壓後直接雙擊就能跑」\n  - 「這個專案 Windows 上中文亂碼\u002Fport 衝突，幫我修」\n  - 「加 OpenAI 串流對話 + 語音轉文字 + 生圖」\n- Should NOT trigger:\n  - 純概念性討論（不需要交付可執行專案）\n  - 純翻譯\u002F摘要，且不涉及 Windows 交付\n\n### Functional tests\n\n- Test case: 一鍵啟動\n  - Given: 新解壓縮的專案資料夾\n  - When: 點一下啟動（Windows：`run_app.bat`／macOS：`run_app.command`／Linux：`run_app.sh`）\n  - Then: 自動建立 venv、安裝依賴、啟動服務\u002F視窗；只有在 URL 可推得且已通過 readiness check 的設計下才自動開啟前端。失敗時顯示繁中說明並寫入 `logs\u002F`。\n\n- Test case: APSM 結構檢核\n  - Given: 已產生 `project.config.json` 與目錄骨架的專案\n  - When: 執行 `python scripts\u002Fapsm_validate.py --project \u003Ctarget-project> --strict`\n  - Then: 輸出 valid 結果；若缺檔、組合非法、`.env` key 不完整、或 `.runtime\u002F*.json` 結構不合法，會以 error code 與路徑回報。\n\n- Test case: 串流輸出\n  - Given: 啟用 OpenAI Responses chat\n  - When: 發送訊息\n  - Then: UI 逐 token 更新；中斷或錯誤可保留已生成內容。\n\n## Troubleshooting\n\n- 症狀：macOS\u002FLinux 雙擊 `run_app.*` 沒反應或提示沒有執行權限\n  - 修正：在 Terminal 執行 `chmod +x run_app.sh run_app.command` 後再執行\u002F雙擊。\n- 症狀：macOS 雙擊 `.command` 被系統阻擋\n  - 修正：依 README 指引到「系統設定 > 隱私權與安全性」允許開啟；必要時再補 `chmod +x`。\n\n- 症狀：`attempted relative import with no known parent package`\n  - 原因：入口檔相對匯入\n  - 修正：`project_launcher.py` 會保守修正常見入口檔的 relative import，並先寫出 `.bak` 備份；若仍失敗，再改成套件入口（例如 `python -m package.module`）或手動修正。\n\n## Resources\n\n- `references\u002Fusage_scene_decision_tree.md`：先判斷使用情境 A\u002FB\u002FC\u002FD，再輸出 `usage_scene`、`project_profile` 與 `AGENTS.md`\n\n- 以下皆為此 skill 目錄內的相對路徑；若要套用到目標專案，需先把對應內容寫入目標專案的相對位置。\n- `scripts\u002Fproject_launcher.py`：一鍵啟動腳本生成與依賴驗證；實際使用時應寫入目標專案的 `scripts\u002Fproject_launcher.py`\n- `scripts\u002Fapsm_validate.py`：APSM 結構檢核器；驗證 `project.config.json`、目錄模板與必要檔案是否一致\n- `scripts\u002Fproject_launcher_posix.py`：POSIX 相容入口；適合保留 split-platform 流程或在 Linux\u002FmacOS 上單獨驗證 launcher 行為\n- `scripts\u002Fproject_launcher_linux.py`：僅供相容舊流程的別名；名稱容易誤導，不建議作為新的主要引用\n- `references\u002Fopenai_nanobanana_guidelines.md`：OpenAI Responses 串流 + Nano Banana 2 圖像 + STT 規範\n- `references\u002Fapsm_decision_tree.md`：APSM 決策樹；先用它篩選 `archetype` \u002F `architecture` \u002F `frontend` \u002F `backend`，再去查模板細節\n- `references\u002Flinux_platform_pitfalls.md`：Linux 權限、Shell 啟動、`xdg-open` 與背景執行避雷\n- `references\u002Fmacos_platform_pitfalls.md`：macOS Finder、`.command`、Gatekeeper、`open` 與權限避雷\n- `references\u002Flinux_macos_platform_pitfalls.md`：Linux\u002FmacOS 導讀與共通原則，相容舊連結用\n- `references\u002Fwindows_platform_pitfalls.md`：Windows 常見錯誤與硬規則\n- `references\u002Fdirectory_structure_recommendations.md`：目錄結構建議與 port\u002Fenv 規範\n- `references\u002Fquality_checklist.md`：交付前 QA 清單\n",{"name":5,"license":14,"version":40,"homepage":41,"metadata":42,"description":7},"2026.3.26","https:\u002F\u002Fgithub.com\u002FAllanYiin\u002Fskills\u002Ftree\u002Fmain\u002Fskills\u002Fvibe-coding-guidelines",{"author":43,"category":32,"language":44,"short-description":45},"Allan Yiin","zh-TW","非程式開發者進行 vibe coding 時給 coding agent 的開發準則","main","0abce4d3cb71af4948463d31aa24ff5867ddcb2f","src\u002Famon\u002Fresources\u002Fskills\u002Fvibe-coding-guidelines",1,"https:\u002F\u002Fgithub.com\u002FAllanYiin\u002FAmon","https:\u002F\u002Fgithub.com\u002FAllanYiin","2026-03-29 12:36:35",{"source":8,"skillName":5,"commands":54,"prompt":64,"zipAvailable":65},[55,58,61],{"tool":56,"command":57},"npx","npx skills add AllanYiin\u002FAmon --skill vibe-coding-guidelines",{"tool":59,"command":60},"bunx","bunx skills add AllanYiin\u002FAmon --skill vibe-coding-guidelines",{"tool":62,"command":63},"pnpm","pnpm dlx skills add AllanYiin\u002FAmon --skill vibe-coding-guidelines","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FAllanYiin\u002FAmon\u002Fblob\u002Fmain\u002Fsrc\u002Famon\u002Fresources\u002Fskills\u002Fvibe-coding-guidelines\u002FSKILL.md",true,[67,73,79,83,87,91,95,99,103,107,111,115,119,123,129,133,137,141,145,149],{"path":68,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":71,"sourceHtmlUrl":72},"CHANGELOG.md","REFERENCE","参考文档",273,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fexchanges\u002Fbinance-official-derivatives-trading-coin-futures\u002FCHANGELOG.md",{"path":74,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":77,"sourceHtmlUrl":78},"LICENSE.md","LICENSE","许可证",1063,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fexchanges\u002Fbinance-official-derivatives-trading-coin-futures\u002FLICENSE.md",{"path":80,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":81,"sourceHtmlUrl":82},"LICENSE.txt",1056,"https:\u002F\u002Fgithub.com\u002FAllanYiin\u002FAmon\u002Fblob\u002Fmain\u002Fsrc\u002Famon\u002Fresources\u002Fskills\u002Fvibe-coding-guidelines\u002FLICENSE.txt",{"path":84,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":85,"sourceHtmlUrl":86},"references\u002Fapsm_decision_tree.md",3531,"https:\u002F\u002Fgithub.com\u002FAllanYiin\u002FAmon\u002Fblob\u002Fmain\u002Fsrc\u002Famon\u002Fresources\u002Fskills\u002Fvibe-coding-guidelines\u002Freferences\u002Fapsm_decision_tree.md",{"path":88,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":89,"sourceHtmlUrl":90},"references\u002Fauthentication.md",4149,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fexchanges\u002Fbinance-official-derivatives-trading-coin-futures\u002Freferences\u002Fauthentication.md",{"path":92,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":93,"sourceHtmlUrl":94},"references\u002Fdirectory_structure_recommendations.md",23381,"https:\u002F\u002Fgithub.com\u002FAllanYiin\u002FAmon\u002Fblob\u002Fmain\u002Fsrc\u002Famon\u002Fresources\u002Fskills\u002Fvibe-coding-guidelines\u002Freferences\u002Fdirectory_structure_recommendations.md",{"path":96,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":97,"sourceHtmlUrl":98},"references\u002Flinux_macos_platform_pitfalls.md",1052,"https:\u002F\u002Fgithub.com\u002FAllanYiin\u002FAmon\u002Fblob\u002Fmain\u002Fsrc\u002Famon\u002Fresources\u002Fskills\u002Fvibe-coding-guidelines\u002Freferences\u002Flinux_macos_platform_pitfalls.md",{"path":100,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":101,"sourceHtmlUrl":102},"references\u002Flinux_platform_pitfalls.md",2725,"https:\u002F\u002Fgithub.com\u002FAllanYiin\u002FAmon\u002Fblob\u002Fmain\u002Fsrc\u002Famon\u002Fresources\u002Fskills\u002Fvibe-coding-guidelines\u002Freferences\u002Flinux_platform_pitfalls.md",{"path":104,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":105,"sourceHtmlUrl":106},"references\u002Fmacos_platform_pitfalls.md",2631,"https:\u002F\u002Fgithub.com\u002FAllanYiin\u002FAmon\u002Fblob\u002Fmain\u002Fsrc\u002Famon\u002Fresources\u002Fskills\u002Fvibe-coding-guidelines\u002Freferences\u002Fmacos_platform_pitfalls.md",{"path":108,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":109,"sourceHtmlUrl":110},"references\u002Fopenai_nanobanana_guidelines.md",32537,"https:\u002F\u002Fgithub.com\u002FAllanYiin\u002FAmon\u002Fblob\u002Fmain\u002Fsrc\u002Famon\u002Fresources\u002Fskills\u002Fvibe-coding-guidelines\u002Freferences\u002Fopenai_nanobanana_guidelines.md",{"path":112,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":113,"sourceHtmlUrl":114},"references\u002Fquality_checklist.md",7020,"https:\u002F\u002Fgithub.com\u002FAllanYiin\u002FAmon\u002Fblob\u002Fmain\u002Fsrc\u002Famon\u002Fresources\u002Fskills\u002Fvibe-coding-guidelines\u002Freferences\u002Fquality_checklist.md",{"path":116,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":117,"sourceHtmlUrl":118},"references\u002Fusage_scene_decision_tree.md",6433,"https:\u002F\u002Fgithub.com\u002FAllanYiin\u002FAmon\u002Fblob\u002Fmain\u002Fsrc\u002Famon\u002Fresources\u002Fskills\u002Fvibe-coding-guidelines\u002Freferences\u002Fusage_scene_decision_tree.md",{"path":120,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":121,"sourceHtmlUrl":122},"references\u002Fwindows_platform_pitfalls.md",2432,"https:\u002F\u002Fgithub.com\u002FAllanYiin\u002FAmon\u002Fblob\u002Fmain\u002Fsrc\u002Famon\u002Fresources\u002Fskills\u002Fvibe-coding-guidelines\u002Freferences\u002Fwindows_platform_pitfalls.md",{"path":124,"resourceType":125,"resourceTypeDesc":126,"sizeBytes":127,"sourceHtmlUrl":128},"scripts\u002Fapsm_validate.py","SCRIPT","脚本",21314,"https:\u002F\u002Fgithub.com\u002FAllanYiin\u002FAmon\u002Fblob\u002Fmain\u002Fsrc\u002Famon\u002Fresources\u002Fskills\u002Fvibe-coding-guidelines\u002Fscripts\u002Fapsm_validate.py",{"path":130,"resourceType":125,"resourceTypeDesc":126,"sizeBytes":131,"sourceHtmlUrl":132},"scripts\u002Fexample.py",247,"https:\u002F\u002Fgithub.com\u002FAllanYiin\u002FAmon\u002Fblob\u002Fmain\u002Fsrc\u002Famon\u002Fresources\u002Fskills\u002Fvibe-coding-guidelines\u002Fscripts\u002Fexample.py",{"path":134,"resourceType":125,"resourceTypeDesc":126,"sizeBytes":135,"sourceHtmlUrl":136},"scripts\u002Fproject_launcher_linux.py",412,"https:\u002F\u002Fgithub.com\u002FAllanYiin\u002FAmon\u002Fblob\u002Fmain\u002Fsrc\u002Famon\u002Fresources\u002Fskills\u002Fvibe-coding-guidelines\u002Fscripts\u002Fproject_launcher_linux.py",{"path":138,"resourceType":125,"resourceTypeDesc":126,"sizeBytes":139,"sourceHtmlUrl":140},"scripts\u002Fproject_launcher_posix.py",2321,"https:\u002F\u002Fgithub.com\u002FAllanYiin\u002FAmon\u002Fblob\u002Fmain\u002Fsrc\u002Famon\u002Fresources\u002Fskills\u002Fvibe-coding-guidelines\u002Fscripts\u002Fproject_launcher_posix.py",{"path":142,"resourceType":125,"resourceTypeDesc":126,"sizeBytes":143,"sourceHtmlUrl":144},"scripts\u002Fproject_launcher.py",91768,"https:\u002F\u002Fgithub.com\u002FAllanYiin\u002FAmon\u002Fblob\u002Fmain\u002Fsrc\u002Famon\u002Fresources\u002Fskills\u002Fvibe-coding-guidelines\u002Fscripts\u002Fproject_launcher.py",{"path":146,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":147,"sourceHtmlUrl":148},"SOURCE.md",163,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fexchanges\u002Fbinance-official-derivatives-trading-coin-futures\u002FSOURCE.md",{"path":150,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":151,"sourceHtmlUrl":152},"TRUST.auto.yaml",2227,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fexchanges\u002Fbinance-official-derivatives-trading-coin-futures\u002FTRUST.auto.yaml",[154,172,186,196,208,223],{"skillNo":155,"name":156,"nameZh":6,"description":157,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":158,"categories":159,"keywords":163,"publishedAt":35},"01M6CEF0D1F0MXB64MZY8KK1JZ","web-search-strategy","當使用者要上網查資料、把模糊研究意圖拆成多輪搜尋查詢、限定網站或檔案類型、找官方來源，或改善 Google\u002FBing 搜尋品質時使用。將問題改寫成 2-5 組高辨識度查詢，結合 site、引號、排除詞、檔案類型、搜尋引擎切換、結果去重與二次搜尋，再整理可信來源、未解空缺與下一輪查詢方向。","https:\u002F\u002Fgithub.com\u002FAllanYiin\u002FAmon\u002Fblob\u002Fmain\u002Fsrc\u002Famon\u002Fresources\u002Fskills\u002Fweb-search-strategy\u002FSKILL.md",[160],{"categoryNo":161,"categoryName":162,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000021","资料检索与研究",[164,165,166,167,168,169,170,171,33],"web search strategy","strategy","web search","search","web","google","research","site",{"skillNo":173,"name":174,"nameZh":6,"description":175,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":176,"categories":177,"keywords":181,"publishedAt":35},"01M6CEETQDHJNZYSBD2KZVNCRB","spreadsheet-workflows","報表 xlsx（整理、公式、檢核）。當使用者需要建立、編輯或分析 Excel 試算表時使用。","https:\u002F\u002Fgithub.com\u002FAllanYiin\u002FAmon\u002Fblob\u002Fmain\u002Fsrc\u002Famon\u002Fresources\u002Fskills\u002Fspreadsheet-workflows\u002FSKILL.md",[178],{"categoryNo":179,"categoryName":180,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000004","电子表格",[182,183,184,185],"spreadsheet workflows","spreadsheet","workflows","xlsx",{"skillNo":187,"name":188,"nameZh":6,"description":189,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":190,"categories":191,"keywords":192,"publishedAt":35},"01M6CEES4D4BMVK6PEPBVAG2QN","spec-to-tasks","將一份需求規格拆成可執行任務（含驗收條件）。當使用者提供產品需求、功能規格或使用者故事時，將其分解成具體的開發任務。","https:\u002F\u002Fgithub.com\u002FAllanYiin\u002FAmon\u002Fblob\u002Fmain\u002Fsrc\u002Famon\u002Fresources\u002Fskills\u002Fspec-to-tasks\u002FSKILL.md",[],[193,194,195],"spec","spec to tasks","tasks",{"skillNo":197,"name":198,"nameZh":6,"description":199,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":200,"categories":201,"keywords":202,"publishedAt":35},"01M6CEEN8XPB8P1ZHVJQY3NS4K","spec-organizer","在使用者要把模糊想法整理成可開發 spec 時使用。常見觸發像「整理需求成 spec」「補驗收條件」「拆分階段開發計畫」。輸出技術規格、白話規格與可直接貼用於 Codex \u002F Claude Code 的分階段 instructions；不直接代替正式文件發布。","https:\u002F\u002Fgithub.com\u002FAllanYiin\u002FAmon\u002Fblob\u002Fmain\u002Fsrc\u002Famon\u002Fresources\u002Fskills\u002Fspec-organizer\u002FSKILL.md",[],[203,193,30,204,205,206,207,31,33],"spec organizer","codex","instructions","code","product",{"skillNo":209,"name":210,"nameZh":6,"description":211,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":212,"categories":213,"keywords":219,"publishedAt":35},"01M6CEEHH6F6NP5Y6GR438211H","slide-content-planner","當使用者要規劃投影片或簡報內容時使用。輸出逐頁大綱、關鍵訊息、證據需求、視覺重點與版面動線。","https:\u002F\u002Fgithub.com\u002FAllanYiin\u002FAmon\u002Fblob\u002Fmain\u002Fsrc\u002Famon\u002Fresources\u002Fskills\u002Fslide-content-planner\u002FSKILL.md",[214],{"categoryNo":215,"categoryName":216,"taxonomyType":217,"taxonomyTypeDesc":218},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[220,221,222],"slide content planner","content","planner",{"skillNo":224,"name":225,"nameZh":6,"description":226,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":227,"categories":228,"keywords":230,"publishedAt":35},"01M6CEEBTMDJ2ZR6PCPDHW1NRW","research-brief","網頁\u002F文件摘要、研究整理。當使用者需要對某個主題進行研究、收集資訊並生成摘要時使用。","https:\u002F\u002Fgithub.com\u002FAllanYiin\u002FAmon\u002Fblob\u002Fmain\u002Fsrc\u002Famon\u002Fresources\u002Fskills\u002Fresearch-brief\u002FSKILL.md",[229],{"categoryNo":161,"categoryName":162,"taxonomyType":20,"taxonomyTypeDesc":21},[170,231,232,233],"brief","research brief","生成"]