菜单
需求不明時的意圖萃取訪談：一次一題、每題附上自己的猜測、聽出「真正想要 vs 覺得應該要」，直到能預測使用者反應（約 95% 信心）才動工。適用：需求缺少對象 / 動機 / 成功標準 / 約束，或使用者點名「訪談我」「先確認一下」「我們確定嗎」。明確自足的指示、純資訊查詢、機械性操作不適用。
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/seikaikyo/dash-skills --skill interview-me命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
Use when reviewing code for security vulnerabilities, implementing authentication/authorization, handling user input, or discussing web application security. Covers OWASP Top 10:2025, ASVS 5.0, LLM Top 10 (2025), and Agentic AI security (2026).
Guides authoring of high-quality YARA-X detection rules for malware identification. Use when writing, reviewing, or optimizing YARA rules. Covers naming conventions, string selection, performance optimization, migration from legacy YARA, and false positive reduction. Triggers on: YARA, YARA-X, malware detection, threat hunting, IOC, signature, crx module, dex module.
Throwaway HTML mockups: 2-3 design variants to compare.
正在显示 SKILL.md
基于 SOC 职业分类
| name | interview-me |
| description | 需求不明時的意圖萃取訪談：一次一題、每題附上自己的猜測、聽出「真正想要 vs 覺得應該要」，直到能預測使用者反應（約 95% 信心）才動工。適用：需求缺少對象 / 動機 / 成功標準 / 約束，或使用者點名「訪談我」「先確認一下」「我們確定嗎」。明確自足的指示、純資訊查詢、機械性操作不適用。 |
| source | adapted from openclawyhwang-hub/tGD tgd-interview-me (Apache-2.0) |
| updated | "2026-07-13T00:00:00.000Z" |
人開口要的跟真正想要的是兩回事。說「做個儀表板」是因為大家都這樣講，不是因為儀表板解決他的問題。抓出這個落差最便宜的時機是在任何計畫、規格、程式碼存在之前；開工之後切換成本是真的，使用者會把錯的東西合理化成「還行」。
本 skill 是前置於 brainstorming 與規格撰寫的階段：一次問一題，每題附上自己的猜測，問到你能預測使用者接下來會說什麼為止。
不適用：指示明確自足（改名、修 typo）、使用者明說要快不要驗、純資訊查詢、機械性操作、你已有 95% 以上信心（先重讀下方停止條件再認定沒有）。
需要活的、能回話的使用者。非互動情境（CI、排程、autonomous loop）禁用；在那些情境遇到需求不明，標記為 blocker 呈報，不要用猜的。
問任何問題之前，先用一句話寫下你目前對需求的最佳解讀，加上誠實的信心數字：
假設：你要的是在 standup 回答「我們狀況如何」的方法，「儀表板」只是慣例式的講法
信心：約 30%。缺：給誰用、「指標」指什麼、成功長什麼樣
數字逼出誠實。信心低於約 70% 時，同一行附一句缺什麼，讓使用者知道訪談要補的是什麼。
問：<一個聚焦的問題>
猜：<你對答案的假設，以及推出這個假設的理由>
等使用者反應完才問下一題。一次一題的理由：問題塞成清單使用者只會掃讀；第三題常依賴第一題的答案，一次全問會鎖死錯的框架。附猜測的理由：對錯誤猜測做反應比從零生答案快；把你的假設攤在檯面上，這正是訪談要曝光的東西。
風險是客氣的使用者順著你的猜測附和。對策：明顯表現出願意猜錯，偶爾往預期會被打槍的方向猜。
最危險的答案是聽起來很得體的那種。警訊：
聽到這些就問：
「如果不用向任何人交代，你實際上想要的是什麼？」
這一題常比前五題加起來有用。
信心夠高時，把你認為的需求寫回去，5 到 8 行，讓使用者能逐行確認或修正：
我現在認為你要的是：
- 結果： <一行>
- 使用者： <一行，誰受益>
- 為什麼現在：<一行，什麼變了>
- 成功標準： <一行，怎麼知道做對了>
- 約束： <一行，綁死的限制>
- 不做什麼： <一行，明確排除的範圍>
可以 / 不對 / 要修？
「不做什麼」那行不可省：一半的認知錯位是對「不建什麼」的沉默歧見。
以下都不算確認：
被修正就吸收修正、重新複述，迴圈到拿到明確的「可以」為止。
自問：接下來要問的三題，我能預測使用者的反應嗎？能，代表有共同理解，停止訪談、產出複述。不能，就問下一題。這是可檢核的測試，不是感覺。地板：問了好幾輪還是無法預測，這是關於需求本身的資訊。停下來說：「我問了 X 題還是無法預測你的反應，有根本的東西缺了，要不要退一步？」
確認過的意圖陳述（Step 4 的複述 + Step 5 的明確 yes），對話形式即可，不落檔。下游：具體需求走 OpenSpec 提案（openspec/changes/），方案推敲走 superpowers brainstorming，兩者都以確認過的意圖為輸入，不是以原始的模糊需求為輸入。