lovstudio-fact-check

fact-check — due-diligence-style fact verification

When using this skill to answer questions about whether a fact is true or false, do not draw conclusions directly from memory. You should simulate the due diligence path of a careful real person: first clarify the proposition, break it into verifiable sub-questions, prioritize primary sources, then cross-validate with independent sources, and finally write out the evidence, inferences, and uncertainties separately and clearly.

When to Use

• The user asks whether a certain fact holds: for example, “Tauri Does the program not support a GitHub webhook handler?”
• The user asks “help me confirm,” “verify this,” “is this true,” or “is there official basis.”
• The user provides an article, screenshot, rumor, technical judgment, business claim, or historical fact and wants its credibility assessed.
• The user explicitly uses English trigger phrases: fact check, verify this, source check, is this true, due diligence.

Core Principle

Fact-checking is not searching for an answer, but reconstructing “how a cautious person would confirm the answer.”

• First confirm the meaning of the question, then confirm the answer.
• Prioritize primary sources: official documentation, source code, standards, regulations, announcements, papers, raw data, statements from company/project maintainers.
• For technical questions, prioritize official documentation, source code, release notes, issues/PRs, then look at blogs and community Q&A.
• For questions that change over time, you must verify online and state the search date.
• Separate “evidence shows,” “reasonable inference,” and “still unconfirmed.”
• Do not use a single search result to make a strong conclusion. At least try to find a counterexample or boundary condition.

Workflow (MANDATORY)

You MUST follow these steps in order:

Step 1: Restate the Claim

Rewrite the user's question into a verifiable proposition and point out key ambiguities. If a key ambiguity would change the search direction, first use AskUserQuestion to ask one clarifying question; otherwise continue executing and do not interrupt the user just for formality.

Example:

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

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

Step 2: Choose Evidence Plan

Choose the evidence path according to the type of question.

Claim Type	Primary Sources	Secondary Sources
Technical capability / API support	Official documentation, source code, release notes, issues/PRs, maintainer discussions	Stack Overflow, blogs, example projects
Product / company facts	Official website, announcements, SEC/business registration materials, official social media, press releases	Media reports, databases
Law / policy / standards	Original legal texts, government websites, standard texts	Law firm interpretations, industry articles
Academic / medical / scientific	Original papers, systematic reviews, guidelines, datasets	Popular science articles, news reports
History / people / events	Original archives, original interviews, timeline materials	Encyclopedias, secondhand accounts

Step 3: Search Like Due Diligence

When performing searches, you must cover these actions:

1. Check official sources: project official website, official documentation, GitHub repo, release notes, official FAQ.
2. Check limitations and counterexamples: search not supported, webhook, http server, plugin, sidecar, issue, discussion, workaround and related terms.
3. Check the timeline: confirm whether the materials are outdated, especially tech stacks, regulations, and product features.
4. Check independent sources: at least one non-official source, used to discover practices or controversies not covered by official documentation.
5. Record evidence quality: primary, secondary, community experience, inference.

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

Organize conclusions using the following judgment framework:

• Direct evidence: Do primary sources directly support or refute the proposition?
• Boundary: Are there limitations involving version, platform, deployment method, permissions, or security model?
• Counterexample: Are there examples or workarounds that can overturn "completely unsupported"?
• Terminology: Does the user's wording confuse "no built-in support," "not recommended," and "cannot be done"?
• Confidence: Is the evidence strong enough? Are there still points that need testing or asking the maintainers?

Step 5: Answer in This Format

Output in Chinese by default. Unless the user requests English.

**结论**
[一句话回答：成立 / 不成立 / 部分成立 / 目前无法确认。]

**更精确的说法**
[把原命题改写成更准确的技术/事实表述。]

**证据链**
1. [来源类型] [来源名称 + 日期/版本，如有]：[它证明了什么]
2. [来源类型] [来源名称 + 日期/版本，如有]：[它证明了什么]
3. [来源类型] [来源名称 + 日期/版本，如有]：[它证明了什么]

**反例或边界**
[列出会改变结论的条件、workaround、版本差异、语义差异。]

**置信度**
[高 / 中 / 低]：[为什么]

**下一步验证**
[如需要：最小复现实验、要查的 issue、要问维护者的问题、要跑的命令。]

Evidence Labels

Use these labels to mark evidence quality:

• [一手] Official documentation, source code, release notes, direct replies from maintainers, original legal texts, original papers.
• [准一手] Official examples, official blogs, maintainer replies in official discussion forums.
• [二手] Media, blogs, tutorials, community Q&A, encyclopedias.
• [实测] Local reproduction, minimal demo, command output.
• [推断] Reasonable judgment based on a chain of evidence, but without a direct source.

Answer Rules

• Do not write "does not exist" when you mean "did not find it in search." You may only write "I did not find direct evidence."
• Do not just give a list of links; you must explain what each source proves.
• Provide links when citing web pages; do not copy long passages of the original text.
• For technical questions, prioritize actionable conclusions: whether it can be done, how it is recommended to be done, and what the risks are.
• If there is a spelling error in the user's question, quietly correct the search terms first, then mention it in the conclusion only if necessary. For example tuari is very likely Tauri。
• If the facts depend on the date, state today's date or the search date.
• If you cannot access the internet or cannot open a key source, you must state this clearly and downgrade the conclusion to "tentative."

Example

User:

tuari程序不支持GitHub webhook handler吗？

Good answer shape:

**结论**
“Tauri 程序不支持 GitHub webhook handler”这个说法不够准确。更准确地说，Tauri 桌面应用通常不内置一个面向公网接收 GitHub webhook 的服务器模型；但它可以通过外部后端、sidecar、本地 HTTP 服务或插件式 Rust 代码参与处理 webhook 流程。

**更精确的说法**
如果你的意思是“GitHub 能直接把 webhook 打到用户本机 Tauri 桌面应用”，这通常不可行也不推荐，因为 webhook 需要公网可达的 HTTP endpoint。如果你的意思是“Tauri 项目里能否写 Rust 逻辑处理 webhook payload”，技术上可以，但通常应由云端服务接收后再通知 Tauri 客户端。

...