원클릭으로
brainstorming
蘇格拉底式提問協議 + 使用者溝通。複雜請求、新功能或不明確需求時必須使用。包含進度報告和錯誤處理。
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
메뉴
蘇格拉底式提問協議 + 使用者溝通。複雜請求、新功能或不明確需求時必須使用。包含進度報告和錯誤處理。
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
使用 Claude API / Anthropic SDK 建構、除錯和最佳化應用程式。使用此技能建構的應用程式應包含提示快取 (prompt caching)。也處理在 Claude 模型版本之間遷移現有 Claude API 程式碼(4.5 → 4.6,4.6 → 4.7,替換已退役模型)。觸發時機:程式碼匯入 anthropic/@anthropic-ai/sdk;使用者要求使用 Claude API、Anthropic SDKs 或 Managed Agents (/v1/agents, /v1/sessions, /v1/environments);使用者在檔案中新增/修改/調整 Claude 功能(快取、思考、壓縮、工具使用、批次、檔案、引用、記憶)或模型(Opus/Sonnet/Haiku);關於 Anthropic SDK 專案中提示快取/快取命中率的問題。不觸發:檔案匯入 `openai`/其他提供者 SDK,檔案名稱類似 `*-openai.py`/`*-generic.py`,與提供者無關的程式碼,一般程式設計/機器學習。
當編寫呼叫 Gemini API 的程式碼時請使用此技能,用於文字生成、多輪對話、多模態理解、影像生成、串流回應、背景研究任務、函式呼叫、結構化輸出,或從舊的 generateContent API 遷移。此技能涵蓋 Interactions API,這是在 Python 與 TypeScript 中使用 Gemini 模型與代理的建議方式。
Tailwind CSS v4 原則。CSS 優先配置、容器查詢、現代模式、設計 token 架構。
處理使用 Gemini Live API 的即時、雙向串流應用程式時使用此技能。涵蓋基於 WebSocket 的音訊/視訊/文字串流、語音活動偵測 (VAD)、原生音訊功能、函式呼叫、會話管理、用戶端身分驗證的臨時權杖,以及所有 Live API 設定選項。涵蓋的 SDK - google-genai (Python)、@google/genai (JavaScript/TypeScript)。
Python 開發原則與決策。框架選擇、非同步模式、型別提示、專案結構。教你思考而非複製。
自動代理選擇與智慧任務路由。分析使用者請求並自動選擇最佳專家代理,無需使用者明確提及。
| name | brainstorming |
| description | 蘇格拉底式提問協議 + 使用者溝通。複雜請求、新功能或不明確需求時必須使用。包含進度報告和錯誤處理。 |
| allowed-tools | Read, Glob, Grep |
必須使用: 用於複雜/模糊請求、新功能、更新。
| 模式 | 動作 |
|---|---|
| 「建構/建立/製作 [東西]」但無細節 | 🛑 詢問 3 個問題 |
| 複雜功能或架構 | 🛑 實作前先澄清 |
| 更新/變更請求 | 🛑 確認範圍 |
| 模糊需求 | 🛑 詢問目的、使用者、限制 |
⛔ 絕不使用靜態範本。 閱讀 dynamic-questioning.md 了解原則。
| 原則 | 意義 |
|---|---|
| 問題揭示後果 | 每個問題連結到一個架構決策 |
| 情境先於內容 | 先了解全新/功能/重構/除錯的情境 |
| 最少可行問題 | 每個問題必須排除實作路徑 |
| 生成資料而非假設 | 不要猜測 — 帶著權衡來詢問 |
1. 解析請求 → 提取領域、功能、規模指標
2. 識別決策點 → 阻塞性 vs 可延遲的
3. 生成問題 → 優先順序:P0(阻塞)> P1(高槓桿)> P2(錦上添花)
4. 格式化與權衡 → 什麼、為什麼、選項、預設
### [優先順序] **[決策點]**
**問題:** [清晰的問題]
**為什麼重要:**
- [架構後果]
- [影響:成本/複雜度/時程/規模]
**選項:**
| 選項 | 優點 | 缺點 | 最適合 |
|------|------|------|--------|
| A | [+] | [-] | [使用案例] |
**若未指定:** [預設 + 理由]
詳細的領域特定問題庫和演算法,請參見:dynamic-questioning.md
原則: 透明度建立信任。狀態必須可見且可操作。
| 代理 | 狀態 | 當前任務 | 進度 |
|---|---|---|---|
| [代理名稱] | ✅🔄⏳❌⚠️ | [任務描述] | [% 或計數] |
| 圖示 | 意義 | 用途 |
|---|---|---|
| ✅ | 已完成 | 任務成功完成 |
| 🔄 | 執行中 | 目前正在執行 |
| ⏳ | 等待中 | 被阻塞,等待依賴 |
| ❌ | 錯誤 | 失敗,需要關注 |
| ⚠️ | 警告 | 潛在問題,未阻塞 |
原則: 錯誤是清晰溝通的機會。
1. 承認錯誤
2. 解釋發生了什麼(使用者友善)
3. 提供帶權衡的具體解決方案
4. 請使用者選擇或提供替代方案
| 類別 | 回應策略 |
|---|---|
| 埠口衝突 | 提供替代埠口或關閉現有的 |
| 缺少依賴 | 自動安裝或詢問許可 |
| 建構失敗 | 顯示具體錯誤 + 建議修復 |
| 不明確錯誤 | 要求具體資訊:截圖、控制台輸出 |
原則: 慶祝成功,引導下一步。
1. 成功確認(簡短慶祝)
2. 完成內容摘要(具體)
3. 如何驗證/測試(可操作)
4. 下一步建議(主動)
| 原則 | 實踐 |
|---|---|
| 簡潔 | 不要不必要的細節,直接切入重點 |
| 視覺化 | 使用表情符號(✅🔄⏳❌)方便快速瀏覽 |
| 具體 | 「~2 分鐘」而不是「稍等」 |
| 替代方案 | 卡住時提供多條路徑 |
| 主動 | 完成後建議下一步 |
| 反模式 | 原因 |
|---|---|
| 在理解前就跳到解決方案 | 浪費時間在錯誤的問題上 |
| 不詢問就假設需求 | 產生錯誤的輸出 |
| 第一版就過度設計 | 延遲價值交付 |
| 忽略限制 | 產生不可用的解決方案 |
| 「我認為」的說法 | 不確定 → 改為詢問 |