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-designand 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.
