Fact Check

Fact check

Keep serious factual mistakes and AI hallucinations out of the course without turning course-making into an exhaustive audit. Focus on the few claims that materially affect trust.

Choose the mode from the request and current course state; do not ask the user to choose a mode:

• Creating: when there is no course yet or the user asks to build/rebuild one, load stage-design and run the check only after all pages exist.
• Reviewing: when content already exists and the user asks to inspect it, report findings first. Do not edit unless fixes were already requested or the user approves findings after the report.

While creating a course

Use the normal stage-design workflow; this skill changes factual handling, not the teaching method, page style, or build sequence.

After all pages exist, call list_scenes, then read every completed page with read_stage using detail:"text"; follow nextOffset until all visible text and narration have been read. Run a quick final sanity check of exact facts and cross-page contradictions. Correct obvious errors before delivery because creating the course already authorizes making its content accurate, subject to the source-of-truth boundary below. Do not interrupt creation with a separate audit report or approval gate unless that boundary requires a user decision; briefly mention only material corrections or remaining uncertainty when handing off the finished course.

When reviewing existing content

For a course, call list_scenes, then read all visible text and narration with read_stage using detail:"text"; follow nextOffset until complete. Respect a narrower scope if the user gave one.

Read once for context and silently shortlist high-signal risks:

• exact numbers, dates, counts, names, and attributed quotations;
• laws, standards, formulas, technical definitions, and classifications;
• “first”, “only”, “always”, “must”, and similar absolute claims;
• causal or professional conclusions stated as settled fact;
• contradictions between pages;
• suspiciously specific claims with no visible support.

Do not verify every claim. Skip correct material, wording preferences, harmless simplifications, and low-value trivia.

Verify only the shortlist

Check list_materials and relevant read_material content first. User sources may support a claim, but the course being checked cannot prove itself.

Use web_search for shortlisted claims that depend on current, exact, disputed, or specialist knowledge. A normal first pass should need no more than about 6–8 searches. Use fetch_url to read the source: a result snippet or the mere existence of a related source is not evidence.

Do not pause the run to ask the user for sources, permission to use general knowledge, or permission to continue. Use the tools and materials that are available. If web search is unavailable, continue with stable knowledge, make fewer factual commitments, and mark genuinely uncertain claims. Never guess a URL for fetch_url; fetch only a user-provided URL or one returned by web_search.

For a compound statement, isolate the questionable part and verify that exact part. Prefer primary or official sources. One authoritative source is enough for an obvious error; add corroboration only for disputed or high-impact claims. For versioned knowledge such as law, policy, standards, or medicine, check the relevant date, version, and jurisdiction.

“No reliable evidence found” does not mean false. If verification remains inconclusive, say so rather than inventing a verdict or correction.

Preserve approved inputs

Do not make a correction that would materially conflict with the settled course plan, user-uploaded materials, or facts already supplied to generation through materialFacts. Treat these as approved inputs, not ordinary generated copy.

If the evidence indicates that an approved input itself may contain a factual error, do not edit the affected course content or silently override the input. Use ask_user to flag the input conflict, state the affected page or claim and the contrary evidence concisely, and offer options to keep the approved input, authorize the factual correction, or review the conflict without editing. Put the warning in the ask_user prompt so it appears in the choice card, not only in the preceding report. This protection applies even when edits were otherwise authorized. It does not block corrections to errors introduced independently by generated page content.

Give a short, readable review report

In review mode, return roughly 3–8 useful findings in the first pass, or fewer when fewer exist. Group them under these bold plain-text labels, in this order, and omit an empty group. Keep them at normal body-text size: do not prefix them with Markdown heading markers such as # or ##.

• A. 明确事实错误
• B. 表述不严谨
• C. 需要核实 — include only when the claim matters

Within the groups, number findings consecutively across the whole report with Arabic numerals. Give every finding a short bold line containing its number, page/location, and specific issue, for example: **1. 第 5 页｜测验解析｜知识混淆**. Do not use Markdown heading markers for finding titles either.

Under each heading, use exactly three bullets:

• 原始表述： quote only the relevant sentence or fragment;
• 存在问题： explain the error and the correct fact in plain language; include a concise source and date here when useful;
• 修改建议： give only the edit action or a compact replacement.

Keep each bullet to one or two short sentences. Do not repeat the same fact or quotation across bullets. If 存在问题 already gives the applicable rule or correct wording, 修改建议 should only state the change — for example, “按上述条文改写，删除‘商业秘密、法人’” — instead of quoting the article again.

Do not show scores, confidence percentages, lengthy methodology, correct claims, or minor style issues. Do not pad the report to reach a quota. If no material issue is found, say what scope was scanned and that no obvious error was found; do not claim the content is perfectly accurate.

Let the user choose after a review

When there are actionable findings and edits were not already authorized, the last action of the turn must be an ask_user tool call with a non-empty options array. This is an interaction requirement: do not merely print option ids or end a normal chat message with “which do you choose?”. Use concise labels in the user's language, equivalent to:

• fix all reported issues;
• fix confirmed errors only;
• keep the report without changes.

Use stable option ids such as fix_all, fix_confirmed, and keep. The form's free-text choice lets the user enter selected finding numbers such as 1, 3.

An approved-input conflict always requires the separate ask_user choice described above, even if the user previously authorized general corrections.

Do not patch before the answer. After approval, load pro-editing, read each selected page with read_stage using detail:"source", and change only the approved claims. If narration changes, regenerate its audio as required by pro-editing.