shield_lock
金大哥
← 返回 Skill 列表
extension
分类: 效率与办公无需 API Key

thesis-audit-reviewer

Use this skill when the user asks to review, audit, proofread, or produce a formal evaluation report for a degree thesis, dissertation, academic paper, or thesis PDF/DOCX, especially when they require checklist-based, line-by-line, evidence-grounded comments, PDF page locations, external fact verification, MinerU/VLM parsing, or a standardized Chinese 学位论文审阅报告. This capability is jointly built with Giiisp.

person作者: yxxxxxy5hubgithub
open_in_new仓库download下载资源包

Thesis Audit Reviewer

Purpose

Produce standardized, evidence-grounded thesis audit reports through a repeatable audit workflow. This skill is an audit operating system, not a one-shot prompt for writing comments.

Use this skill for Chinese or bilingual thesis review tasks involving PDF/DOCX papers, self-check lists, problem summaries, external facts, formulas, tables, references, or supervisor-style comments.

Default review basis: use references/default_review_sources.md, derived from the user's 学位论文自检清单.docx and 学位论文问题汇总.docx, unless the user provides a newer checklist or explicitly asks for a different standard.

Default delivery mode: PDF input produces a PDF audit report; DOC/DOCX input produces a commented DOCX. Preserve Markdown, issue database, review matrix, factcheck, and coverage artifacts for traceability.

Non-Negotiable Standard

Every finding needs:

  • precise location: PDF physical page, printed page/chapter if available, object type if available
  • original excerpt: short, necessary quote only
  • audit comment: what is wrong, in reviewer language
  • evidence basis: checklist, paper context, external source, PDF image, or academic norm
  • modification requirement: concrete author action
  • priority: 必须修改 / 建议修改 / 格式修正
  • certainty: 确认问题 / 疑似问题 / 需作者补充材料 / 无法判断

Never deliver only a summary when the user asks for a formal audit. Write in 批注和审核语言, for example: "该处……" "应补充……" "建议作者……" "不宜……".

If a conclusion lacks location, excerpt, and basis, keep it in the work notes as a lead; do not put it in the formal report.

Operating Model

Adopt the mature-skill pattern from prior document-audit work:

  • Treat the report as a product generated from work artifacts, not as the audit itself.
  • Build the audit denominator first: pages, sections, figures, tables, formulas, references, data facts, strong claims, and policy suggestions.
  • Use deterministic tools for parsing, splitting, scaffolding, rendering, and report validation.
  • Use AI judgment for academic reasoning, evidence chain evaluation, overclaim detection, and reviewer-language drafting.
  • Record pass/blocked/unknown states, not only discovered issues.
  • Add a fact-audit layer before normative review: identify methods, verifiable claims, method premises, internally repeated numbers, and author-computed core results.
  • Finish only after the completion gate passes or after residual risks are explicitly listed.

Workflow

  1. Confirm Scope

    • Identify source paper(s), checklist files, reference problem files, and requested output format.
    • If no alternative checklist/problem summary is supplied, use references/default_review_sources.md as the audit basis.
    • Determine input/output mode using references/input_output_policy.md: PDF -> PDF report; DOC/DOCX -> commented DOCX.
    • Prioritize one paper deeply. For multiple papers, create independent per-paper workspaces and do not weaken single-paper gates.
    • If the user asks to use external fact verification, browse and cite sources.
    • If the user asks for a Skill/process discussion, do not run the full audit.
    • If the user wants DOCX comments or redlines, use the Documents skill and keep this skill as the audit logic.

  2. Create Project Work Area

    • Use a subfolder under the current project, e.g. subprojects/thesis_audit_<date>/.
    • Keep intermediate artifacts: source manifest, parsed pages, issue database, final reports.
    • Do not store API tokens or private credentials in files.
    • Prefer scripts/init_audit_workspace.py to create the standard directory and empty ledgers.

  3. Parse Paper

    • Default scenario is ordinary thesis material that may be parsed by third-party tools; for PDF, prefer MinerU online VLM parsing when available.
    • If the user marks the paper confidential, unpublished, restricted, or not uploadable, do not use online parsing; switch to local parsing or ask for permission.
    • Use scripts/mineru_vlm_extract.py to upload the full PDF and download results when MinerU is available and upload is allowed.
    • If MinerU is unavailable, unconfigured, timed out, or upload is not allowed, run scripts/pdf_local_fallback_extract.py first. It tries local pymupdf4llm Markdown extraction, then local PyMuPDF/fitz page text extraction.
    • Use scripts/split_mineru_vlm_pages.py to create page-level object files after MinerU parsing.
    • Always verify high-risk findings against the original PDF image or rendered page; parsed text is evidence support, not final truth.
    • For DOCX, use the Documents skill or direct OOXML inspection when comments/redlines are requested.
    • For DOC/DOCX, run scripts/docx_integrity_scan.py and read references/docx_integrity_gate.md; do not rely on python-docx paragraph.text or long command-output previews as full-text coverage.

  4. Build Audit Denominator

    • Create source manifest, page index, structure map, object ledger, fact ledger, and reference ledger before drafting findings.
    • Index every page, section, table, figure, formula, reference entry, data source, method, verifiable claim, strong conclusion, and policy recommendation that is visible enough to audit.
    • Mark low-quality extraction, ambiguous page objects, and missing pages as blocked; do not silently skip them.

  5. Build Method and Claim Ledgers

    • Read references/method_and_fact_audit.md.
    • Identify every substantive research method and create a method profile: role, data, assumptions, parameters, core outputs, and whether results support main conclusions.
    • Run scripts/scan_verifiable_claims.py on extracted text where available, then let AI clean and complete the ledger.
    • Register all numbers, percentages, money amounts, dates, sample sizes, method windows, cross references, data-source claims, and author-computed core results.
    • Decide each claim's verification action: internal crosscheck, external factcheck, method premise check, minimal recalculation, author source required, or blocked.

  6. Build Review Coverage

    • Read checklist/reference docs and map them to review categories.
    • Use the taxonomy in references/issue_taxonomy.md.
    • For each checked area, record either findings or checked-no-issue notes in the work files when coverage matters.
    • Use statuses: pass, issue, needs_factcheck, needs_internal_crosscheck, needs_method_premise_check, needs_recalculation, needs_author_source, not_applicable, blocked.
    • Do not use pass unless the required verification action for that object has actually been completed.

  7. Audit High-Risk Areas First

    • Abstract and English abstract.
    • Table of contents, figure/table lists, numbering, cross references.
    • Research question, title concept alignment, chapter progression.
    • Literature review coverage and critique.
    • Research design, interviews, samples, coding, variables, formulas, models.
    • Method premises, data sources, calculation consistency, reproducibility, and author-computed core results.
    • Conclusions, policy suggestions, overclaims.
    • References, duplicate entries, missing fields, source suitability.

  8. Verify Facts and Reproducibility

    • Browse when facts may be current, contested, or externally checkable.
    • Prefer primary/official sources for company facts, policy facts, dates, products, and standards.
    • Separate “verified”, “partly verified”, and “not verified” in the report.
    • Record facts as you read. Do not reconstruct the fact list from memory at the end.
    • For author-computed core results, perform the strongest feasible check: internal table consistency, formula substitution, public-data minimal recalculation, or author-source-required.
    • Do not mark a result as needs_author_source until internal crosscheck, public-source lookup, and minimal recalculation feasibility have been considered.

  9. Build Issue Database

    • Promote only evidence-backed findings into the issue database.
    • Deduplicate, classify, and assign severity before writing the final report.
    • Keep unresolved leads, blocked evidence, and author-source-needed items separate from confirmed problems.

  10. Write the Report

  • Use references/standard_report_template.md.
  • Use references/comment_language.md for tone and wording.
  • Generate Markdown first. If requested or useful, use scripts/render_md_report_pdf.py to create a PDF copy.
  1. Run Completion Gate
  • Read references/completion_gate.md.
  • Run scripts/validate_audit_report.py on the Markdown report before claiming completion.
  • If validation fails, fix the report or explicitly state which gate is blocked and why.
  1. Document the Work
  • If inside a project, update existing progress/findings/docs with factual notes: what was parsed, what was verified, output paths, pitfalls.
  • Do not create unrelated README or personal notes inside the Skill.

When to Load References

  • Load references/audit_operating_protocol.md before planning or executing a full audit.
  • Load references/default_review_sources.md before building the review matrix unless the user supplied a replacement checklist.
  • Load references/input_output_policy.md before choosing the final deliverable.
  • Load references/docx_integrity_gate.md for DOC/DOCX inputs or when formulas/images may be lost.
  • Load references/method_and_fact_audit.md before building method profiles, claim ledgers, fact checks, or reproducibility checks.
  • Load references/work_products.md when creating workspace files, ledgers, matrices, or issue databases.
  • Load references/completion_gate.md before final delivery.
  • Load references/standard_report_template.md before writing the final report.
  • Load references/comment_language.md when drafting comments.
  • Load references/issue_taxonomy.md when planning coverage or classifying findings.
  • Load references/evidence_rules.md when deciding whether a statement is sufficiently supported.

Script Quick Use

python scripts/doctor.py
python scripts/init_audit_workspace.py --out subprojects/thesis_audit_YYYY_MM_DD --paper-id paper01 --title "论文题名" --source-file paper.pdf
# DOCX input example:
# python scripts/init_audit_workspace.py --out subprojects/thesis_audit_YYYY_MM_DD --paper-id paper01 --title "论文题名" --source-file paper.docx
python scripts/docx_integrity_scan.py --docx paper.docx --markdown-output work/paper01/docx_integrity.md --json-output work/paper01/docx_integrity.json
python scripts/scan_verifiable_claims.py --input work/paper01/extracted_text.md --output work/paper01/05_verifiable_claims.csv
python scripts/mineru_vlm_extract.py --file paper.pdf --out work/mineru_vlm --model-version vlm
python scripts/split_mineru_vlm_pages.py --content-list work/mineru_vlm/<extract_dir>/content_list_v2.json --out work/vlm_pages
python scripts/pdf_local_fallback_extract.py --file paper.pdf --out work/pdf_fallback
python scripts/render_md_report_pdf.py --input outputs/paper01/审查报告.md --output outputs/paper01/审查报告.pdf
python scripts/validate_audit_report.py --report outputs/paper01/审查报告.md --strict

The MinerU script reads the token from MINERU_API_TOKEN, hidden TTY input, or stdin. If the user has no token, point them to https://mineru.net/apiManage/token to register and create one. Never write the token into a command, report, or repository file. The local PDF fallback script does not need a token; treat its output as lower confidence than MinerU for scanned PDFs, formulas, complex tables, multi-column layout, headers/footers, and split reference lists.

Completion Definition

For a formal thesis audit, completion requires:

  • source and parsing status recorded
  • default or user-supplied review basis recorded
  • input/output mode recorded: PDF report or commented DOCX
  • DOCX integrity gate completed when input is DOC/DOCX, especially formula/image visibility
  • object denominator created or residual gaps listed
  • method profile and verifiable claim ledger created or explicitly blocked
  • checklist coverage recorded, including pass and blocked rows
  • all formal findings traceable to issue database entries
  • external facts, internal numeric consistency, method premises, and feasible recalculations checked or marked with the correct residual status
  • high-risk formulas, tables, references, and numbering checked against PDF image when needed
  • final report follows the standard template and passes validation
  • project progress/findings documentation updated when working inside a project

For batch work, completion means every single paper satisfies the single-paper gate first, then the batch summary is generated.