Token导航 LogoToken导航TokenDH.com
研究检索只读github未标认证来源可访问许可证需确认审计提醒

paper-audit纸质审核

Agent Skill

用于辅助安全审计、权限检查、凭据风险、认证流程和常见漏洞排查。它适合让 Agent 梳理敏感配置、检查依赖风险、分析鉴权逻辑或生成安全复核清单。使用时不能把工具输出直接当最终结论,涉及密钥、令牌、用户数据或生产系统时,应先确认最小权限、脱敏方式和操作边界。

总安装

11,643

周安装

471

GitHub Stars

164

下载量

3,655
CodexClaudeCursorGemini CLI

安装说明

本站只整理中文说明和来源信息,不托管安装包,也不代用户安装。

GitHub

来源数

2

许可证

unknown

最后核验

2026-05-01

来源状态

来源可访问

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:paper-audit(纸质审核)
来源仓库:https://github.com/bahayonghang/academic-writing-skills
仓库路径:skills/paper-audit
安装命令:
npx skills add https://github.com/bahayonghang/academic-writing-skills --skill paper-audit
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 npx skills 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

skills.shnpx skills
npx skills add https://github.com/bahayonghang/academic-writing-skills --skill paper-audit

简介

paper-audit 用于辅助安全审计与权限检查,识别凭据风险和认证漏洞。

  • 适合梳理敏感配置、分析鉴权逻辑或生成安全复核清单。
  • 通过 GitHub 安装,使用 npx skills add 命令添加技能。
  • 输出不能直接作为最终结论,涉及密钥或生产系统时应先确认操作边界。
  • 适用宿主包括 Codex、Claude、Cursor、Gemini CLI,接入前应确认版本、权限和运行环境要求。

SKILL.md

Paper Audit Skill v4.5

paper-audit is now deep-review-first. Its core job is to behave like a serious reviewer: find technical, methodological, claim-level, and cross-section issues; keep script-backed findings separate from reviewer judgment; and return a structured issue bundle plus a revision roadmap.

Version 4.5 adds a script-backed PRESUBMISSION layer for final-week mechanical checks: em dashes, AI-tone term frequency, abstract completeness, LaTeX citation/label/equation hygiene, paragraph-shape weak signals, and concrete captions. This layer supports existing modes; it is not a separate public mode.

Use it for audit and review. Do not use it as the first tool for source editing, sentence rewriting, or build fixing.

What This Skill Produces

  • quick-audit: fast submission-readiness screen with script-backed findings, including PRESUBMISSION
  • deep-review: reviewer-style structured issue bundle with major/moderate/minor findings
  • gate: PASS/FAIL decision calibrated for submission blockers; PRESUBMISSION Major/Minor findings remain advisory
  • re-audit: compare current issue bundle against a previous audit, including mechanical regression findings
  • polish: precheck-only handoff into a polishing workflow

The primary product is no longer just a score. For deep-review, the main outputs are:

  • final_issues.json
  • overall_assessment.txt
  • review_report.md
  • peer_review_report.md
  • revision_roadmap.md

Do Not Use

  • direct source surgery on .tex / .typ
  • compilation debugging as the main task
  • free-form literature survey writing
  • paragraph-level related-work rewriting
  • cosmetic grammar cleanup without an audit goal

Critical Rules

  • Never rewrite the paper source unless the user explicitly switches to an editing skill.
  • Never fabricate references, baselines, or reviewer evidence.
  • Always distinguish [Script] from [LLM] findings.
  • Always anchor reviewer findings to a quote, section, or exact textual location.
  • Be conservative with OCR noise, formatting quirks, and obvious copy-editing trivia.
  • Review like a careful reader: understand the author's intended meaning before flagging an issue.
  • For literature findings, judge whether the gap is evidence-backed and fairly positioned; do not rewrite the prose inside paper-audit.
  • For PRESUBMISSION, map CRITICAL/MAJOR/MINOR to Critical/Major/Minor script severities; only Critical or failed checklist items can fail gate.
  • In PDF mode, do not guess source-only hygiene. Report text-proven items and note that LaTeX/Typst source checks were skipped.

Mode Selection

Requested intentMode
"check my paper", "quick audit", "submission readiness", "pre-submission review", "投稿前检查"quick-audit
"review my paper", "simulate peer review", "harsh review", "deep review"deep-review
"is this ready to submit", "gate this submission", "blockers only"gate
"did I fix these issues", "re-audit", "compare against old review"re-audit
"polish the writing, but only if safe"polish

Legacy aliases still work for one compatibility cycle:

  • self-check -> quick-audit
  • review -> deep-review

Input Resolution

  • Resolve the paper path first and keep the user-provided relative path when it already works.
  • Infer the paper format from the extension (.tex, .typ, .pdf) before choosing checks or parser behavior.
  • Infer report-style from the request: use peer-review when the user asks for journal-review prose such as Summary / Major Issues / Minor Issues / Recommendation; otherwise default to deep-review.
  • Infer output language from the request first, then fall back to the paper language when the request is ambiguous.
  • For re-audit, require --previous-report PATH. If it is missing, stop immediately and ask only for that path instead of running a fresh audit.
  • State the locked mode, report style, focus, language, and venue (if known) before running commands when any of them were inferred rather than explicitly provided.

Presentation Surface

  • deep-review: make the issue bundle, revision roadmap, and artifact paths the primary summary surface. It is acceptable to mention schema-level fields such as review lanes or source provenance here.
  • peer-review: make reviewer prose the primary summary surface. Do not expose raw internal keys like review_lane, source_kind, or root_cause_key in the top-level prose summary; keep them inside the artifact bundle.
  • gate: show verdict first, then EIC screening, then blockers, then advisory recommendations.
  • re-audit: show status buckets (FULLY_ADDRESSED, PARTIALLY_ADDRESSED, NOT_ADDRESSED, NEW) before any new audit commentary.

Committee Focus Routing (deep-review)

For deep-review, use the Academic Pre-Review Committee by default. This is a 5-role review pass:

  1. Editor (desk-reject screen)
  2. Reviewer 1 (theory contribution)
  3. Reviewer 3 (literature dialogue / gap)
  4. Reviewer 2 (methodology transparency)
  5. Reviewer 4 (logic chain)

If the user requests a single dimension, run only the matching committee role(s).

Literature focus means:

  • verify whether the literature is thematically synthesized or merely enumerated
  • verify whether contradictions are acknowledged rather than flattened
  • verify whether the claimed gap is genuine instead of manufactured by selective citation
  • do not rewrite the related-work prose; hand that off to the format-specific writing skill when needed

If --focus... is provided, it overrides keyword inference:

  • --focus full (default)
  • --focus editor|theory|literature|methodology|logic

Keyword map (English + Chinese):

  • editor: "desk reject", "pre-screen", "editor", "EIC", "主编", "预筛", "初筛"
  • theory: "theory", "contribution", "novelty", "theoretical dialogue", "理论", "贡献", "创新性"
  • literature: "related work", "literature", "research gap", "citation", "文献", "综述", "Research Gap", "引用", "gap is fake", "选择性引用"
  • methodology: "methods", "sample", "coding", "data", "design", "SRQR", "方法", "样本", "编码", "数据", "研究设计", "透明度"
  • logic: "logic", "argument", "causal", "structure", "论证", "因果", "逻辑", "结构"

Output language: match the user's request language. If ambiguous, match the paper language.

Review Standard

Read these references before running reviewer-style work:

  1. references/REVIEW_CRITERIA.md
  2. references/DEEP_REVIEW_CRITERIA.md
  3. references/CHECKLIST.md
  4. references/CONSOLIDATION_RULES.md
  5. references/ISSUE_SCHEMA.md
  6. references/PRE_SUBMISSION_RULES.md

The deep-review workflow uses a 16-part issue taxonomy:

  1. formula / derivation errors
  2. notation inconsistency
  3. prose vs formal object mismatch
  4. numerical inconsistency
  5. missing justification
  6. overclaim or claim inaccuracy
  7. ambiguity that can mislead a careful reader
  8. underspecified methods / missing information
  9. internal contradiction
  10. self-consistency of standards
  11. table structure violations
  12. abstract structural incompleteness
  13. theory contribution deficiency
  14. qualitative methodology opacity
  15. pseudo-innovation / straw man
  16. paragraph-level argument incoherence

Workflow

Common Step 0

Parse $ARGUMENTS, lock the paper path, and infer the mode if the user did not provide one. State the inferred mode before running commands if you had to infer it.

quick-audit

  1. Run: uv run python -B "$SKILL_DIR/scripts/audit.py" <paper> --mode quick-audit...
  2. Present a concise report:

- Submission Blockers first - then Quality Improvements - then checklist items - call out PRESUBMISSION mechanical findings separately when they matter - mark quick-audit findings with [Script] provenance

  1. If the user clearly wants reviewer-depth critique after the quick screen, escalate to deep-review.

deep-review

Use this as the default reviewer-style path.

If the user explicitly wants a submission-style reviewer report (for example: “SCI reviewer”, “journal review report”, “Summary / Major Issues / Minor Issues / Recommendation”, or “审稿报告”), keep the same deep-review evidence pipeline but make peer_review_report.md the Primary View in the combined CLI summary while keeping review_report.md as the richer evidence bundle. In this path, keep raw schema fields inside artifacts rather than the reviewer-facing prose.

Phase 1: Prepare workspace

Run:

uv run python -B "$SKILL_DIR/scripts/prepare_review_workspace.py" <paper> --output-dir ./review_results

This creates:

  • full_text.md
  • metadata.json
  • section_index.json
  • claim_map.json
  • paper_summary.md
  • sections/*.md
  • comments/
  • references/ (minimal copies for reviewer agents)
  • committee/ (committee reviewer artifacts)

Phase 2: Phase 0 automated audit

Run:

uv run python -B "$SKILL_DIR/scripts/audit.py" <paper> --mode deep-review ...

Treat this as Phase 0 only. It supplies script-backed context and scores, not the final review. PRESUBMISSION findings stay here for focused theory/literature/methodology/logic reviews; only full/editor deep-review can promote high-signal mechanical findings into the pre_submission_readiness lane.

Phase 3: Committee + Review Lanes

Phase 3A: Academic Pre-Review Committee (default)

Decide committee focus:

  • If --focus... is provided, use it.
  • Otherwise infer from the user request using the keyword map in "Committee Focus Routing".
  • If nothing matches, default to full (all five roles).

Dispatch the committee reviewers (in this exact order) and have them write artifacts into the workspace:

  1. agents/committee_editor_agent.md

- write: committee/editor.md - write: comments/committee_editor.json

  1. agents/committee_theory_agent.md

- write: committee/theory.md - write: comments/committee_theory.json

  1. agents/committee_literature_agent.md

- write: committee/literature.md - write: comments/committee_literature.json

  1. agents/committee_methodology_agent.md

- write: committee/methodology.md - write: comments/committee_methodology.json

  1. agents/committee_logic_agent.md

- write: committee/logic.md - write: comments/committee_logic.json

If subagents are unavailable, run the committee reviewers inline, but keep the same file outputs.

Then write: committee/consensus.md

  • include: overall score (1-10), ordered priorities, and the top 3 issues to fix first
  • scoring formula:

- start at 9.0 - subtract: 1.5 * (# major) + 0.7 * (# moderate) + 0.2 * (# minor) - floor at 1.0 - if Editor verdict is Desk Reject, cap at 4.0

Note: render_deep_review_report.py automatically embeds committee/*.md into review_report.md when present.

Phase 3B: Section and cross-cutting review lanes (coverage)

Read:

  • references/SUBAGENT_TEMPLATES.md
  • references/REVIEW_LANE_GUIDE.md

Then dispatch reviewer tasks for:

  • section lanes

- introduction / related work - methods - results - discussion / conclusion - appendix, if present

  • cross-cutting lanes

- claims vs evidence - notation and numeric consistency - evaluation fairness and reproducibility - self-standard consistency - prior-art and novelty grounding - pre-submission readiness (full/editor focus only)

Each lane writes a JSON array into comments/.

If subagents are unavailable, use the built-in deterministic fallback lane pass in scripts/audit.py so the workflow still writes lane-compatible JSON into comments/ before consolidation.

Phase 4: Consolidation

Run:

uv run python -B "$SKILL_DIR/scripts/consolidate_review_findings.py" <review_dir>
uv run python -B "$SKILL_DIR/scripts/verify_quotes.py" <review_dir> --write-back
uv run python -B "$SKILL_DIR/scripts/render_deep_review_report.py" <review_dir>

Consolidation rules:

  • merge exact duplicates
  • keep distinct paper-level consequences separate even if they share a root cause
  • preserve singleton findings unless clearly false positive
  • assign comment_type, severity, confidence, and root_cause_key

Phase 5: Present result

Summarize:

  • 1 short paragraph overall assessment
  • counts of major / moderate / minor issues
  • 3 highest-priority revision items
  • identify the Primary View selected by --report-style
  • path to review_report.md, peer_review_report.md, and final_issues.json

gate

  1. Run: uv run python -B "$SKILL_DIR/scripts/audit.py" <paper> --mode gate...
  2. EIC Screening (Phase 0.5): Read agents/editor_in_chief_agent.md and perform the editor-in-chief desk-reject screening on the paper's title, abstract, and introduction. This evaluates pitch quality, venue fit, fatal flaws, and presentation baseline. A desk-reject verdict is a gate blocker.
  3. Report PASS/FAIL.
  4. Present EIC screening results first (verdict + score + justification).
  5. List blockers next.
  6. Keep advisory items separate from blockers.
  7. Keep PRESUBMISSION Major/Minor items advisory; only Critical mechanical findings can block the gate.
  8. For IEEE pseudocode checks, make it explicit which issues are mandatory and which are only IEEE-safe recommendations.

re-audit

  1. Requires --previous-report PATH.
  2. Run: uv run python -B "$SKILL_DIR/scripts/audit.py" <paper> --mode re-audit --previous-report <path>...
  3. If both old and new final_issues.json bundles are available, also run: uv run python -B "$SKILL_DIR/scripts/diff_review_issues.py" <old_final_issues.json> <new_final_issues.json>
  4. Present:

- root-cause-aware status labels: FULLY_ADDRESSED, PARTIALLY_ADDRESSED, NOT_ADDRESSED, NEW - use structured prior issue bundles when available, but still accept Markdown previous reports

polish

  1. Run the audit precheck: uv run python -B "$SKILL_DIR/scripts/audit.py" <paper> --mode polish...
  2. If blockers exist, stop and report them.
  3. Only proceed into polishing if the precheck is safe.

Output Contract

For deep-review, the final issue schema is:

{
  "title": "short issue title",
  "quote": "exact quote from paper",
  "explanation": "why this matters and what remains problematic",
  "comment_type": "methodology|claim_accuracy|presentation|missing_information",
  "severity": "major|moderate|minor",
  "confidence": "high|medium|low",
  "source_kind": "script|llm",
  "source_section": "methods",
  "related_sections": ["results", "appendix"],
  "root_cause_key": "shared-normalized-key",
  "review_lane": "claims_vs_evidence",
  "gate_blocker": false,
  "quote_verified": true
}

Always prefer:

  • exact quotes over vague paraphrase
  • evidence-backed findings over style commentary
  • issue bundle + roadmap over raw script dumps

References

FilePurpose
references/REVIEW_CRITERIA.mdtop-level audit scoring and mapping
references/DEEP_REVIEW_CRITERIA.mddeep-review-specific issue taxonomy (16 dimensions) and leniency rules
references/CONSOLIDATION_RULES.mddeduplication and root-cause merge policy
references/ISSUE_SCHEMA.mdcanonical JSON schema
references/REVIEW_LANE_GUIDE.mdsection lanes and cross-cutting lanes
references/PRE_SUBMISSION_RULES.mdfinal-week mechanical audit rules, severity mapping, and PDF/source limits
references/SUBAGENT_TEMPLATES.mdreviewer task templates
references/QUICK_REFERENCE.mdCLI and mode cheat sheet

Scripts

ScriptPurpose
scripts/audit.pyPhase 0 audit and mode entrypoint
scripts/pre_submission_check.pydeterministic PRESUBMISSION mechanical audit layer
scripts/prepare_review_workspace.pycreate deep-review workspace
scripts/build_claim_map.pyextract headline claims and closure targets
scripts/consolidate_review_findings.pydeduplicate comment JSONs
scripts/verify_quotes.pyverify exact quote presence
scripts/render_deep_review_report.pyrender final Markdown report
scripts/diff_review_issues.pycompare old vs new issue bundles

Reviewer Lanes

Committee agents (deep-review default):

  • committee_editor_agent.md
  • committee_theory_agent.md
  • committee_literature_agent.md
  • committee_methodology_agent.md
  • committee_logic_agent.md

Default deep-review lanes live in agents/:

  • section_reviewer_agent.md
  • claims_evidence_reviewer_agent.md
  • notation_consistency_reviewer_agent.md
  • evaluation_fairness_reviewer_agent.md
  • self_consistency_reviewer_agent.md
  • prior_art_reviewer_agent.md
  • synthesis_agent.md
  • editor_in_chief_agent.md — EIC desk-reject screener (used in gate mode)

Specialized deep-review agents (read their files for activation criteria):

  • critical_reviewer_agent.md — devil's advocate with C3-C5 checks
  • domain_reviewer_agent.md — domain expertise with A1-A7 assessments
  • methodology_reviewer_agent.md — methodology rigor with B3-B10 checks
  • literature_reviewer_agent.md — evidence-based literature verification (optional, --literature-search)

Examples

  • “Review this manuscript like a serious conference reviewer and tell me the biggest validity risks.”
  • “Run a quick audit on paper.tex and tell me what blocks submission.”
  • “Gate this IEEE submission and separate blockers from recommendations.”
  • “Re-audit this revision against my previous report.”
  • “Audit only the literature positioning and tell me whether the claimed gap is real or fabricated by selective citation.”

适合场景

01

用户想查找某类 Agent Skill 时

02

需要根据任务场景推荐可安装能力包时

03

需要对比不同来源的安装命令和来源信息时

能力概览

能力 1

按任务关键词查找相关 Skills

能力 2

展示可复制的安装命令

能力 3

保留来源站点、仓库和原始说明,方便继续核验

能力 4

展示第三方安全扫描或审计结果

安装后应在对应宿主中按原始 README 的触发条件使用;具体调用方式请以来源页面和 README 为准。

平台分布

Codex

37.7%
按下载量换算1,378

Claude

29.32%
按下载量换算1,072

Cursor

19.16%
按下载量换算700

Gemini CLI

10.14%
按下载量换算371

安全审计

Gen Agent Trust Hub

通过

Socket

通过

Snyk

可疑

权限和风险

只读

该 Skill 主要提供规则、说明或参考内容,本身偏只读;真正读写文件、联网或执行命令仍取决于宿主 Agent 的任务。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。来源安全扫描存在 warning/failed 结果,不能写成本站确认安全。当前只有一个来源,正式发布前建议补源仓库或其他目录站核验。

来源信息

继续浏览同类 Skills