lov-fact-check

fact-check — 尽调式事实校验

用这个 skill 回答事实真伪问题时，不要直接凭记忆下结论。你要模拟一个认真真人的尽调路径：先澄清命题，拆成可验证子问题，优先查一手资料，再用独立来源交叉验证，最后把证据、推断和不确定性分开写清楚。

When to Use

• 用户问某个事实是否成立：例如“Tauri 程序不支持 GitHub webhook handler 吗？”
• 用户要求“帮我确认”“查证一下”“这是真的吗”“有没有官方依据”。
• 用户给出一段文章、截图、传言、技术判断、商业说法或历史事实，希望判断可信度。
• 用户明确使用 English trigger phrases: fact check, verify this, source check, is this true, due diligence.

Core Principle

事实校验不是搜索答案，而是还原“一个谨慎的人会如何确认答案”。

• 先确认问题含义，再确认答案。
• 优先找一手资料：官方文档、源码、标准、法规、公告、论文、原始数据、公司/项目维护者声明。
• 对技术问题，优先官方文档、源码、release notes、issue/PR，再看博客和社区问答。
• 对会随时间变化的问题，必须联网核验，并写明检索日期。
• 把“证据显示”“合理推断”“仍未确认”分开。
• 不要用单一搜索结果做强结论。至少尝试找一个反例或边界条件。

Workflow (MANDATORY)

You MUST follow these steps in order:

Step 1: Restate the Claim

把用户的问题改写成一个可验证命题，并指出关键歧义。 如果关键歧义会改变检索方向，先用 AskUserQuestion 问一个澄清问题； 否则继续执行，不要为了形式而打断用户。

Example:

用户问：“Tauri 程序不支持 GitHub webhook handler 吗？”

可验证命题：
1. Tauri 桌面应用本身是否内置 HTTP server / webhook handler 能力？
2. Tauri 应用能否通过插件、Rust sidecar、本地端口或外部服务接收 GitHub webhook？
3. “不支持”指官方不推荐、没有内置 API，还是技术上完全不能做？

Step 2: Choose Evidence Plan

根据问题类型选择证据路径。

Claim Type	Primary Sources	Secondary Sources
技术能力 / API 支持	官方文档、源码、release notes、issue/PR、维护者讨论	Stack Overflow、博客、示例项目
产品 / 公司事实	官网、公告、SEC/工商资料、官方社媒、新闻稿	媒体报道、数据库
法律 / 政策 / 标准	法规原文、政府官网、标准正文	律所解读、行业文章
学术 / 医疗 / 科学	论文原文、系统综述、指南、数据集	科普文章、新闻报道
历史 / 人物 / 事件	原始档案、采访原文、时间线材料	百科、二手转述

Step 3: Search Like Due Diligence

执行检索时必须覆盖这些动作：

1. 查官方来源：项目官网、官方文档、GitHub repo、release notes、官方 FAQ。
2. 查限制和反例：搜索 not supported, webhook, http server, plugin, sidecar, issue, discussion, workaround 等相关词。
3. 查时间线：确认资料是否过期，尤其技术栈、法规、产品功能。
4. 查独立来源：至少一个非官方来源，用来发现官方文档没有覆盖的实践或争议。
5. 记录证据质量：一手、二手、社区经验、推断。

If web access is available and the claim depends on external facts, use it. Do not answer source-attributed or current factual claims from memory alone.

Step 4: Evaluate

用下面的判断框架组织结论：

• Direct evidence: 一手资料是否直接支持或否定命题？
• Boundary: 有无版本、平台、部署方式、权限、安全模型限制？
• Counterexample: 是否存在能推翻“完全不支持”的示例或 workaround？
• Terminology: 用户用词是否混淆了“没有内置支持”“不推荐”“不能做”？
• Confidence: 证据是否足够强？是否还有需要实测或询问维护者的点？