Stats
Actions
Tags
From dev
Extracts what the user actually wants and refines vague ideas into sharp, actionable concepts. Achieves this through one-question-at-a-time interview until ~95% confidence about the underlying intent, then applies structured divergent/convergent thinking if the idea needs refining. Use when an ask is underspecified ("build me X" without "for whom" or "why now"), when the user wants to ideate or refine a concept ("ideate", "refine this idea", "stress-test my plan"), when the user explicitly invokes ("interview me", "grill me", "are we sure?"), or when you catch yourself silently filling in ambiguous requirements before any plan, spec, or code exists.
How this skill is triggered — by the user, by Claude, or both
Slash command
/dev:interview-meThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
人们说出来的需求和真正的需求是两回事。他们要"一个 dashboard"是因为这是约定俗成的说法，而不是因为 dashboard 能解决他们的问题。他们说"让它更快"但没有量化指标。
人们说出来的需求和真正的需求是两回事。他们要"一个 dashboard"是因为这是约定俗成的说法，而不是因为 dashboard 能解决他们的问题。他们说"让它更快"但没有量化指标。
捕捉这个差距最便宜的时机是在任何 plan、spec 或代码存在之前。一旦开始构建，切换成本是真实存在的，用户会把错误的东西合理化"够好了"。不匹配就此锁定。
本 Skill 在造成任何损失之前关闭这个差距。Interview-me 提取真实意图；如果意图仍然模糊（"我想要类似..."但没有具体形态）， Skill 接着应用结构化发散/收敛思维来生成和压力测试方案，然后再交接给 spec-driven-development。
以下情况适用本 Skill ：
何时不使用：
在问任何问题之前，用一句话写下你当前对用户需求的最佳解读，加上诚实的置信度数字（0–100%）：
假设（HYPOTHESIS）：你想要一种在站会上回答"我们做得怎么样？"的方式，"dashboard"只是最先想到的约定说法。
置信度（CONFIDENCE）：~30% — 缺失：为谁做、"指标"在上下文中指什么、以及成功的标准是什么
数字强制诚实。如果你写了一个高数字但实际上无法预测用户对接下来的三个问题的反应，这个数字就是错的。从你能捍卫的置信度水平开始。
当置信度低于 ~70% 时，在同一行附上简短原因——什么仍未解决或缺失。这告诉用户访谈需要揭示什么，并防止数字成为模糊信号。
格式：
Q: <一个聚焦的问题>
GUESS: <你对答案的假设，以及产生该假设的推理>
等待用户反应后再问下一个问题。
为什么一次一个，而非批量：
为什么要附带猜测：
风险是礼貌的用户同意你的猜测以显得配合。通过明显愿意出错来缓解，偶尔猜测一个你预期用户会反驳的方向。
最危险的答案是用户说出深思熟虑的答案听起来像什么而非他们真正想要什么。注意：
当你听到这些时，问：
"如果你不需要向任何人解释理由，你真正想要的是什么？"
这一个问题往往比前五个更有用。
当你的置信度很高时，写回你现在认为用户想要什么。保持紧凑（5–8 行），尽可能使用他们的语言，结构化以便用户逐行确认或纠正：
以下是我现在认为你想要的：
- 成果： <一行>
- 用户： <一行——谁受益>
- 为什么现在： <一行——什么变了>
- 成功标准： <一行——如何知道它成功了>
- 约束： <一行——硬性限制>
- 排除范围： <一行——明确不做什么>
是 / 否 / 需要调整？
包含"排除范围"是不可协商的。一半的对齐失败是关于什么不应该被构建的无声分歧。
门槛是明确的"是"。以下不是是：
如果他们纠正你，纳入纠正并重新陈述。循环直到得到明确的是。
当你对以下问题能回答是时，就完成了：
我能预测用户对接下来的三个问题的反应吗？
如果是的，你们已经有了共同理解。停止访谈并产出重述。如果不是，你还没完成；问下一个问题。
这是一个可验证的测试，不是感觉。它也有底线：如果你已经进行了多轮仍无法预测，这本身就是关于需求的信息，而非继续追问的理由。停下来告诉用户："我已经问了 X 个问题但仍无法预测你的反应。一些基础性的东西缺失了。想退一步重新梳理吗？"
当确认的意图是"我想要类似 X 但不知道应该是什么形态"时，应用结构化发散→收敛思维来生成和缩小选项。
此步骤适用条件：
发散阶段——生成选项（2–4 个变体）：
对每个变体提供：
收敛阶段——压力测试和缩小范围：
对每个选项应用精炼标准：
呈现前 1–2 个选项，附推荐和背后的推理。用户选择；不要替他们选择。
示例：
意图确认：个人实验追踪器。三种可行的形态：
选项 A — Markdown 文件 + git hook
→ 最适合：单人开发，零配置，版本受控
→ Trade-off：无搜索，无可视化
→ 反信号：你需要图表或需要与团队共享
选项 B — 本地 SQLite + CLI
→ 最适合：可查询、可脚本化、私密
→ Trade-off：你自己构建 UI
→ 反信号：你想要 web 界面
选项 C — 轻量 Web 应用（SQLite + htmx）
→ 最适合：web 访问，简单可视化，仍为本地
→ Trade-off：配置工作最多
→ 反信号：你需要今天完成
推荐：选项 A 或 B。你的核心需求是一个列表，而非 dashboard。
选项 C 增加了你所述需求不合理的 UI 复杂度。
本 Skill 的输出是一份确认的意图陈述：第 4 步的重述加上第 5 步的明确"是"。这就是交付物。Spec、plan 和 task list 是下游产物；它们消费本 Skill 产生的意图。
如果用户希望意图持久化（多 session 项目、交接给其他协作者），提议保存到 docs/intent/[topic].md。仅在确认后保存。
简短的对比。
没有 interview-me：
用户： 给我构建一个我们的指标的 dashboard
Agent： <开始提议图表库和布局>
Agent 已经假设：为谁做、什么指标、"我们的团队"是什么意思、成功的样子是什么。这些都未说明。每一个假设都是用户以后可能说"那不是我的意思"的地方。
用了 interview-me：
用户：给我构建一个我们的指标的 dashboard
Agent：
假设：你想要一种在站会上回答"我们做得怎么样？"的方式，"dashboard"只是因为这是约定的说法才想到的。
置信度：~30% — 缺失：为谁做、什么"指标"、成功的样子是什么
Q: 当你说"我们做得怎么样？"，谁在问——你一个人、工程团队在站会上、还是向上级（经理、高管、董事会）？
GUESS：工程团队在站会上，因为"我们"通常是这样用的，站会是这个问题被提出的场景。如果是给高管看，指标和框架会有很大不同。
用户：其实是为我自己。我总是不知道哪些实验在跑，它们的早期信号是什么样的。
Agent：
更新解读：根本不是团队 dashboard。是个人实验追踪器。置信度：~60% — 仍缺失："早期信号"指什么、完成的样子是什么。
Q: 你的问题是不知道哪些实验存在，还是无法在一个地方看到它们的结果？
GUESS：第二个。你可能在各处有实验列表，但结果分散在五个不同的工具里，手工协调让你很疲惫。
用户：其实是第一个。我根本没有列表。它们分散在不同的文档里。
Agent：<继续>
两个问题之后，Agent 已经发现实际的需求不是"dashboard"，而是"列表"。不同的产物、不同的范围、不同的工作量。Dashboard 会是错误的。
spec-driven-development：下游。一旦意图具体且方案确定（第 6 步完成或跳过），交接给 spec-driven-development 编写正式的 spec。planning-and-task-breakdown：隔一个 hops 的下游（在 spec 之后）。应用 interview-me 后：
npx claudepluginhub dogemassaji/cc-plugins-marketplace --plugin devProvides CDSS development patterns for drug interaction checking, dose validation, clinical scoring (NEWS2, qSOFA), and alert classification integrated into EMR workflows.