跳到主内容
智客 ZICQ

技能库 智客分类:Agent 工作流 nature-reviewer

自然审查员

Simulate Nature-style or general pre-submission peer review from the referee perspective, not an author rebuttal. Use for reviewer reports, mock peer review, manuscript critique, novelty/significance/technical-soundness assessment, 审稿人视角评估, 模拟审稿, 预审, 投稿前自审, 审稿意见模拟, or 帮我审一下论文. Produce evidence-grounded Major Concerns, Minor Comments, and blocking flags. For multiple reviewers, keep every reviewer mutually blind in a separate context, freeze all reports before comparison, and create any synthesis only afterward as a separate editor/author-facing artifact.

9333 安装量

官方网址:skills.sh

技能介绍

先看中文介绍;官方 description 原文单独保留,不改写 SKILL.md。

做什么

官方 description 用英文写明「自然审查员」做什么。中文介绍不改写这段原文,能力边界以文件结构与下方原文为准。

何时用

官方 description 未单独写出 Use when。按规范,代理会在用户任务与这段 description 的关键词匹配时激活本技能。

代理如何加载

按 Agent Skills 渐进披露:启动时只加载 name 与 description(约 100 token);任务匹配后才读入整份 SKILL.md 正文;scripts/、references/、assets/ 仅在需要时再读。 本文件正文结构:Nature Reviewer Assessment Skill、Default stance、Accepted inputs、Workflow、Output format、Red lines。 其中含规范建议的小节:分步指令。

文件分析

文件分析:除 SKILL.md 外,正文引用了 references/technical-concern-taxonomy.md、references/domain-specific-review-gates.md、references/source-basis.md、references/reviewer-workflow.md、references/review-axes.md,属于带资源的技能包,这些文件按需再读。

Nature Reviewer Assessment SkillDefault stanceAccepted inputsWorkflowOutput formatRed linesRelated filesSource hierarchy

来源分类:skills.sh agent-skill

SKILL.md 与 Agent 调用

官方规范 ↗
name
nature-reviewer
description
Simulate Nature-style or general pre-submission peer review from the referee perspective, not an author rebuttal. Use for reviewer reports, mock peer review, manuscript critique, novelty/significance/technical-soundness assessment, 审稿人视角评估, 模拟审稿, 预审, 投稿前自审, 审稿意见模拟, or 帮我审一下论文. Produce evidence-grounded Major Concerns, Minor Comments, and blocking flags. For multiple reviewers, keep every reviewer mutually blind in a separate context, freeze all reports before comparison, and create any synthesis only afterward as a separate editor/author-facing artifact.
  1. 发现技能客户端向 Agent 提供名称与描述目录。
  2. 匹配与调用用户指定或任务匹配后,载入 SKILL.md 指令。
  3. 按需加载按步骤读取参考文档、使用脚本与素材。
指令中引用的文件 · 5
  • references/technical-concern-taxonomy.md
  • references/domain-specific-review-gates.md
  • references/source-basis.md
  • references/reviewer-workflow.md
  • references/review-axes.md

以下路径提取自原文;文件是否齐全请以来源仓库中的完整目录为准。

具体调用语法与可用工具以目标 Agent 客户端为准。 查看调用机制说明 ↗

安装这个技能

Skills CLI ↗

先选择目标 Agent 和安装范围,保留技能包的附属文件,安装后检查客户端能否发现该技能。

该技能引用了附属文件,请从来源获取完整目录;仅复制 SKILL.md 可能缺少依赖。

交给 Agent 安装

复制安装指令给支持 Agent Skills 的代理,确认其中的目标目录与客户端匹配。

把 Agent Skill「nature-reviewer」安装到我的项目:SKILL.md 原文与官方 description 见 https://zicq.com/zh/skills/skl-ba6151e2a932c125-%E8%87%AA%E7%84%B6%E5%AE%A1%E6%9F%A5%E5%91%98.html
请存为 .cursor/skills/nature-reviewer/SKILL.md 或 .claude/skills/nature-reviewer/SKILL.md,frontmatter 的 name 与 description 保持原样,不要改写。
该技能还带 scripts/、references/、assets/ 等文件,请从 https://github.com/yuan1z0825/nature-skills 取完整目录,不要只建一个 SKILL.md。

GitHub 完整包 ↗

终端安装 · Skills CLI

需要 Node.js 与 npx。先查看仓库技能列表,确认实际名称。

npx skills add 'https://github.com/yuan1z0825/nature-skills' --list

npx skills add 'https://github.com/yuan1z0825/nature-skills' --skill 'nature-reviewer'

CLI 会交互选择目标 Agent,默认安装到项目;用户级安装使用 -g。先通过查看命令核对仓库内容,再用 npx skills list 检查已安装技能。

阅读排版
--- name: nature-reviewer description: >- Simulate Nature-style or general pre-submission peer review from the referee perspective, not an author rebuttal. Use for reviewer reports, mock peer review, manuscript critique, novelty/significance/technical-soundness assessment, 审稿人视角评估, 模拟审稿, 预审, 投稿前自审, 审稿意见模拟, or 帮我审一下论文. Produce evidence-grounded Major Concerns, Minor Comments, and blocking flags. For multiple reviewers, keep every reviewer mutually blind in a separate context, freeze all reports before comparison, and create any synthesis only afterward as a separate editor/author-facing artifact. --- # Nature Reviewer Assessment Skill Use this skill to simulate a `Nature`-style reviewer assessment package from the referee side. This skill is for reviewer-style manuscript evaluation, not for drafting the authors' response. If the user wants rebuttal writing, route to `nature-response`. ## Default stance - Ground the review only in the local source basis plus manuscript facts supplied by the user. - Evaluate the manuscript against source-grounded axes: `originality`, `scientific importance`, `interdisciplinary readership`, `technical soundness`, and `readability for nonspecialists`. - Use the 12-axis technical concern taxonomy only as an internal coverage checklist; it supplements but never replaces the five source-grounded axes. - Return exactly `3 mutually blind reviewer reports + 1 post-review synthesis` unless the user explicitly asks for another structure. - Give every reviewer only the same immutable manuscript/source packet, the same journal criteria, and that reviewer's preassigned emphasis. Never provide another review, a shared concern ledger, a draft synthesis, or hints about what another reviewer noticed. - Run each reviewer in a genuinely separate context, subagent, process, or invocation. If the environment cannot isolate contexts, generate one reviewer report per invocation or explicitly state that mutual blindness cannot be guaranteed; never present shared-context drafting as independent peer review. - Define emphasis briefs before any report is generated. They are working lenses, not reviewer identities, specialties, institutions, or biographies. - Freeze each individual report before comparing them. Natural duplication or disagreement is valid evidence of independent review and must not be edited away to manufacture diversity. - Identify who would be interested in the results and why. - Identify technical failings that must be addressed before the authors' case is established. - Give every substantive concern a stable ID, a faithful `claim_pointer`, and a verifiable `evidence_pointer`; mark missing locations instead of inventing them. - Separate user-visible concerns into `Major Concerns` and `Minor Comments`. Mark a Major Concern `Blocking Yes` only when the current manuscript cannot establish its central case until that concern is resolved; Minor Comments are never blocking. - Do not impose a concern quota. If no grounded concern exists at a level, state that explicitly instead of inventing one. - Keep the critique intellectually sharp but professionally phrased; severity comes from impact on the manuscript's case, not from hostile wording. - Avoid em dashes, en dashes, and colons as routine prose punctuation throughout reviewer reports and synthesis. Prefer a new sentence, comma, semicolon, parentheses, or a short heading followed by a new line. Retain ordinary hyphens in standard compound terms and stable IDs such as `R1-M1`. Preserve punctuation in source-faithful titles, quotations, formulas, identifiers, URLs, times, and required machine-readable syntax when changing it would be inaccurate. - Distinguish clearly between what is supported, what is weak, and what is not assessable from the provided material. - When the manuscript has a clear technical domain, use claim-dependent domain gates as supporting checks, but keep the output inside the same 3-reviewer `nature-reviewer` structure. - Do not claim the editor's final decision or certainty about fit to `Nature`. ## Accepted inputs The skill may receive: - full manuscript draft - abstract, summary paragraph, or cover-summary style text - introduction, results, discussion, or methods excerpts - figure legends, selected figures, or result notes - author notes in Chinese or English describing the claimed contribution - pre-submission positioning notes If the provided material is partial, perform a bounded review and mark the assessment boundary explicitly. ## Workflow 1. Identify the input scope and whether the job is a reviewer-style assessment rather than rebuttal drafting. 2. Build one immutable review packet containing only the supplied manuscript, verified source anchors, assessment boundary, and common journal criteria. Do not add analytical conclusions or suspected concerns to this packet. 3. Define the reviewer count and emphasis briefs before launching any reviewer. 4. Launch each reviewer in an isolated context. Pass only the immutable review packet, that reviewer's emphasis brief, the common report skeleton, and the same grounding rules. 5. Inside each isolated review, independently assess readiness and the source-grounded axes, then build that reviewer's own concern ledger using `references/technical-concern-taxonomy.md`. If relevant, load only the applicable section of `references/domain-specific-review-gates.md` inside that same isolated context. 6. Finalize and freeze every reviewer report. Do not show a completed or partial report to another reviewer, and do not redistribute concerns to control overlap. 7. Only after all reports are frozen, compare them in a separate synthesis pass. Reconcile independently created concerns to shared synthesis keys, and label consensus only when at least two reports independently raise the same underlying concern. 8. Generate `Cross-review synthesis (post-review; not shown to reviewers)` with consensus blocking concerns, other major concerns, the minor-revision checklist, and genuine differences in emphasis or judgment. 9. Run QA for reviewer isolation, severity calibration, blocking calibration, evidence anchoring, groundedness, coverage, role boundaries, and non-invention. Overlap is measured only after freezing and must never trigger retroactive rewriting of individual reports. ## Output format Unless the user asks for another format, return: ```text Review setup - **Input scope** [value] - **Assessment boundary** [value] - **Shared manuscript claim summary** [value] - **Visible evidence base** [value] - **Missing materials affecting confidence** [value] Reviewer 1 - **Overall assessment** [text] - **Who would be interested in the results, and why** [text] - **Major strengths** [text] - **Major Concerns** [items] - **Minor Comments** [items] - **Technical failings that need to be addressed before the case is established** [IDs or summary] - **Assessment against Nature-style criteria** [text] - **Recommendation posture** [text] For each Major Concern - **Concern ID** R1-M1 - **Severity** Major - **Blocking** Yes / No - **Axis** [value] - **Claim pointer** [value] - **Evidence pointer** [value] - **Concern** [text] - **Why it matters** [text] - **Resolution test** [text] For each Minor Comment - **Concern ID** R1-m1 - **Severity** Minor - **Axis** [value] - **Affected element** [value] - **Evidence pointer** [value] - **Issue** [text] - **Required correction** [text] Reviewer 2 [Same structure] Reviewer 3 [Same structure] Cross-review synthesis (post-review; not shown to reviewers) - **Consensus strengths** [text] - **Consensus blocking concerns** [items] - **Other consensus major concerns** [items] - **Where emphasis differs across reviewers** [text] - **Minor revision checklist** [items] - **Broad-interest / significance readout** [text] - **Most important issues to resolve before a strong Nature-style case is established** [items] Risk / unsupported claims - [specific unsupported or not-assessable items] ``` ## Red lines - Do not invent reviewer identities, specialty roles, or selection history. - Do not let one reviewer read, cite, anticipate, agree with, or respond to another review. - Do not build or distribute a shared concern ledger before individual reports are frozen. - Do not rewrite independent reports after comparison merely to reduce duplication or create artificial disagreement. - Do not call reports mutually blind when they were generated in a shared context without an explicit limitation notice. - Do not use dash punctuation or colons as habitual sentence connectors when clearer punctuation, headings, or sentence boundaries work. - Do not invent experiments, validations, controls, citations, figure details, line numbers, or prior-work distinctions not present in the input. - Do not silently turn reviewer assessment into author rebuttal drafting. - Do not present the review as an editorial decision letter. - Do not state that the manuscript belongs in `Nature` as a settled fact. - Do not omit technical failings when the provided evidence does not establish the authors' case. - Do not create Major or Minor concerns merely to fill a quota or make reviewer reports look balanced. - Do not downgrade a core evidence, validity, ethics, or integrity problem to Minor because it is easy to describe, and do not upgrade a local presentation issue merely to sound severe. ## Related files | File | Open when | |---|---| | [references/source-basis.md](references/source-basis.md) | You need source provenance, local rule summaries, or source-vs-implementation boundaries | | [references/reviewer-workflow.md](references/reviewer-workflow.md) | You need the invocation order, fact-base extraction flow, or synthesis rules | | [references/review-axes.md](references/review-axes.md) | You need the evaluation axes or reviewer weighting logic | | [references/technical-concern-taxonomy.md](references/technical-concern-taxonomy.md) | You need the internal 12-axis coverage check, concern ledger, or claim/evidence-pointer rules | | [references/domain-specific-review-gates.md](references/domain-specific-review-gates.md) | The manuscript has clear chemistry, engineering, materials, atmospheric, climate-ecology, hydrology, or remote-sensing evidence chains | | [references/report-structure.md](references/report-structure.md) | You need the default output contract or section anatomy | | [references/role-boundaries.md](references/role-boundaries.md) | You need constraints on reviewer differences and editor-versus-reviewer boundaries | | [references/qa-checklist.md](references/qa-checklist.md) | You are finalizing an output and need groundedness / non-invention checks | | [../nature-shared/core/consistency-sweep.md](../nature-shared/core/consistency-sweep.md) | You are checking the manuscript against itself: headline counts that do not reconcile with the Methods, one metric at two precisions, a superlative contradicted by the paper's own table, overlapping error bars presented as an advantage, or internal summaries that disagree | | [references/editorial criteria and processes.md]() | You need the primary local Nature source text | ## Source hierarchy Use sources in this order: 1. `references/editorial criteria and processes.md` 2. manuscript facts supplied by the user 3. conservative local implementation rules documented in `references/source-basis.md` 4. domain-specific supporting gates in `references/domain-specific-review-gates.md` If a user asks for policy-level certainty beyond this local source, state the limit instead of improvising broader journal policy.

相关技能

Agent 工作流

技能创建者Skill Creator

创造有效技能指南。 当用户想创造出新的技能(或更新现有的技能),以专业知识,工作流程,或工具集成来扩展克洛德的能力时,应该使用这种技能.

Agent 工作流

克劳德胡布Clawdhub

使用ClawdHub CLI搜索,安装,更新并发布从taladhub.com的代理技能. 需要获取苍蝇上的新技能时使用,将安装的技能同步到最新版本或特定版本,或者发布 npm-instainddhub CLI 的新/更新的技能文件夹.

Agent 工作流

团队指挥Agent Team Orchestration

管弦乐团多代理团队,任务设定周期,交接协议,审查工作流程. 使用时间: (1)建立2+特派员队伍,具有不同专业,(2)确定任务路线和生命周期(收录框_ spec_建设_审查_完成),(3)在特派员之间制定交接协议,(4)建立审查和质量关口,(5)管理特派员之间的交流和文物共享.

Agent 工作流

超级力量Superpowers

Spec-first,TDD,子代理驱动的软件开发工作流程. 当:(1)构建任何新功能或应用——触发脑暴_计划_子代理执行回路,(2)调试出一个bug或测试失败——触发系统性的根起过程,(3)用户说"让我们构建","帮助我计划","我想添加X",或"这个被打破",(4)完成一个功…