API 測試（英文） 是做什麼的？
中文版： 請參考對應的中文技能。
使用時機
- 需要 API 測試計畫、API 案例或 API 風險分析。
- 請求涉及 REST、GraphQL、SOAP、gRPC、WebSocket 或混合 API 行為。
工作流程
- 閱讀並遵循「漸進式揭露」下方列出的主要提示（涵蓋範圍、結構、品質標準）。
- 僅添加會改變結果的專案情境：範圍、環境、限制、風險、依賴關係、預期交付項目。
- 若輸入不完整，請回傳可用的初稿，並明確標示假設與缺口。
- 預設使用 Markdown；僅在使用者要求時才切換格式。
核心限制
- 根據風險／業務影響進行優先排序——不要對所有項目一視同仁。
- 將已確認的事實與當前假設分開。
- 不要憑空創造使用者未提供的端點、欄位、環境或根本原因。
- 保持輸出可執行：具體的情境、清晰的優先級、明確的下一步。
漸進式揭露
- 在產出之前，閱讀並遵循
prompts/api-testing.md（最低涵蓋範圍、輸出結構、品質標準）。 - 當要求 Excel/CSV/JSON/Word 格式時：閱讀
output-formats.md並遵循該格式。 - 當有現成模板可用時：使用
output-templates/下匹配的檔案。 - 對於深入的框架／故障排除／架構筆記：僅閱讀
references/下相關的檔案，不要載入整個目錄。 - 對於格式轉換或輔助檢查：優先使用現有的
scripts/，而不是重新發明。 - 若要評估／回歸此技能：搭配 skill-up 使用
evals/。
交付前檢查清單
- 遵循了主要提示的輸出結構
- 最低涵蓋範圍聚焦於：範圍內的端點或業務流程、優先級與風險等級、正向情境、負向情境、邊界情境、認證與權限檢查、請求和回應驗證、錯誤處理……（詳細內容請見主要提示）
- 涵蓋了最低檢查清單，或說明了遺漏的原因
- 高風險項目已明確標示優先級
- 未憑空創造使用者未提供的細節
- 假設與缺口已標示
常見陷阱
- 當範圍／情境缺失時，不要假裝完整。
- 不要將每個項目都視為同等重要。
- 不要跳過假設與資訊缺口。
- 不要傾瀉與當前工具鏈無關的通用理論。