关于 research-scoping
research-scoping 是一项技能，可在启动完整研究前梳理问题的视角、分歧和答案结构。它只用单个上下文，不检索资料、不引用来源，也不调用子 Agent。
主要功能
- 01单轮梳理问题视角
- 02识别可能的分歧
- 03勾勒完整答案结构
- 04判断就地处理或升级
- 05标记待核实的主张
适用场景
- 01委托研究前界定宽泛问题
- 02判断是否升级到 /ann
- 03为证据收集整理问题
- 04找出需要核实的主张
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/research-scoping确认已加载。
详细介绍
研究范围界定
在你决定是否为某个问题投入真正的 Token 之前，先用一次单上下文分诊梳理问题。这项技能将 Stanford 的 STORM 方法中的多视角步骤压缩到一个提示词中：找出问题所需的视角，揭示这些视角之间的冲突，勾勒完整答案的结构，然后判断是直接处理还是升级处理。它不检索任何内容，也不引用任何资料。输出是一份地图和计划，以待探究的问题来呈现，而不是答案。
它兼具经济和分析价值。完整的 COMPLEX /ann 运行会消耗数十万个 Token；这一步只需在一个上下文中花费其中一小部分，也不会分派子 Agent。因此，它要么省去大型运行，要么让专家名单更精准，使大型运行更有针对性。
适用范围——何时使用这项技能，而非其他技能
- research-scoping（本技能）：用一次低成本运行梳理问题的各种视角与冲突，然后进行分诊。不检索、不引用、不调用子 Agent，也不交付成果。
- /grill-mel：一次提出一个问题，采访 Ane，以完善她已有的设计。research-scoping 则反其道而行：不采访 Ane，而是向她提供一份地图。
- /ann：完整编排并产出交付成果。research-scoping 是你在决定是否启动它之前要经过的入口。
- /researcher、/evidence-synthesis：检索并引用真实来源。research-scoping 从不这样做；如果问题需要证据，它会将问题交给这些技能。
- /decision-debate：围绕一个有争议的决策展开 Token 密集型多 Agent 辩论。research-scoping 只用一个上下文，不会启动任何 Agent。
如果问题显然需要交付成果，就跳过范围界定，直接使用 /ann 或合适的构建工具。
从设计上确保诚实的规则
这项技能绝不能输出引用，也绝不能断言任何关于 IPPF、MA、合作伙伴、联系人、数字或日期的事实。它提出的所有内容都只是有待核实的假设，这是设计要求。快速生成一份未经来源支持、却看似权威的地图，正是整个 MEL 系统要防止的失败模式，因此防护措施是结构性的，而非风格性的：
- 不得使用
Author (year)格式的引用。如果某个框架相关，请指出分析动作（“检验相互竞争的解释”），并将其加入交接时的待核实声明清单。不要引用该框架。 - 不得断言事实。凡是某项事实会影响判断的地方，都应写成
⚠️ to verify: [what]，而不是给出具体数值。 - 每次输出都必须以以下横幅结尾，确保读者不会把地图误认为研究发现。
方法——单一上下文，不分派子 Agent
所有步骤都在一次运行中完成。为理解问题而轻量读取上下文（对话、明确指定的项目文件）没有问题。不要进行文献检索，也不要调用专家；这些属于交接后的工作，尝试这样做就说明你选错了技能。
- 重述问题，用一句话明确并统一范围。
- 找出视角。 推导出问题真正需要的 4 到 6 个角度，不要套用通用清单。这与 Vi 在 SELECT 阶段执行的是同一种操作，只是独立进行且提前执行。用直白的语言为每个角度命名。
- 最关键的问题。 针对每个视角，列出它最会追问的一两个问题。
- 冲突地图。 指出这些视角最可能产生分歧的地方。这是核心内容：呈现冲突，而非平滑过渡的摘要。每个尚未解决的冲突用一行表示。如果找不到三个真实冲突，这个问题可能属于 SIMPLE。
- 完整答案的结构。 勾勒一份提纲，说明如果委托撰写，真正的交付成果会如何组织。
- 分诊结论。 SIMPLE（现在直接处理）或 COMPLEX（升级处理）。对于 COMPLEX，列出初步专家名单以及需要核实的声明。对于 SIMPLE，说明直接给出的答案会涵盖哪些内容。
输出结构
每次都使用此模板：
范围界定图：[问题]
- 问题 — 用一句话重述。
- 视角 — 列出 4 到 6 个角度并命名。
- 各视角关注的问题 — 每个视角提出最尖锐的问题。
- 冲突之处 — 张力图，每条现实分歧占一行。这是核心。
- 完整答案的结构 — 提纲骨架。
- 结论 — SIMPLE 或 COMPLEX、建议的下一步；如果是 COMPLEX，还要提供一组种子成员名单，以及
⚠️ to verify:列表。
最后加上：
范围界定图，不是研究结论。 这里没有任何论断附有来源。请将每一行都视为有待核实的假设，而非答案。要产出真正的答案，请将此图交给 /ann、/researcher 或 /evidence-synthesis。
常设规则
- 控制成本。 只用一个上下文，不使用子 Agent，不进行检索。一旦需要查阅文献，就转交处理。
- 给出建议，不做罗列。 结论必须明确选择 SIMPLE 或 COMPLEX，并指出一个具体的下一步，而不是提供选项菜单。
- 表达风格。 使用通俗英语（Flesch-Kincaid 等级 9 到 10），首次使用 MEL 术语时予以解释，正文中不要使用破折号。通过可理解性测试：罗马尼亚、突尼斯、埃塞俄比亚或越南的英语使用者能否初读即懂？
- 至少三个视角。 探索步骤要求这样做。少于三个真正不同的角度，本身就表明问题属于 SIMPLE。
收尾
给出范围界定图，然后提出交接：
“图已完成。结论：[SIMPLE / COMPLEX]。要我将此交给 /ann、/researcher 或 /evidence-synthesis，还是在问题属于 SIMPLE 时直接在此处理？”
不要在此技能中开始产出最终交付内容。图就是产出；交接之后才会生成答案。