Token导航 LogoToken导航

Agent Skill · 研究检索

paper-audit(纸质审核)

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

paper-audit 是研究检索类 Agent Skill,可用宿主为 Codex、Claude、Cursor、Gemini CLI,通过GitHub 仓库获取,权限为只读;许可证信息还不明确,第三方扫描有提醒项,按安装量在研究检索类的 73,675 个 Skill 里排第 11,143。

总安装 11,643周安装 471GitHub Stars 164下载 3,655核验 2026-05-01

安装说明

本站只整理中文说明,不托管安装包,也不代用户安装。
GitHub
许可证
unknown

安装方式

通过对话安装

复制提示词发给支持本地命令或 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

这个 Skill 是做什么的

研究检索类 Skill 主要解决「找资料、核对事实、把来源整理清楚」的问题,通常会让助手先检索再总结。

paper-audit 用于辅助安全审计与权限检查,识别凭据风险和认证漏洞。适合梳理敏感配置、分析鉴权逻辑或生成安全复核清单。通过 GitHub 安装,使用 npx skills add 命令添加技能。输出不能直接作为最终结论,涉及密钥或生产系统时应先确认操作边界。

适用宿主包括 Codex、Claude、Cursor、Gemini CLI,接入前应确认版本、权限和运行环境要求。

来源仓库内路径:skills/paper-audit

上手步骤

4 步
  1. 1

    确认自己的宿主工具

    公开资料标注支持 Codex、Claude、Cursor、Gemini CLI;先确认自己用的是其中之一,再按对应工具的 Skills 目录放置。

  2. 2

    拿到安装命令

    可以直接复制的命令是 npx skills add https://github.com/bahayonghang/academic-writing-skills --skill p…;命令里的占位符换成自己的路径或密钥再执行。

  3. 3

    安装后重启宿主

    命令执行完要完全退出宿主工具再打开,让新装的 Skill 被重新扫描到,否则列表里可能看不到。

  4. 4

    按最小权限试用

    它标注为只读,先用只读任务试一次,确认行为符合预期再扩大使用范围。

常见问题

6 条

paper-audit 怎么安装?

在终端执行 npx skills add https://github.com/bahayonghang/academic-writing-skills --skill paper-audit。装完完全退出宿主工具再打开,让它重新扫描本地 Skill。

paper-audit 支持哪些 AI 工具?

公开资料标注支持 Codex、Claude、Cursor、Gemini CLI。其他工具只要能读取本地 Skill 目录,一般也能手动放进去,但要自己确认触发方式是否一致。

paper-audit 需要什么权限?

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

paper-audit 是免费的吗?

公开资料没有标注明确许可证,收费和商用限制都无法确认。正式使用前请到来源仓库核对授权说明。

paper-audit 用的人多吗?

公开数据是累计安装 11,643 次,近一周安装 471 次,下载 3,655 次,GitHub 164 星。这些数字来自第三方目录统计,只能当作热度参考,不代表质量或安全性。

paper-audit 安全吗?

第三方扫描有提醒项,说明存在需要人工确认的行为。安装前请打开源码看清它读了什么、联网到哪里。

值得选的地方和要先想清楚的地方

值得选的地方

  • 同时适配 4 种工具,换客户端不用重新找替代品。
  • 标注为只读权限,试用阶段不容易误改本地文件。

先想清楚的地方

  • 许可证没有明确标注,能不能商用、能不能再分发都不确定。
  • 第三方扫描存在提醒项或未通过项,需要人工逐条确认。
  • 第三方目录整理,版本更新和行为细节以来源仓库为准。

适不适合你

更适合

  • 已经在用 Codex,想直接扩展它能力的人。
  • 需要处理研究检索类任务、又不想每次都手写提示词的人。
  • 只想先试试效果、不希望它改动本地文件的人。

不太适合

  • 需要明确授权才能用到公司项目里的场景。
  • 需要厂商级技术支持和 SLA 的生产系统。

研究检索类 Skill 对比

6 个同类
Skill总安装GitHub 星权限许可证扫描
find-skills

寻找技能 · Codex、Claude

31,199,81316,486操作浏览器MIT有提醒
self-improving-agent

自我改进 Agent · OpenClaw

16,464,0023,396接触敏感数据MIT-0通过
soultrace

灵魂追踪 · Codex、Claude

7,588,94412需要联网未明确有提醒
self-improving

自我完善 · OpenClaw

6,829,2841,046需要联网MIT-0通过
microsoft-foundry

微软代工厂 · Codex、Claude

6,614,144764调用外部服务未明确有提醒
paper-audit

纸质审核 · 本页

11,643164只读未明确有提醒

按安装量取同分类前几名;数字来自第三方目录统计,只作热度参考,不代表质量结论。

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

平台分布

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 的任务。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。来源安全扫描存在提醒或未通过项,安装前请自行复核。目前只有一个公开来源,建议同时核对源仓库。

继续浏览同类 Skills