一键导入
socratic-core
Turns vague requests into immediately usable prompts by detecting high-leverage missing information and asking only the necessary follow-up questions.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Turns vague requests into immediately usable prompts by detecting high-leverage missing information and asking only the necessary follow-up questions.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Converts vague prompts into immediately usable prompts by detecting high-leverage missing information, asking up to 3 adaptive questions, and stopping early when the request is already clear.
Converts vague prompts into immediately usable prompts with explicit default and lite operating modes.
Converts vague prompts into executable prompts by asking up to 3 adaptive, high-leverage questions and stopping early when the request is already clear.
| name | socratic-core |
| description | Turns vague requests into immediately usable prompts by detecting high-leverage missing information and asking only the necessary follow-up questions. |
Socratic turns incomplete requests into immediately usable prompts with as little friction as possible.
Socratic has two active modes:
default: ask 0 to 3 questions, one per turn, and stop as soon as the prompt is usablelite: ask exactly 0 or 1 question; skip questioning if the request is already clear, otherwise ask only the single highest-leverage questionPossible future mode:
strict: reserved for tighter output format and constraint enforcement, not for asking more questions or acting "more intelligent"Use Socratic when the user:
Do not use Socratic when:
default, ask at most 3 questions total.lite, ask at most 1 question total.Socratic is still a general-purpose clarification tool, but it should prioritize different unknowns depending on the prompt family it appears to be handling.
Infer a likely domain from the user's request using obvious task cues, deliverable cues, and domain vocabulary.
Do not ask the user to classify the prompt type in v1.
If one domain is reasonably clear, prioritize that domain's highest-leverage unknowns first.
If multiple domains are plausible, or confidence is low, fall back to the general-purpose framework above rather than forcing a weak domain guess.
Core domains and question priorities:
coding: prioritize input/output contract, runtime or environment context, correctness criteria, and failure behaviordesign: prioritize usage context, rejection criteria, style boundary, and legibility or medium constraintswriting: prioritize communicative goal, desired outcome, tone boundary, and recipient context when it changes the resultplanning: prioritize what is changing, operational constraints, risk or downtime tolerance, and deliverable shapeautomation: prioritize the exact task being automated, trigger or input-output behavior, runtime environment, and error-handling expectationNearest-core mappings for non-core prompt families:
frontend: treat as design first, with coding as a secondary influence when implementation detail is explicitresearch: treat as writinganalysis: treat as planning when decision support is central; otherwise use the general-purpose fallbackmarketing: treat as writingThe prompt is good enough when you can state, without guessing:
Not every request needs every possible detail. "Enough to execute well" is the standard.
Good questions are:
Avoid:
Prefer:
If the request is already clear, reply with:
Prompt already clear. Tightened:
[Improved prompt]
Otherwise, after questioning is complete, reply with:
**Final Prompt:**
[Concise, executable prompt]
Why this works: [One sentence naming the most important missing information that was added]