When to Use
- Users need to compare answers from one or more platforms, distinguish unverified drafts from verified conclusions, and retain sources, point-by-point verdicts, and transferable reports.
- Collection results already exist, or the three dependency skills are ready to be independently installed and reviewed; network access, account configuration, and local writes must comply with user authorization.
- Chinese is the target language of the original workflow; when the user specifies another language, interact in that language while preserving the field names in the data contract.
This skill only performs orchestration and does not embed the three business layers. It calls sibling skills in the following order:
llm-answer-reference-compare: multi-platform answers, citations, and on-site evidence collection.fact-check-x-knowledge-compare: local structured comparison of knowledge points, optional.fact-check-x-authoritative-verify: point-by-point concurrent authoritative verification and platform performance report.
All semantic decomposition and evidence adjudication are performed by the agent currently hosting the skill. The scripts do not call any model API.
Dependency location
AAS only distributes the scripts and tests of this orchestration skill,not distributed llm-answer-reference-compare、fact-check-x-knowledge-compare、fact-check-x-authoritative-verify collectors, renderers, and fixtures. Therefore, installing this skill alone cannot run the complete pipeline, nor can it falsely claim to have opened the login page.
Dependency recovery: from verified official sources obtain the four complete skills and their dependencies. First review the pinned-revision sources, licenses, lock files, browser and account data boundaries; do not silently download or install them through this skill. The complete three dependency directories installed separately can be located through the following variables; the automatic configuration component uses the same directories:
export FACTCHECK_SKILLS_DIR="<已审查的完整上游分发包的 skills 绝对目录>"
Script paths are relative to this skill's installation directory; enter that directory before execution. First check dependencies (fail explicitly when executable entry points are missing; do not treat the mere existence of SKILL.md as proof of readiness):
python3 scripts/fact_check_x.py locate
Complete process
First collect results.json, then prepare the knowledge point comparison:
python3 scripts/fact_check_x.py prepare-comparison \
--results <results.json> \
--run-dir <run>
The command will synchronously generate the "summary of answers from all parties", generating at the top level of the run directory 01-capture-report.html. Each deliverables entry simultaneously returns the verified existing local path, standard fileUri , and directly displayable markdownLink. The caller must display markdownLinkas-is, and must not concatenate Windows paths on its own or put path directly into Markdown; if the artifact does not exist, the command will fail at the current stage.
In the default interactive mode, the program writes the stage status to stage-checkpoints.json. After the caller sends the artifacts of this stage and receives the user's "continue to the next step", it must use checkpoint.acknowledgement.token to execute:
python3 scripts/fact_check_x.py acknowledge-stage \
--run-dir <run> --stage <checkpoint.stage> \
--token <checkpoint.acknowledgement.token> --decision continue
If not confirmed, the next-stage command will fail directly. The current program implements a stage-by-stage confirmation mode; explain this constraint before executing the complete process. When the user requests continuous execution, do not falsely claim that automatic mode is already supported, and do not forge confirmation tokens.
The current agent reads <run>/comparison-task.json, writes <run>/comparison-analysis.json, and then executes:
comparison-task.json is a self-contained compact working set. After phase confirmation, only "read the task package once, write the analysis once, and execute acceptance once" is allowed, with the compact task package as the primary input, avoiding unnecessary repeated reads or full dumps. When errors, ambiguities, or contract issues occur, the necessary source code or evidence should be read to locate the cause; the three-call limit is an upstream efficiency suggestion and must not be used to block correctness or safety checks.capturedText is only a bounded original-text preview; the complete main text is obtained by the program during acceptance from results.json verification and reconstruction.
During decomposition, atomicity simultaneously constrains knowledge points and each platform's claim. When a single original sentence contains multiple independent obligations, conditions, objects, values, or consequences, it must be split into points, and each claim retains only the current fact; substantial newly added platform-specific facts must also be made into separate anchorless knowledge points and must not be merged into broad knowledge points and then reused with a deep-knowledge anchor to skip checking. Each knowledge point must also indicate claimType=fact|recommendation: purely operational suggestions may be marked as recommendation, and are not judged as unfaithful citation merely for lacking a per-sentence footnote; institutional facts, conditions, numbers, or time limits contained in a suggestion must be split into independent fact。
python3 scripts/fact_check_x.py complete-comparison \
--results <results.json> \
--run-dir <run>
The command will generate at the top level of the running directory 02-comparison-report.html, and through deliverables[].markdownLink return a clickable link; the caller must display it as is. The report must include a comprehensive draft explicitly marked "unverified". In the default interactive mode, only after the user confirms to continue may authoritative verification proceed.
Generate an independent cloud request for each knowledge point and gather evidence concurrently:
python3 scripts/fact_check_x.py prepare-authority --run-dir <run>
python3 scripts/fact_check_x.py search-authority --run-dir <run> --max-workers 12
Deep-knowledge collection retains both the per-sentence footnotes in the answer and the answer-level sources in the "Knowledge Special Library"; identical URLs are merged into inline_and_global. Answer-level sources may support the fact only when they are semantically matched one by one against the current knowledge point and the original text can be located; they must not be inherited wholesale from the entire library. When a knowledge point already has official materials attached to this answer from Deep Knowledge/Deep Knowledge (deep traceability), or gov.cn materials attached to this answer from another platform, and the original text indeed supports the current factual claim, directly reuse them as official evidence and do not call trusted search. Purely operational suggestions likewise do not call trusted search; apart from these, factual knowledge points whose existing materials are insufficient for adjudication are the non-exempt-from-checking knowledge points.
If there are knowledge points not exempt from checking but the local machine does not yet have a trusted search configuration,prepare-authority and search-authority will return status=configuration_required、userPrompt and configuration.command and exit with a nonzero status. The caller first displays the login prompt and the external provider, account/key creation, possible costs, scope of data sent, and local storage location, and after obtaining authorization executes the command in the foreground. "Missing configuration" must not be treated as authorization to automatically create account credentials or connect to the network. The user only needs to complete login on the automatically opened DeepKnowledge MaaS page; the component will automatically reuse an existing complete key, and if there is none, create Fact-Check-X dedicated key, and after verification save it to ~/.fact-check-x/credentials/trusted-search-key. Carriers such as Codex, Claude Code, and WorkBuddy share this configuration, and when an existing key is detected, login is skipped directly. After successful configuration, the caller automatically reruns prepare-authority, and must not require the user to copy the key, edit shell configuration, reply "configured", or switch to deep-knowledge sources or ordinary search to bypass it.
Only when trusted search returns 401/403 should the existing key be treated as invalid and automatic configuration be entered. On timeout, network disconnection, or service abnormality, retain the existing configuration and automatically retry; if it still fails after retry, stay in the search phase and return a technical error, without requiring the user to log in again and without converting it into manual fact review.
prepare-authority will write authority-gate.json. Only after the trusted search batch completes normally and the gate status changes to searched mayfinalize-authority Only then is it allowed to run; manually writing evidence or result cannot bypass this.
The current agent reads one by one authority/requests and authority/evidence, writes the verdict into authority/assessments/<知识点ID>.json, then:
In no-check mode,trustedAnchor.officialAnswer is the authoritative conclusion for the current factual knowledge point; the anchor evidence list is used for source tracing. Regardless of whether it comes from deep knowledge or gov.cn, it must be confirmed that the captured main text actually supports the conclusion, and it must not be automatically determined solely based on official attributes.trustedAnchor.claimEvidenceMap records the official original text that each platform has already bound claim by claim; platforms that hit this mapping directly reuse the evidence included with this answer, and must not be downgraded to insufficient evidence because another round of trusted search did not recall the same material. When other platform claims are semantically consistent with officialAnswer or can be directly inferred from it, the verdict is supported and cites a valid anchor evidence ID. Only when the platform claim adds substantive facts that the authoritative conclusion cannot support, or when it truly cannot be determined, use insufficient. The citation faithfulness in the knowledge point comparison stage and the factual correctness in this stage are retained separately; a claim already confirmed by the authoritative conclusion must not be refused judgment merely because the platform's own citations are insufficient.recommendation is displayed separately as an "operational suggestion" and does not enter the factual accuracy rate or hallucination rate; if authoritative evidence proves that the suggestion would be misleading, it may still be judged as contradicted。
{
"authoritativeFinding": "由权威证据支持的知识点结论",
"verdicts": {
"<平台ID>": {
"verdict": "supported",
"reason": "主张与 E1 一致",
"evidenceIds": ["E1"]
}
}
}
verdict can only use supported、contradicted or insufficient, and the evidence ID must exist in the current evidence file. The old-style top-level verdict、officialAnswer、platformAssessment will be rejected.
python3 scripts/fact_check_x.py finalize-authority --run-dir <run>
After the third step is completed, if the assessment needs to be corrected, it is forbidden to manually clear the results or modify the gate. First execute python3 scripts/fact_check_x.py reopen-authority --run-dir <run> --reason "<原因>"; after the program validates and locks the summary and archives the old verdict, it rolls back to searched, then modify the assessment, re-run finalize-authority and reconfirm the third-step artifacts.
finalize-authority generates the "final answer after authoritative verification", including only directly supported knowledge points with sufficient evidence in finalAnswer, writing supplementary references separately into supplementalFindings, and writing items with insufficient evidence into evidenceGaps. The third step displays only the direct answer, evidence boundaries, and a concise source index; per-knowledge-point verdicts and scoring are displayed only in the fourth step.
finalize-authority After completing the verdict, it independently generates 03-authority-report.html, and through
deliverables returns the verified path, file URI, and markdownLink. The caller must display markdownLinkas-is; in the default interactive mode,
only when the status is completed and the user confirms to continue is it executed:
python3 scripts/fact_check_x.py deliver --results <results.json> --run-dir <run>
When trusted search returns no_evidence , record it as insufficient_evidence: an empty result only means that no adjudicable material was obtained this time, and it cannot be directly judged as "fabricated"; after the evidence boundary is recorded, continue generating subsequent reports.
deliver must generate and return four independently readable reports at the top level of the run directory:
01-capture-report.html: summary of each party's answers;02-comparison-report.html: aggregation of each party's answers (unverified);03-authority-report.html: final answer after authoritative verification, authoritative evidence, and evidence boundaries;04-final-report.html: evaluation report of each party's answers.
deliver can only read the verification.json and 03-authority-report.htmllocked in the third step; if the summary of any file changes, it must be rejected, and the third step must not be recalculated or rewritten.
If any report is missing, 05-complete-report-package.zip。
must not be generated or delivered. Final retention:
capture/results.json、capture/report.html、capture/report.md;comparison-task.json、comparison-analysis.json、comparison.json、comparison.html;- independent request, evidence, assessment, and result for each knowledge point;
authority/batch.json、verification.json、report.html、pipeline.json;- four stage reports and
05-complete-report-package.zip。
skip knowledge point comparison
Knowledge point comparison is an optional capability. When structured knowledge points are already available, a single-knowledge-point request can be established directly according to the data contract of the authoritative evidence verification module, invoking it independently fact-check-x-authoritative-verify. The unified entry point will not force users to first collect multiple AI answers.
Execution boundaries
- The raw answer stage only collects, does not verify; the trusted search full-text parameter may be used to complete the body text of the same source already provided by the platform, but citations must not be added or replaced.
- Knowledge point comparison only compares the original answer with the attached sources, and does not go online to find the truth.
- The cloud layer only receives the current knowledge point; if the claims of all parties are the same, the claims are not uploaded, and only differences are uploaded when they differ.
- Shenzhixiao does not repeat the search when a qualified official anchor already exists.
- The final report must use the stable report renderer within the authoritative evidence verification module.
Delivery gate
# 本地边界检查可离线执行;完整冒烟测试需要上面的三个已审查依赖与夹具。
python3 tests/smoke_test.py
# quick_validate.py 属于可选宿主工具,未随 AAS 分发;仅在当前宿主确实存在且已审查时使用。
For complete standards, see Acceptance criteria and Orchestration contract。
Examples
用户:比较两份已有回答,区分来源支持、事实核验和证据不足,先生成未核验草案。
助手:确认输入/私有输出目录,检查依赖,准备第一阶段报告;不自动登录云服务、创建 Key 或把证据不足标为误导。
Limitations
- This skill writes to/cleans the runtime directory, invokes external sub-skills, and the configuration process may create and save account Keys; use only a dedicated private runtime directory and authorized accounts.
risk: criticaldescribes these capabilities, not a rating of content quality or service security. - Do not automatically install all dependencies; before installation, review fixed sources, lock files, and lifecycle scripts,
prepare-runtimedisables npm lifecycle scripts by default. - External search verification sends requests and may consume quota; execute only after authorization, and it is forbidden to transmit Keys to unknown addresses or redirects.
- The JSON summary gate prevents accidents or subsequent changes and does not constitute a signature resistant to malicious local attacks; the runtime directory, inputs, and sub-skills must be trusted. Do not directly execute sub-skills after receiving third-party artifacts.
- An official domain is not proof of automatic correctness; the obtained original text must support the current atomic claim, and if technical collection fails, insufficient evidence is retained.
- Complete smoke, multi-platform, and stage gate tests depend on the complete upstream distribution package; AAS does not include these external fixtures, and when missing, prerequisites should be stated and passes must not be fabricated.
- Local tests/fixtures cannot prove actual login, provider invocation, or real platform end-to-end behavior.