SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillslaohan-shencha

laohan-shencha

Writing & research

View repository

Updated 10-15 15:23

About this skill

Laohan Shencha (Lao Han Deep Review)

Core Principles

When LLMs write technical documentation, they naturally believe the claims they write are correct. The sole purpose of this Skill:Find those claims that "look correct but are actually wrong", and correct them when authorized.

Pure text review (contradictory statements, inconsistent formatting) is not the focus of this skill—those can be found through text comparison alone.

Modes and Actions

First separately choose the "verification target" and "whether to modify"; do not mix the two together:

  • TECH_CLAIMS: default mode, used for technical documentation, scripts, configuration, and external resource claims.
  • CONTENT_CLAIMS: used only in real-person spoken workflow ⑤ or when the user explicitly requests verification of spoken facts.
  • RECORDED_FINAL_INPUT_GUARD + AUDIT_ONLY: used only at the orchestration entry point for an already recorded final script, to audit whether rerecording is necessary.
  • AUDIT_ONLY: the default action when the user says "review, verify, check whether there are problems", only producing findings and evidence, without modifying files.
  • VERIFY_AND_FIX: used only when the user explicitly requests "fix, change it", or when an upstream workflow contract explicitly authorizes modification.

Choosing CONTENT_CLAIMS does not mean lowering factual standards, and choosing VERIFY_AND_FIX does not authorize modifying style, methodology, or content unrelated to facts.

RECORDED_FINAL_INPUT_GUARD + AUDIT_ONLY

Enabled only when the episode recordUSER_PROVIDED_FINAL_SCRIPT_AND_RAWand the upstream Prompt explicitly specifiesRECORDED_FINAL_INPUT_GUARD + AUDIT_ONLY. Read the current01-口播稿.mdand06-拍摄素材/raw.mp4, calculate SHA-256 for each; perform only a blocking audit that does not modify the spoken script. Ordinary unverifiable, non-core wording and safely editable issues are written as non-blocking observations and then continued, and it must not automatically return to ②, rerun ③—⑤, or fabricate a regular review history.

Fixed writes00-编排/recorded-input-guard.jsonand00-编排/recorded-input-guard.md. JSON must be:

{
  "schema_version": 1,
  "mode": "RECORDED_FINAL_INPUT_GUARD",
  "script_sha256": "64 lowercase hex",
  "raw_sha256": "64 lowercase hex",
  "status": "CLEAR_WITH_NOTES|BLOCKED_REQUIRES_RERECORD",
  "blocking_reasons": [],
  "non_blocking_observations": [],
  "checked_at": "ISO-8601"
}

blocking_reasonsOnly the following four items are allowed, and the status may beBLOCKED_REQUIRES_RERECORD：

  • HIGH_RISK_PLATFORM_VIOLATION
  • CORE_FACT_DIRECTLY_CONTRADICTED
  • SCRIPT_RAW_MATERIAL_MISMATCH
  • RERECORD_ONLY_REMEDIATION

This mode must not write04-事实核验.md、04-事实主张.jsonorfact_check_status: CLEAR, and must not edit the script. The human report must restate the same script/raw SHA, status, blocking reasons, and non-blocking observations, forRECORDED_FINAL_INPUT_GUARDdownstream aggregation.

CONTENT_CLAIMS mode (real-person spoken ⑤)

The input is episodes/<slug>/01-口播稿.md, and the output is fixed as 04-事实核验.md and 04-事实主张.json. The beginning of the report must contain script_hash: <当前稿 SHA-256>、fact_check_status: CLEAR|REVISE_REQUIRED|BLOCKED、contradicted_count and unverifiable_count frontmatter. The claims JSON must contain the current script_hash, the factual report SHA, a stable claim_idfor each external claim, the original sentence, theSUPPORTED|INFERRED|CONTRADICTED|UNVERIFIABLE|OPINION conclusion, and source evidence. Extract only claims that would affect audience judgment and can be verified by external evidence: institutional actions, position/product definitions, numbers, growth rates, policies, research conclusions, verbatim quotations, and temporal relationships. Only write what can be directly read from the source as SUPPORTED；SUPPORTED there must be at least one auditable piece of evidence—a genuinely retrieved page body (retrieval: FETCHED_HTTP_200) or local evidence within the episode (local_path + a consistently measured sha256); if only a title/search snippet was read (TITLE_ONLY) or nothing was retrieved (FETCH_FAILED), it must not write SUPPORTED, and may only write INFERRED(append non-empty inference_note) or UNVERIFIABLE; conclusions derived from implementation, multiple sources, or behavior are written as INFERRED, and provide a non-empty inference_note. Personal experience, value judgments, metaphors, and action recommendations are marked as OPINION。

04-事实主张.json Minimal structure:schema_version: 1、script_sha256、fact_report_sha256、claims array; each item contains at least a stable claim_id、statement、verdict、evidence array. Each evidence item must have a stable id, and one of the two: external evidence is written as url（http(s)）、source_type、retrieval(retrieval tier, one of three:FETCHED_HTTP_200 truly retrieved page body / FETCH_FAILED retrieval failed / TITLE_ONLY only read the title search snippet)——when writing FETCHED_HTTP_200 a parsable retrieved_atmust be given, when writing FETCH_FAILED／TITLE_ONLY a non-empty failure_notemust be given (explaining why it was not retrieved); for local evidence in this issue write the in-episode local_path and file sha256(must match the actual measurement). The two SHA fields must respectively equal the SHA-256 of the current 01-口播稿.md and 04-事实核验.md . When there are no verifiable claims, still write an empty claims array; the file may not be omitted or sources fabricated. (The retrieval tier and SUPPORTED criteria have been mechanically checked by scripts/verify-fact-claims.mjs in the production/final stage since 2026-09-30; older artifacts that previously only registered url will only WARN during accepted-final recheck, with no retroactive application.)

  1. Extract claims numbered one by one, preserving the original sentence and the line it is on.
  2. For each item, prioritize finding a first-hand source: institutional official website/announcement, original research, official database, original interview, or the platform's original post; only use reliable second-hand reporting when there is no first-hand source, and note it.
  3. Only SUPPORTED、INFERRED、CONTRADICTED、UNVERIFIABLE、OPINION five conclusions may be given; without a source, "basically correct" may not be written.INFERRED may be used for spoken judgment, but cannot serve as direct factual evidence for subsequent PROOF beats.
  4. CONTRADICTED must be revised back in ②;UNVERIFIABLE must be deleted, replaced with cautious wording without numbers, or marked as a personal judgment. "It is said" may not be used to cover it up.
  5. The report must contain at least: claim ID, original sentence, conclusion, source link, source date, and suggested revision. When there are no verifiable claims, still write "0 items"; the file may not be omitted.

Only when CONTRADICTED=0、UNVERIFIABLE=0 and all sentences requiring modification have been handled in the current draft may fact_check_status: CLEARbe written; otherwise write REVISE_REQUIRED and count accurately. When the network is unavailable, sources cannot be read, or verification cannot be completed, write BLOCKED, and hash or "report already produced" may not be used to replace the conclusion.

CONTENT_CLAIMS does not evaluate hooks, pacing, resonance, or transmissibility; these are diagnosed by dbskill. It also does not change the upstream Cheat's rubric.

Original templates, catchphrases, metaphors, conflict expressions, personal judgments, and dramatized scenes are not "safety risks" to be eliminated. Only extract the externally verifiable factual parts; the mode of expression itself must not be deleted or downgraded because sources cannot be cited. Personal real experience is treated as a factual issue only when it impersonates nonexistent actual measurements, data, or results.

AUTONOMOUS_RUN boundary: CONTENT_CLAIMS does not execute the general "Stage 3.5 item-by-item confirmation with the user" below. When CONTRADICTED/UNVERIFIABLE is found, first write REVISE_REQUIRED, with the exact original sentence/evidence/suggested revision, and return to ②; the orchestrator may autonomously delete, modify, or downgrade wording within at most three rounds, then rerun ③—⑤ and ④ the final prediction. Only when source access, account authorization, or the facts themselves must be provided by Jeffrey and still cannot be resolved after three rounds does it BLOCKED. Regular HIGH/CRITICAL fact corrections must not be turned into a manual confirmation gate, and issues must not be written as CLEAR in order to continue the process.

Tiered sampling (enabled when more than 50 claims are declared, to save tokens): High confidence (copied from official README, environment variable names) → sample-check 20%; medium confidence (version numbers, parameter values) → sample-check 50%; low/unknown confidence (community discussions, blog citations) → verify all. When the number of declared claims is ≤50, verify each one in full. Claims that are purely category common sense and do not affect the audience's judgment (such as "PyTorch is a deep learning framework") may be skipped; version numbers, recommended values, resource requirements, ports, or other parameters that would change the outcome of an operation are not "common sense" and must be verified according to these rules.

Five-stage review process

Stage 1: Scan — extract verifiable claims

Read all relevant files in the workspace and extract the following types of claims:

File scope selection: Prioritize scanning executable scripts (.py/.sh/.ps1), configuration files (.json/.yaml/.toml), and project documentation (README.md/workflows/). Skip pure prose/diary/log-type files. When there are more than 20 files, prioritize script + configuration types.

Claim extraction patterns:

  • GitHub repository：github\.com/[\w.-]+/[\w.-]+ → github.com/xxx/yyy
  • Version number：v?\d+\.\d+(\.\d+)*(?:-[.\w]+)? → PyTorch 2.7.1
  • Parameter value："?\w+"?\s*[:=]\s*"?[^\s,;"]+"? → blocks_to_swap=10, port: 3000
  • API endpoint：https?://[^\s]+\bapi[^\s]+ → https://api.example.com/v1/chat
  • CLI command：(?:^|[\s]+)(docker|npm|pip|python|git|curl|cargo|go)\s[^\n]+ → docker compose up -d
  • Environment variable：\b[A-Z_]{3,}\b(activated only in .env/.sh/configuration files) → OPENAI_API_KEY
  • File path：(?:/[\w.-]+)+/? → /etc/nginx/conf.d/, ~/.config/
  • Port number：:\d{2,5}(?:/\w+)? → :18789, :3000/api
  • Docker tag：[\w.-]+:[\w][\w.-]* → python:3.11-slim
  • Hardware requirements：\d+\s*(GB|MB|GiB|MiB)\s*(VRAM|RAM|显存) → 16GB VRAM
  • File size：(?:~|大约|约|about)?\s*\d+\s*(KB|MB|GB|TB) → ~10GB
  • pip install：(?:pip3?|python\s+-m\s+pip|uv\s+pip)\s+install\s+\S+ → pip install xxx
  • npm package："(@?[\w@./-]+)":\s*"([^"]+)" → "next": "^14.2.0"
  • CVE ID：CVE-\d{4}-\d{4,} → CVE-2024-1234
  • Browser compatibility：(Chrome|Safari|Firefox|Edge)\s*\d+ → Chrome 90+
  • git clone：git\s+clone\s+(?:--depth\s+\d+\s+)?\S+ → git clone --depth 1 https://...

External resource references in executable scripts are automatically escalated by one severity level. Filenames, URLs, and repository IDs written incorrectly in scripts (.ps1/.py/.sh) directly cause runtime failures, and are far more serious than errors of the same name in documentation.

Output: a list of claims grouped by file, annotating the verification method and priority for each.

Stage 2: Online verification — verify one by one

Use the corresponding verification method for each claim.You must actually query; you cannot judge based on training knowledge.

Verification tool priority:

  1. gh repo view / gh api — GitHub repository availability,gh api repos/{o}/{r}/releases/latest check the latest release
  2. Web search — official documentation, community reports
  3. Context7 — the latest documentation for libraries/frameworks (note API rate limits)
  4. curl -I {url} — quickly check URL reachability (HEAD requests preferred)
  5. npm view {pkg} / pip index versions {pkg} / brew info {fmla} — package manager verification
  6. Docker Hub API / HuggingFace API / PyPI JSON API — image and model verification
  7. gh auth status — first check authentication status, then decide whether to set GH_TOKEN

Parallelization: Prefer parallel tool calls for independent verification items; delegate to sub-agents only when the user explicitly requests it or the host rules allow multiple agents.

API rate limit handling:

  • GitHub API unauthenticated: 60 req/hr. Setting the GH_TOKEN or GITHUB_TOKEN environment variable grants 5000 req/hr.
  • HuggingFace API：https://huggingface.co/api/models/{user}/{repo} to view model information,/tree/main to view the file list.
  • PyPI API：https://pypi.org/pypi/{package}/json to get version information.

Source conflict resolution priority: Official documentation > GitHub README > Official Wiki > Community discussion > Blog posts. When sources conflict, the higher priority prevails, and note the conflict details in the report.

Phase 3: Cross-comparison — Consistency between documents

Check whether the same parameter/description is stated consistently across different files:

  • Numeric parameters (node count, VRAM, version number)
  • Repository URL and installation commands
  • Hardware requirement descriptions
  • Step/process descriptions

Phase 3.5: Confirmation — Show findings to the user

This phase applies only to general technical documentation review. CONTENT_CLAIMS in real-person voiceover ⑤ are handled according to the AUTONOMOUS_RUN/REVIEW_GATED contract above and are not re-asked here.

  • AUDIT_ONLY: Show findings, evidence, and minimal fix suggestions, then stop and do not modify any files.
  • VERIFY_AND_FIX: First list the claims to be modified and the evidence; if a fix would expand the user-specified scope, change program behavior, or require product judgment, confirm first. Ordinary factual corrections within scope can be executed directly.
  • CONTENT_CLAIMS: Handle according to the current run mode and node contract; do not add an extra confirmation threshold.

When confirmation is needed, use the following format:

### 发现 #1 [CRITICAL]
文件：xxx.py:42  原：`pip instal torch`  应为：`pip install torch`
证据：PyPI 官方文档 https://pypi.org/project/torch/
是否修复？[Y/n]（拒绝时标为"用户否决"，不修复但保留在报告中）

Phase 4: Fix — Only for VERIFY_AND_FIX

AUDIT_ONLY Skip this phase.VERIFY_AND_FIX Fix in order of severity, anchoring each severity to a testable consequence:

Severity Definition Example
CRITICAL Provably causes crashes or exceptions Repository does not exist, command syntax error, NameError
HIGH Provably causes incorrect output/behavior Wrong parameter value, VRAM estimate deviation >20%
MEDIUM Information is incorrect but does not change system behavior Outdated version number, dead link (if no one clicks it)
LOW Functionally correct but imprecisely stated Inconsistent wording, formatting differences

Phase 5: Report

Output format:

## 审查报告

### 统计
- 总声明数：X
- 已验证：X
- 有问题：X（CRITICAL: X / HIGH: X / MEDIUM: X / LOW: X）
- 已修复：X

### 发现的问题
| 文件 | 行 | 原值 | 应为 | 证据来源 | 严重度 | 状态 |
|------|-----|------|------|---------|--------|------|
| ... | ... | ... | ... | ... | ... | 已修/待定/用户否决 |

### 仍需实际验证的项
（需要实际运行环境才能确认的项目）

Key Considerations

  1. Do not trust training knowledge: Even for "common-sense" parameter values, verify online. Model training data has a time limit.
  2. Verify repository availability: Repositories deleted/made private/renamed (e.g., user/repo suddenly returning 404) can only be discovered by actually querying; static analysis cannot detect them.
  3. Check official sources for parameter values: Recommended values for blocks_to_swap and VRAM requirements should be based on official README/documentation, not blogs.
  4. Cross-document synchronization: After fixing one parameter, you must check whether all files referencing that parameter also need updating.
  5. Mark uncertain items: Items that cannot be verified online (e.g., requiring actual hardware testing) must be clearly marked in the report.
  6. Iterative review: After Phase 4 fixes are complete, return to Phase 1 and rescan the fixed files to confirm the fixes did not introduce new errors. Iterate at most 2 rounds.
  7. Transparent coverage: When resources are limited, prioritize verifying scripts, configurations, and high-impact claims based on consequences; the report must clearly state what has been verified, what has not been verified, and the sampling scope, and must not present partial coverage as fully complete.
  8. No mechanical query limit: When sources conflict, continue investigating until a conclusion can be given, or clearly mark it as UNVERIFIABLE/BLOCKED. Stop only when the task budget is exhausted, external access fails, or user information is missing; write generic reviews truthfully PARTIAL/BLOCKED, write CONTENT_CLAIMS according to the node contract BLOCKED, and do not skip the remaining scope and then claim completion just because no serious issues were found.

Applicable Project Types

This skill is anexternal resource verifier, not a code reviewer. It verifies external claims that can be checked online, such as URLs, version numbers, package names, and file paths.Cannot detect: code-level bugs such as undefined variables, type errors, logic defects, and missing imports.

Applicable scenarios:

  • AI model deployment solutions (ComfyUI, LoRA training, inference services)
  • Infrastructure configuration (Docker, K8s, CI/CD)
  • Technical projects with dense dependency versions
  • Projects maintained with multiple documents (guides + scripts + workflows)
  • Any technical project that references external resources, such as web application backends, mobile applications, and database architectures

Review Anti-Patterns (Should Not Be Flagged as Issues)

The following scenarios arenormalin specific project environments and should not be flagged:

  1. Package manager version namespace differences: brew/apt/pip/npm each have independent version numbering systems; it is normal for the same tool to have different version numbers in different package managers, so do not cross-compare and flag it as "outdated".
  2. Platform/environment-specific parameters: some CLI parameters depend on the local environment (such as browser cookies or hardware-specific flags); being unavailable on other OSes is by design, not an error.
  3. Intentional use of shell=True: some scripts must use shell=Truefor path expansion; this is not a security vulnerability. Judge based on context rather than flagging mechanically.
  4. Private/internal packages: internal npm/pip/cargo packages may not be found in public registries; flag them as "not public" rather than "nonexistent".
  5. Documented known issues: entries already marked in code comments or documentation as "404"/"paused"/"deprecated"/"TODO" are intentionally recorded, not errors to be fixed.
  6. Large timeout settings for long-running operations: timeout settings for operations such as audio/video processing and large file downloads (such as 300s+) are necessary; do not "optimize" by shortening them according to regular RPC standards.
  7. Platform-specific standard paths: each OS has standard installation paths (macOS /opt/homebrew、Linux /usr/local、Windows C:\Program Files); they should not be cross-flagged.
  8. Regional mirrors/proxies：pypi.tuna.tsinghua.edu.cn、ghproxy.com etc. are legitimate mirrors and should not be flagged as "unofficial".