用途
on-the-spot 用于在编写规格或开始实现之前，把含糊的功能请求转化为一组显式决策。核心原则是：提问，不实现；没有答案就不开始写规格。
主要能力
- 在第一个问题之前先阅读该功能涉及的代码，包括入口点、数据模型、配置、测试和 AGENTS.md 等文档，使问题建立在真实代码之上。
- 搜索该功能或其部分是否已经存在，并在第一个问题前告知用户搜索结果。
- 把用户可能不知道的事实写入问题文本，例如指出导入脚本会先删除所有订单再加载文件，并询问是否应保留。
- 每轮最多提出四个问题，环境中有提问工具则使用，否则在聊天中提问。
- 每个问题提供 2 至 4 个选项，推荐选项排在最前并标记“(Recommended)”，每个选项附一行取舍说明；选项不互斥时允许多选。
- 仔细阅读自由文本回答，因为其中常会改变方向、增加未提供的选项或要求停止。
使用方式
按从基础到细节的顺序组织轮次，不适用的主题跳过：
- 基础：解决方案形式、范围、数据事实来源、用户与角色。
- 安全与访问：谁可以做什么、认证、会话、密钥、滥用限制。
- 界面与结构：渲染、样式、路由、模块布局。
- 行为细节：ID、删除、验证规则、列表、过滤器、消息。
- 运维：CLI、安装脚本、配置、界面与文档语言、反馈消息。
- 交付：测试、文档、OpenAPI、分支与提交策略。
持续提问，直到无需猜测即可写出规格。两个完成信号：下一个问题只会确认默认值；摘要中的每个决策都有归属（用户或显式推荐的默认值）。
最后一轮之后：按主题分组，用用户的语言写出所有决策摘要；列出由默认值决定且仍需确认的细节；把摘要保存到 .scratchpad/<slug>/interview-decisions.md；询问用户是先看原型（prototype-options，当结果具有用户可查看的形态时）还是继续写规格（write-acceptance-spec）。
适用场景
适合在功能需求尚不明确、需要先对齐范围与实现决策时使用，尤其适用于涉及现有代码库的功能开发前置沟通。
限制
资料未提供该技能的具体安装方式、支持的平台、收费信息或效果数据，这些内容暂未提供。