메뉴
在执行 ≥ 30 条目的批量核查 / 批量修改任务（引用核查、术语一致性检查、格式统一、文献元数据补齐）时， 必须采用"派多个 Agent 并行 + 每个 Agent 输出 JSON + 主进程汇总落盘 + 分批断点续跑"的标准模式， 不得在主会话里串行单线程跑全量。 Use when 任务规模 ≥ 30，涉及对独立条目的同质操作（每个条目处理逻辑相同、之间无依赖）。
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Use when designing, restructuring, or auditing manuscript figures and you need to define one main claim per figure, assign panel roles, align legends with the text, or decide what belongs in main figures versus supplement.
Use when checking manuscript citations, bibliography hygiene, DOI or PMID completeness, placeholder references, or BibTeX consistency before submission or revision.
Use when acting as a journal or grant reviewer and writing formal reviewer-side evaluations focused on methodology, statistics, reporting standards, reproducibility, and constructive feedback.
Workflow 3: Full paper writing pipeline. Orchestrates paper-plan → paper-figure → figure-spec/paper-illustration/mermaid-diagram → paper-write → paper-compile → auto-paper-improvement-loop to go from a narrative report to a polished PDF. At `— effort: max | beast` (or explicit `— assurance: submission`), Phase 6 gates the Final Report on `tools/verify_paper_audits.sh`; the PDF is labelled `submission-ready` only when the external verifier is green. Use when user says "写论文全流程", "write paper pipeline", "从报告到PDF", "paper writing", or wants the complete paper generation workflow.
Polish, restructure, or translate academic prose into Nature-leaning English using the paper-architecture and writing-strategy principles from Scientific English Writing & Communication, with phrase-level support from Academic Phrasebank. Use whenever the user asks to polish a manuscript paragraph, abstract, introduction, results, discussion, conclusion, title, methods section, or Chinese academic draft for publication-quality English.
Use when writing or revising scientific manuscripts, abstracts, figures, or references for journal submission and you need full-paragraph prose, scientific structure, citation-style guidance, or reporting-guideline support.
| name | paper-parallel-audit |
| description | 在执行 ≥ 30 条目的批量核查 / 批量修改任务（引用核查、术语一致性检查、格式统一、文献元数据补齐）时， 必须采用"派多个 Agent 并行 + 每个 Agent 输出 JSON + 主进程汇总落盘 + 分批断点续跑"的标准模式， 不得在主会话里串行单线程跑全量。 Use when 任务规模 ≥ 30，涉及对独立条目的同质操作（每个条目处理逻辑相同、之间无依赖）。 |
156 篇引用串行核查 ≈ 5 小时 + 中间挂了从头来。 3 个 Agent 并行 + 每个 50 篇 + JSON 落盘 ≈ 1 小时 + 任意一个挂了只重跑那一个。
批量任务的瓶颈不是 AI 的速度，是"挂了从头来"的恐惧。 并行 + 落盘 = 把恐惧拆成可控的小块。
满足全部 → 触发：
paper-pilot-before-batch 跑过样本，逻辑确认无误任意一条不满足 → 不并行，老老实实串行 + 落盘（仍然要落盘）。
total = 156 条
shard_size = 50（按 Agent 数倒推）
shards = [0:50, 50:100, 100:156]
每个 Agent 处理自己的分片，输出：
{
"shard_id": "0-50",
"total": 50,
"results": [
{"item_id": 1, "status": "pass", "issue": null},
{"item_id": 2, "status": "fail", "issue": "作者名拼写错误", "suggestion": "..."}
],
"completed_at": "<ISO 8601 timestamp>"
}
# 等所有 Agent 返回后
python merge_shards.py shard-*.json > audit_report.json
检测到 ≥ 30 条目的同质批量任务
│
▼
确认已经跑过 paper-pilot-before-batch
│
▼
分片：N 个 Agent，每个 ≤ 50 条
│
▼
告诉用户：「派 N 个 Agent 并行，每个负责 [区间]，
各自落盘 JSON。预计 [时间]，挂了只重跑挂掉的分片。」
│
▼
用 Task 工具派 Agent（subagent_type 选 general-purpose）
单条消息里多个 Task 调用 = 真正并行
│
▼
等所有 Agent 返回 → 汇总 JSON → 给用户报告
你是引用核查 Agent，负责本批 [分片区间]。
任务：核查每条引用的 [核查标准列表]。
输入：[引用列表 / 文件路径]
输出：JSON 文件，路径 `shard-<分片 ID>.json`，格式：
{
"shard_id": "...",
"total": N,
"results": [
{"item_id": ..., "status": "pass|fail", "issue": "...", "suggestion": "..."}
],
"completed_at": "..."
}
完成后只返回一句话：「分片 X 完成，pass M 条，fail K 条，已落盘 shard-X.json」。
不要把详细结果写在回复里——一律只在 JSON 里。
用户：「把这 156 条引用核查一遍。」
错误做法：在主会话里串行跑——
正确做法：分 3 片 → 派 3 个 Agent → 各自 JSON 落盘 → 主进程汇总 → 用户拿到完整报告。
| 念头 | 现实 |
|---|---|
| "派 Agent 太重，自己串行更直接" | 串行第 80 条挂掉时你会回来读这个表 |
| "我能边跑边把结果记在脑子里" | 你不能。这是惨案 9 的根因 |
| "JSON 太麻烦，纯文本 markdown 就行" | 汇总时要 dedupe / 排序 / filter，markdown 干不了 |
| "派 1 个 Agent 跑 156 条也是并行" | 不是，那只是把串行搬到了子进程里，还是从头来 |
| "落盘的 JSON 占空间" | 一个 shard JSON 几 KB，挂了能省小时级时间 |
paper-pilot-before-batchpaper-protect-terminologypaper-verify-before-handoff 自查报告《Claude Code 科研手记》§4.2「批量文献核查」、§10.2「引用核查的并行实战」