Menu
苏格拉底式深度访谈，用数学化的模糊度评分来澄清需求。适用于模糊的想法、不确定的需求、需要暴露隐藏假设的场景。触发词："deep interview"、"深度访谈"、"需求澄清"、"帮我理清思路"、"不知道要做什么"。
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
Nop项目Git专家 - 智能提交、Rebase、历史搜索（基于项目风格固化）
涉及git worktree的操作优先使用这个skill。管理 Git bare 仓库和多个并行 worktree 的开发环境。支持初始化 bare 仓库结构、自动生成分支名并创建 feature worktree。
Node.js 后端服务技术架构设计。基于 NestJS + Prisma + SQLite 的原型开发规范，支持快速原型开发和未来迁移到 Java。触发词：Node.js 后端、NestJS、Prisma、后端架构、API 设计。
(opencode-project - Skill) Nop平台数据库设计规范。定义表命名、列命名、主键设计、索引设计、通用字段、域定义、关系设计等规范。触发词：数据库设计、表设计、DDL、ORM模型、字段命名。
使用 nop-cli gen 命令从 ORM 模型文件生成 Nop 平台初始项目脚手架（仅初次生成）。生成后通过 mvn install 迭代。触发词：代码生成、gen、生成项目、脚手架、初始化项目。
Generate, validate, and modify Nop ORM models from MySQL DDL/SQL or business requirements. Covers entity modeling, relationships, domains, dictionaries, displayName localization, and ORM file organization (Delta mode). Use for database-first or requirements-first ORM development.
| name | deep-interview |
| description | 苏格拉底式深度访谈，用数学化的模糊度评分来澄清需求。适用于模糊的想法、不确定的需求、需要暴露隐藏假设的场景。触发词："deep interview"、"深度访谈"、"需求澄清"、"帮我理清思路"、"不知道要做什么"。 |
本 skill 的核心目标是在写代码之前，通过苏格拉底式提问帮助用户澄清模糊的需求和想法。
核心原则：
当你的需求涉及以下场景时，请加载此 skill：
| 场景 | 触发关键词 | 示例 |
|---|---|---|
| 模糊的想法 | "我有个想法"、"想做xxx" | "我想做一个任务管理应用" |
| 不确定的需求 | "不太确定"、"可能需要" | "需要一个API，但不确定具体功能" |
| 需要暴露假设 | "不要假设"、"确保理解" | "别假设，问清楚再开始" |
| 避免返工 | "不想做错"、"先理清" | "帮我理清思路，避免做错" |
| 复杂到不能直接动手 | 复杂任务、多模块 | "重构整个认证系统" |
| 场景 | 原因 | 替代方案 |
|---|---|---|
| 明确的文件/函数修改 | 需求清晰，直接执行 | 直接开始实现 |
| 快速小改动 | 单一明确任务 | 直接执行 |
| 用户说"直接做" | 尊重用户意愿 | 直接执行 |
| 已有详细规格文档 | 需求已清晰 | 基于文档执行 |
通过迭代提问，对每个维度进行评分（0.0 - 1.0）：
| 维度 | 权重（新项目） | 权重（现有项目） | 评分标准 |
|---|---|---|---|
| 目标清晰度 (Goal Clarity) | 40% | 35% | 能否一句话说清目标？ |
| 约束清晰度 (Constraint Clarity) | 30% | 25% | 边界、限制、非目标是否明确？ |
| 成功标准 (Success Criteria) | 30% | 25% | 能否写出可测试的验收标准？ |
| 上下文清晰度 (Context Clarity) | N/A | 15% | 是否理解现有系统？ |
新项目: ambiguity = 1 - (目标×0.40 + 约束×0.30 + 成功标准×0.30)
现有项目: ambiguity = 1 - (目标×0.35 + 约束×0.25 + 成功标准×0.25 + 上下文×0.15)
目标：模糊度 ≤ 20% 才进入执行阶段
explore agent 探索相关代码区域> 开始深度访谈。我会通过针对性提问来彻底理解你的想法。
> 每次回答后，我会展示你的清晰度评分。
> 当模糊度降到 20% 以下时，我们就可以开始执行了。
>
> **你的想法**: "{初始想法}"
> **项目类型**: {新项目|现有项目}
> **当前模糊度**: 100%（还没开始）
重复直到 模糊度 ≤ 20% 或用户选择提前退出：
问题目标策略：
各维度问题风格：
| 维度 | 问题风格 | 示例 |
|---|---|---|
| 目标清晰度 | "具体来说，当...时会发生什么？" | "你说'管理任务'，用户第一个具体操作是什么？" |
| 约束清晰度 | "边界在哪里？" | "这个需要离线工作吗？还是假设有网络？" |
| 成功标准 | "怎么知道它工作了？" | "如果我给你看完成的产品，什么会让你说'对，就是这个'？" |
| 上下文清晰度 | "这怎么融入现有系统？" | "现有认证用的是 JWT，我们应该扩展它还是新建一个流程？" |
每次只问一个问题，不要批量提问。格式：
Round {n} | 针对: {最弱维度} | 模糊度: {score}%
{问题}
选项：
1. {选项A}
2. {选项B}
3. 其他（自由输入）
使用 question 工具让用户选择。
收到用户回答后，对每个维度评分：
评分提示词（使用高质量模型，temperature 0.1）：
根据以下访谈记录，对每个维度评分（0.0-1.0）：
原始想法: {idea}
访谈记录:
{所有轮次的Q&A}
评分维度：
1. 目标清晰度 (0.0-1.0): 主要目标是否明确？能否一句话说清且无歧义？
2. 约束清晰度 (0.0-1.0): 边界、限制、非目标是否清晰？
3. 成功标准清晰度 (0.0-1.0): 能否写出测试来验证成功？验收标准是否具体？
4. 上下文清晰度 (0.0-1.0) [仅现有项目]: 是否充分理解现有系统以便安全修改？
对每个维度提供：
- score: float (0.0-1.0)
- justification: 一句话解释评分
- gap: 还有什么不清楚（如果 score < 0.9）
以 JSON 格式回复。
Round {n} 完成。
| 维度 | 评分 | 权重 | 加权分 | 差距 |
|------|------|------|--------|------|
| 目标 | {s} | {w} | {s*w} | {gap 或 "清晰"} |
| 约束 | {s} | {w} | {s*w} | {gap 或 "清晰"} |
| 成功标准 | {s} | {w} | {s*w} | {gap 或 "清晰"} |
| 上下文（现有项目）| {s} | {w} | {s*w} | {gap 或 "清晰"} |
| **模糊度** | | | **{score}%** | |
{score <= 20% ? "清晰度达标！可以开始执行。" : "下一问题针对: {最弱维度}"}
在特定轮次，转换提问视角：
| 模式 | 激活时机 | 目的 | 示例问题 |
|---|---|---|---|
| 反驳者 (Contrarian) | Round 4+ | 挑战核心假设 | "如果相反的情况是真的呢？这个约束真的存在吗？" |
| 简化者 (Simplifier) | Round 6+ | 去除不必要复杂度 | "最简单的可用版本是什么？哪些约束其实是假设？" |
| 本质论者 (Ontologist) | Round 8+ (模糊度>30%) | 重新定义问题本质 | "这到底是什么？用一句话向同事描述会怎么说？" |
每种模式只使用一次，然后恢复正常苏格拉底式提问。
当模糊度 ≤ 20%（或用户选择提前退出）：
规格结构：
# 需求规格: {标题}
## 元信息
- 访谈轮次: {count}
- 最终模糊度: {score}%
- 项目类型: 新项目 | 现有项目
- 状态: {通过 | 提前退出}
## 清晰度分解
| 维度 | 评分 | 权重 | 加权分 |
|------|------|------|--------|
| 目标清晰度 | {s} | {w} | {s*w} |
| 约束清晰度 | {s} | {w} | {s*w} |
| 成功标准 | {s} | {w} | {s*w} |
| **总清晰度** | | | **{total}** |
| **模糊度** | | | **{1-total}** |
## 目标
{从访谈中得出的清晰目标陈述}
## 约束
- {约束 1}
- {约束 2}
- ...
## 非目标
- {明确排除的范围 1}
- {明确排除的范围 2}
## 验收标准
- [ ] {可测试的标准 1}
- [ ] {可测试的标准 2}
- [ ] {可测试的标准 3}
- ...
## 暴露的假设
| 假设 | 挑战 | 决定 |
|------|------|------|
| {假设} | {如何被质疑} | {最终决定} |
## 技术上下文
{现有项目: 相关代码发现}
{新项目: 技术选择和约束}
## 核心实体
| 实体 | 字段 | 关系 |
|------|------|------|
| {实体} | {字段1, 字段2} | {关联到...} |
## 访谈记录
<details>
<summary>完整Q&A ({n} 轮)</summary>
### Round 1
**Q:** {问题}
**A:** {回答}
**模糊度:** {score}%
...
</details>
规格生成后，询问用户如何继续：
你的需求规格已准备好（模糊度: {score}%）。你想如何继续？
1. **开始实现** - 基于规格直接开始编码
2. **先做技术设计** - 先输出技术设计方案，再实现
3. **继续澄清** - 继续访谈以进一步降低模糊度（当前: {score}%）
4. **保存规格** - 将规格保存到文件，稍后再处理
explore agent 探索代码库针对最弱维度：
评分: 目标=0.9, 约束=0.4, 成功标准=0.7
下一问题针对约束（最低 0.4）:
"你提到这个需要'在移动端工作'。这意味着原生App、
响应式网页、还是PWA？需要支持哪些具体的设备或系统版本？"
先探索再问：
[启动 explore agent: "查找认证实现"]
[收到: "认证在 src/auth/ 使用 JWT 和 passport.js"]
问题: "我看到项目使用 JWT 认证和 passport.js 在 src/auth/。
对于这个新功能，我们应该扩展现有认证中间件还是
创建一个单独的认证流程？"
挑战模式：
Round 5 | 反驳者模式 | 模糊度: 42%
你说这需要支持10,000并发用户。如果只需要处理100个呢？
架构会有根本变化吗，还是这个10K数字只是一个假设
而不是实测的需求？
批量提问：
"目标用户是谁？用什么技术栈？认证怎么处理？
还有，部署目标是什么？"
→ 错误：四个问题同时问，导致浅层回答
问代码库已有的信息：
"你的项目用什么数据库？"
→ 错误：应该先用 explore agent 查找
模糊度高时继续执行：
"模糊度45%但已经5轮了，开始做吧。"
→ 错误：45%意味着近一半需求不清晰
| 范围 | 含义 | 行动 |
|---|---|---|
| 0-10% | 水晶般清晰 | 立即执行 |
| 10-20% | 足够清晰 | 执行（默认阈值） |
| 20-40% | 有一些差距 | 继续访谈 |
| 40-60% | 显著差距 | 聚焦最弱维度 |
| 60-80% | 非常不清晰 | 可能需要重构问题（本质论者模式） |
| 80-100% | 几乎一无所知 | 早期阶段，继续 |
nop-orm-modeler 生成 ORM 模型nop-codegen-master 生成项目脚手架question 工具进行用户问答task(subagent_type="explore") 探索现有代码库