gws-drive
作者 googleworkspacegws-drive 是 Google Workspace CLI 的 Google Drive 技能。可用來管理檔案、資料夾、共用雲端硬碟、存取提案，以及各種以 API 驅動的 Drive 工作流程，減少猜測與反覆試錯。它很適合後端開發、自動化，以及需要可重複執行的命令列任務。
這個技能評分 78/100，屬於相當穩健的清單候選：目錄使用者多半可用 `gws drive <resource> <method> [flags]` 這個模式觸發它，並取得實際的 Google Drive 工作流程支援。不過，驗證與規則仍大多要仰賴更上層的 `gws-shared` 前置技能。內容的完整度足以支撐安裝決策，但又還不到新手能直接上手、開箱即用的程度。
- 作業範圍扎實：涵蓋 Google Drive 在 about、accessproposals 與多個 Drive API 方法上的管理，不只是狹窄的示範。
- 觸發性不錯：明確的命令格式、有效的 frontmatter，以及可回溯到倉庫的說明參考（`gws drive --help`），都讓代理更容易正確呼叫。
- 漸進式揭露有實用性：有輔助命令連到上傳相關指引，正文也包含部分操作的 API 層級說明與限制。
- SKILL.md 沒有安裝指令，也沒有支援檔案或腳本，因此設定與執行會依賴外部倉庫脈絡與共用前置技能。
- 這個技能偏向 API 方法導向，而不是任務劇本導向，對端到端使用者工作流程來說，代理可能還是得自己補一些判斷。
gws-drive 技能概覽
gws-drive 的用途
gws-drive 是 Google Workspace CLI 的 Google Drive 技能。它能讓你從命令列管理檔案、資料夾、共用雲端硬碟，以及相關的 Drive API 工作流程，並提供技能層級的指引，避免你在資源名稱、必要欄位與權限限制上靠猜。
適合哪些人使用
如果你在後端開發、自動化或維運工作中，需要在腳本或 agent 工作流程裡重複執行 Drive 操作，gws-drive 技能就很適合你。當你想用 CLI 驅動的流程處理 Drive 任務，而不是一次性的提示詞，尤其是上傳、需要理解中繼資料的操作，以及以 API 為基礎的查詢時，它特別有用。
安裝前最重要的事
gws-drive 的核心價值不在於功能廣度，而在於穩定性：它會把 agent 導向正確的 Drive 資源與正確的 request 形狀。最大的導入阻礙通常是驗證與共用設定，因為這個技能仰賴更大的 gws 環境，以及 gws-shared 裡關於旗標與安全規則的共用說明。
如何使用 gws-drive 技能
安裝與前置條件檢查
先在 Google Workspace CLI 的情境中安裝 gws-drive 技能，然後先確認共用前置條件：../gws-shared/SKILL.md。技能中繼資料也預期系統可用 gws binary，所以在開始任何 Drive 工作流程前，先確認 CLI 可以正常運作。實務上的安裝路徑是：設定完成後先讀 gws drive --help，再把內容和技能中的資源清單比對。
先從正確的輸入形式開始
gws-drive 的使用模式是 gws drive <resource> <method> [flags]，所以你的提示詞應該明確寫出目標資源、動作，以及精確的輸出限制。好的輸入像這樣：「列出我可存取的共用雲端硬碟，只回傳 name 和 id，並排除垃圾桶中的項目。」不好的輸入像這樣：「檢查 Drive。」如果你是為後端開發使用 gws-drive 指南，請一開始就提供識別碼、父資料夾，以及任何權限或 scope 假設。
先讀這些檔案
先從 SKILL.md 開始，再查看 ../gws-shared/SKILL.md，因為驗證、全域旗標與安全行為都由它管。這段 repo 範圍裡沒有可依賴的 helper scripts 或支援資料夾，所以技能檔本身就是最主要的準則來源。請特別留意 API resource 區塊與 helper command +upload，因為它們展示的是預期流程，而不是要你從一般性的 Drive 文件自行推斷。
能帶來更好結果的工作流程
建議採用三步驟：先定義資源，再縮小方法範圍，最後只加上會影響 API response 的旗標。例如，若要抓取 Drive 帳戶資訊，請明確提到 about.get 需要 fields；而與上傳相關的工作，則應在你想要自動帶出中繼資料時改走 helper command。這就是 gws-drive 最重要的使用紀律：請求最小但足夠的回應，而不是盡可能最大的回應。
gws-drive 技能 FAQ
gws-drive 只適合 Drive 基礎操作嗎？
不是。gws-drive 不只涵蓋核心 Drive 資源，也涵蓋自動化情境中很重要的特定 API 行為，例如 about.get 需要 fields，以及只允許 approver 的 access proposal 處理限制。這使它比一般提示詞更適合用在你需要正確 API 形狀，而不只是一般 Drive 說明的情境。
什麼時候不該用這個技能？
如果你只需要手動、一次性的 Drive 小技巧，或是你還沒準備好 gws CLI 與共用驗證設定，就先不要用 gws-drive 技能。當你的任務根本不在 Drive 操作範圍內時，它也不是好選擇，因為這個技能是為 request 建構與 CLI 執行而優化，不是為一般 Workspace 建議而設計。
這個技能適合新手嗎？
適合，只要你能描述一個具體的 Drive 目標。這個技能會透過資源－方法模式與關鍵注意事項來減少猜測，但新手仍然需要提供目標檔案、資料夾、共用雲端硬碟或權限情境。沒有這些資訊，agent 可能只會產出過於空泛的命令，或選到過於寬泛的 API 呼叫。
和一般提示詞最大的差別是什麼？
一般提示詞可能只會解釋 Drive 概念；gws-drive 則提供以實際 CLI 與 API 資源為基礎的工作流程。當你需要可預測的命令、合法的欄位選擇，或不能在第一次執行就失敗的權限感知操作時，這個差異就很重要。
如何改進 gws-drive 技能
給 agent 精確的 Drive 情境
最好的結果來自於在一句話裡同時說清楚資源、動作與範圍。範例：「使用 gws-drive 列出資料夾 abc123 裡的檔案，回傳 id、name、mimeType 和 modifiedTime，且不要包含已刪除項目。」這比只說「找文件」強得多，因為它能降低搜尋歧義，也能避免不必要的 API 輸出。
說明會改變 API 呼叫的限制條件
請明確指出你是否需要共用雲端硬碟、特定資料夾、access proposal，或帳戶層級資訊。對 gws-drive 而言，這些細節很重要，因為不同資源對權限與 response 的要求不同。如果你省略它們，第一次輸出常會因為缺少 fields、缺少 approver 存取權，或查詢範圍過大而失敗。
從命令到結果逐步迭代
如果第一次輸出太寬泛，就把可選輸出拿掉，並加入你在意的精確識別碼來收斂請求。如果失敗，先檢查問題是否出在驗證、gws-shared 裡缺少前置條件，或 resource-method 配對不正確。最快的 gws-drive 指南流程，是先修正命令形狀，再調整任務本身。