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: ```text 用户问：“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 执行检索时必须覆盖这些动作...