nature-reviewer

어떤 스킬인가요?

>-

설치 방법

프로젝트 폴더에서 아래 명령어를 실행하고, 설치할 에이전트를 선택하세요.

설치 명령을 직접 실행해야 적용됩니다. 지원 에이전트와 필요한 권한·라이선스는 제작자의 안내를 확인하세요.

스킬 원문 파일

interface:
  display_name: "Nature Reviewer"
  short_description: "Simulate tiered, mutually blind pre-submission reviews"
  default_prompt: "Use $nature-reviewer to run three mutually blind pre-submission reviews with tiered Major and Minor comments."

name: nature-reviewer
version: 1.4.0
description: >
  Declarative manifest for the Nature-style reviewer assessment workflow. It
  keeps the referee-facing SKILL.md compact while loading source basis, axes,
  domain gates, report structure, role boundaries, and QA checks only when the
  review stage requires them.

# Design note: reviewer simulation should remain grounded, mutually blind,
# and non-inventive.
# The official/local criteria and QA checks are always relevant to final reports,
# but domain-specific gates should only load for manuscripts in covered domains.

always_load:
  - references/editorial criteria and processes.md
  - references/source-basis.md

references:
  on_demand:
    - condition: executing the full isolated-review workflow, preparing immutable reviewer inputs, or resolving assessment order
      path: references/reviewer-workflow.md
    - condition: weighting originality, scientific importance, interdisciplinary readership, technical soundness, or readability
      path: references/review-axes.md
    - condition: building the internal concern ledger, calibrating Major/Minor severity and Blocking status, checking technical coverage, or anchoring concerns to manuscript claims and evidence locations
      path: references/technical-concern-taxonomy.md
    - condition: manuscript is clearly in chemistry, engineering, materials, atmospheric science, climate-ecology, hydrology, or remote sensing
      path: references/domain-specific-review-gates.md
    - condition: composing or auditing mutually blind reviewer reports with Major Concerns, Minor Comments, Blocking flags, and a post-review synthesis
      path: references/report-structure.md
    - condition: enforcing reviewer mutual blindness or preventing invented identities, editor decisions, or inappropriate reviewer-role claims
      path: references/role-boundaries.md
    - condition: final reviewer-isolation, severity, blocking, groundedness, non-invention, coverage, and reviewer-risk QA before delivery
      path: references/qa-checklist.md
    - condition: checking the manuscript against itself — headline counts that do not reconcile with the Methods, a metric reported at two precisions, superlatives contradicted by the paper's own tables, overlapping error bars presented as an advantage, and internal summaries that disagree; these are the cheapest findings a referee can make and belong in Major or Minor Concerns with the contradicting table cited
      path: ../nature-shared/core/consistency-sweep.md

# `nature-reviewer` Skill

[中文说明](README.md)

`nature-reviewer` simulates Nature-style pre-submission review from the reviewer perspective, helping authors find risks in novelty, significance, technical soundness, and reader value before submission.

## What To Use It For

- Stress-test a manuscript, abstract, figure set, or result storyline before submission.
- Evaluate originality, scientific importance, interdisciplinary readership, technical soundness, and readability using Nature-style review dimensions.
- Generate three reviewer reports in mutually blind isolated contexts, then create a separate cross-review synthesis only after every report is frozen.
- Mark unsupported claims, technical defects, evidence-chain breaks, and barriers for non-specialist readers.
- Separate comments into `Major Concerns` and `Minor Comments`, marking Major issues that block the central case as `Blocking Yes`.
- Keep severe criticism direct, professional, and evidence-grounded; keep minor comments specific and actionable without inventing issues to fill a quota.
- Avoid dash punctuation and colons throughout the prose when a sentence boundary, comma, semicolon, parentheses, or a short label on a new line is clearer; retain necessary source punctuation and hyphens in stable IDs and compound terms.
- Use an internal 12-axis technical checklist and bind each substantive concern to a claim pointer and verifiable evidence location.
- Cross-check terminology, units, numeric precision, Methods counts, and table support within the manuscript, separating language issues from substantive contradictions that weaken credibility.
- Do not coordinate or rewrite reviews to reduce duplication; treat an issue as consensus only when at least two reviewers raise it independently in the post-review synthesis.
- Identify which readers would care about the work and why.

## Typical Requests

- "Review this introduction and Figure 1 like a Nature reviewer."
- "Before submission, find the technical issues reviewers are most likely to attack."
- "Give me three reviewer reports and one synthesis, not a rebuttal."

## What You Need To Provide

- Manuscript, abstract, key sections, figures, legends, or author notes.
- Target journal, field, and the review risks you are most worried about.
- Existing supplementary experiments or constraints on adding new experiments.

## Outputs

- Three peer-review style reports.
- Cross-review synthesis: consensus problems, divergent emphases, and editor-level risks.
- Traceable concerns with stable IDs, claim pointers, evidence pointers, and resolution tests.
- Tiered Major/Minor comments, blocking risks, and a deduplicated minor-revision checklist.
- List of experiments, analyses, narrative changes, or figure evidence that must be strengthened.
- Explicit labels for judgments that cannot be made from the supplied evidence.

## Boundaries

- The skill does not invent specific reviewer identities, expert personas, or editorial decisions.
- Reviewers cannot read, cite, agree with, or respond to one another; synthesis begins only after all independent reports are locked.
- It makes conservative simulations only from the provided material and the skill's official review rules.
- For writing responses to real reviewer comments, use `nature-response`.

## Related Skills

- `nature-response`: turn real reviewer comments into a response package.
- `nature-writing`: rebuild manuscript narrative based on review risks.
- `nature-statistics`: deeply audit statistical design and reporting.

# `nature-reviewer` 技能

[English](README_EN.md)

`nature-reviewer` 用于从审稿人视角模拟 Nature 风格的预投稿评审，帮助作者在投稿前发现 novelty、significance、technical soundness 和读者价值上的风险。

## 适合用它做什么

- 对手稿、摘要、图表或结果故事线做投稿前压力测试。
- 按 Nature 官方审稿维度评估 originality、scientific importance、interdisciplinary readership、technical soundness 和 readability。
- 在相互不可见的独立上下文中生成三份 reviewer reports，全部定稿后再单独生成 cross-review synthesis。
- 标记无支撑声称、技术缺陷、证据链断点和非专业读者理解障碍。
- 将意见明确分成 `Major Concerns` 和 `Minor Comments`；对会阻断核心论证的 Major 问题标记 `Blocking Yes`。
- 尖锐意见保持直接、专业且有证据，小问题保持具体、可执行，不为凑数量虚构问题。
- 整体文风尽量不用破折号或冒号连接句子，优先使用分句、逗号、分号、括号或另起一行的短标签；稳定编号、必要连字符和不能改动的原文格式不受影响。
- 用内部 12 轴技术清单检查覆盖范围，并为每条实质性意见绑定 claim pointer 和可核验的证据位置。
- 交叉核对手稿内部的术语、单位、数值精度、Methods 计数和表格支撑，区分语言问题与会削弱可信度的实质矛盾。
- 不为了降低重复度而提前协调或改写审稿意见；只有至少两位 reviewer 独立提出同一问题时才在后置综合中列为共识。
- 判断哪些读者会关心这项工作，以及为什么。

## 典型请求

- “像 Nature reviewer 一样审这篇 introduction 和 Figure 1。”
- “投稿前帮我找最可能被审稿人攻击的技术问题。”
- “给我三份 reviewer reports 和一个综合判断，不要写 rebuttal。”

## 你需要提供

- 手稿全文、摘要、关键章节、图表、图注或作者说明。
- 目标期刊、学科领域和你最担心的审稿风险。
- 已有补充实验或不能新增实验的限制。

## 产出

- 三份 peer-review style reports。
- Cross-review synthesis：共识问题、分歧重点和编辑层风险。
- 带稳定编号、claim pointer、evidence pointer 和解决判据的可追溯审稿意见。
- 分级的 Major/Minor 意见、Blocking 风险和去重后的 minor revision checklist。
- 必须补强的实验、分析、叙事或图表证据清单。
- 对无证据判断的明确标记。

## 边界

- 不会虚构具体审稿人身份、专业人设或编辑决定。
- 不同 reviewer 之间不能读取、引用、赞同或回应彼此的意见；综合判断只在全部独立报告锁定后生成。
- 只基于用户提供材料和技能内官方审稿规则做保守模拟。
- 如果目标是写返修回复，优先使用 `nature-response`。

## 相关技能

- `nature-response`：把真实审稿意见转成回复包。
- `nature-writing`：根据评审风险重建手稿叙事。
- `nature-statistics`：深入审查统计设计和报告。

# Domain-specific review gates

## Contents

- [Shared gate pattern](#shared-gate-pattern)
- [Chemistry](#chemistry)
- [Engineering](#engineering)
- [Materials Science](#materials-science)
- [Atmospheric Science](#atmospheric-science)
- [Climate Ecology](#climate-ecology)
- [Hydrology](#hydrology)
- [Remote Sensing and Earth Observation](#remote-sensing-and-earth-observation)


Use this file only after the shared manuscript fact base is clear. These gates are
claim-dependent stress tests inside `nature-reviewer`; they do not create specialist
reviewer identities and do not replace the source-grounded Nature axes.

Apply only the domain sections triggered by the manuscript. Convert the diagnostics
into normal reviewer prose. Do not expose gate names, routing tables, pattern IDs, or
this file's internal structure in the final report.

## Shared gate pattern

For each central claim, identify:

- the claimed contribution and its exact scope;
- the evidence chain needed to support that claim;
- the assumptions, controls, uncertainty, and alternative explanations that carry the
  conclusion;
- whether the supplied material directly demonstrates the claim or only a narrower
  finding;
- what revision would either strengthen the evidence or calibrate the claim.

Make a concern major only when it affects the central contribution or the reader's
confidence in the evidence chain. Use minor comments for terminology, local clarity,
figure/table presentation, or non-central reporting gaps.

## Chemistry

Use for manuscripts where claims depend on synthesis, reaction development, catalysis,
chemical biology, analytical chemistry, spectroscopy, electrochemistry, computational
chemistry, or chemically specific materials/interfacial mechanisms.

Stress-test:

- identity, purity, structure, speciation, aggregation, and analytical quantification;
- reaction scope, selectivity, controls, yields, product balance, and boundary
  conditions;
- catalytic metrics such as turnover, quantum/Faradaic efficiency, stability,
  mass transport, light absorption, reference calibration, and normalization;
- whether mechanistic claims distinguish correlation from discriminating chemical
  evidence;
- whether computational chemistry, simulation, cheminformatics, or AI-for-chemistry
  results are sensitive to model assumptions and independently validated;
- whether chemical-biology claims separate probe chemistry, target engagement,
  off-target effects, and biological readouts.

Typical revision direction: add orthogonal characterization, matched controls,
scope limits, uncertainty/replicate reporting, raw spectra or structures, calibrated
performance metrics, and clearer separation between observed chemistry and inferred
mechanism.

## Engineering

Use for manuscripts whose central contribution is an engineered system, device,
robot, platform, instrument, manufacturing process, autonomous lab, control method,
or algorithm embodied in a physical system.

Stress-test:

- whether design requirements are defined before performance is interpreted;
- whether validation is independent of training, calibration, optimization, screening,
  or design selection;
- whether baselines are current, tuned, fair, and evaluated under matched constraints;
- whether the operating envelope covers realistic loads, environments, duty cycles,
  latency, safety boundaries, batch variation, ageing, edge cases, and failure modes;
- whether simulations, digital twins, controllers, and surrogate objectives are
  calibrated against unseen physical evidence;
- whether autonomy, scalability, manufacturability, deployment, or translation claims
  exceed proof-of-concept evidence.

Typical revision direction: define the engineering task, add independent validation,
matched baselines, repeated batches or unseen tasks, uncertainty/failure reporting,
operating-envelope tests, and a narrower deployment or platform claim where needed.

## Materials Science

Use for manuscripts where claims depend on materials design, synthesis, processing,
composition, phase, microstructure, structure-property relations, device-material
performance, durability, scalability, or computational materials prediction.

Stress-test:

- whether material identity, composition, phase, purity, morphology, interfaces,
  defects, and spatial representativeness are established by convergent evidence;
- whether property and performance metrics are valid, normalized, and comparable
  under matched protocols;
- whether controls and benchmarks include closest prior, commercial, or state-of-the-art
  materials under equivalent tests;
- whether structure-property or degradation mechanisms are causal rather than only
  correlated;
- whether stability, cycling, ageing, humidity/thermal/chemical/mechanical stress,
  and post-test characterization support durability claims;
- whether manufacturability, processability, cost, toxicity, or application-readiness
  conclusions are supported at the same scale as the evidence.

Typical revision direction: add orthogonal composition/phase evidence, representative
characterization, matched benchmarks, uncertainty and batch variation, in situ/operando
or perturbation evidence for mechanisms, and realistic stability or process-window tests.

## Atmospheric Science

Use for manuscripts involving atmospheric dynamics, observations, reanalysis, satellite
products, aerosol-cloud-radiation interactions, atmospheric chemistry, extremes,
circulation mechanisms, attribution, or AI weather/climate models.

Stress-test:

- whether observations, reanalysis products, satellite retrievals, and model outputs
  measure the atmospheric variable claimed;
- whether scale, resolution, sampling, representativeness, and event selection support
  the stated spatial or temporal inference;
- whether trend, circulation, extreme-event, or attribution claims separate signal from
  internal variability, product uncertainty, model spread, and multiple testing;
- whether mechanism claims are supported by diagnostics that rule out plausible
  alternative circulation, forcing, transport, chemistry, or feedback explanations;
- whether AI weather/climate claims are evaluated out of sample and against physically
  meaningful baselines and metrics.

Typical revision direction: add product intercomparison, physical diagnostics, ensemble
or sensitivity tests, uncertainty propagation, scale-bounded wording, and clear
separation between detection, mechanism, and attribution.

## Climate Ecology

Use for manuscripts in ecology, biodiversity, conservation, forest/land-use science,
carbon or nitrogen cycling, ecosystem modelling, global change, or ecological management
implications.

Stress-test:

- whether biodiversity, community, ecosystem-function, trait, stability, or resilience
  claims use direct metrics rather than proxy variables alone;
- whether plots, sites, taxa, seasons, years, and sensors are representative of the
  generalization being made;
- whether ecological, climate, land-use, and management drivers are separable from
  confounders and site history;
- whether statistical models respect hierarchy, autocorrelation, multiple testing,
  detectability, and effect-size interpretation;
- whether carbon/nitrogen stocks, fluxes, sinks, emissions, and nutrient cycling are
  measured with appropriate units, baselines, and uncertainty;
- whether policy, conservation, restoration, or management implications are supported
  at the decision-relevant scale.

Typical revision direction: add sampling-frame justification, independent validation,
mechanism or driver-separation tests, uncertainty propagation, decision-scale caveats,
and narrower ecological or management claims where evidence is local.

## Hydrology

Use for manuscripts involving streamflow, runoff, groundwater, total water storage,
drought, flood, hydroclimate, water quality, water resources, hydrological remote
sensing, data assimilation, or hydrological modelling.

Stress-test:

- whether the hydrological variable supports the claim: stage is not discharge, total
  water storage is not groundwater, flood extent is not hazard, concentration is not
  load, and precipitation anomaly is not necessarily hydrological impact;
- whether water-balance closure, basin boundaries, storage terms, withdrawals,
  evapotranspiration, and human-water interactions are treated consistently;
- whether models are calibrated, validated, and tested against independent gauges,
  basins, periods, extremes, and process signatures;
- whether drought, flood, trend, attribution, or water-quality claims separate hazard,
  exposure, vulnerability, residence time, sampling frequency, and uncertainty;
- whether remote sensing or data-assimilation products are validated at the scale and
  temporal support of the inference.

Typical revision direction: define variables and basins precisely, add independent
gauge/product validation, close or explain the water budget, report uncertainty and
sensitivity, separate hazard from risk, and narrow regional or policy claims when needed.

## Remote Sensing and Earth Observation

Use for manuscripts centered on satellite products, retrieval algorithms, Earth-observation
maps, machine-learning classification/regression, spatial products, time series, or product
validation.

Stress-test:

- whether the remote-sensing product validly represents the physical, ecological, or
  social quantity inferred from it;
- whether validation data are independent, representative, and matched in spatial,
  temporal, and measurement support;
- whether spatial leakage, non-independent train/test splits, out-of-domain transfer,
  rare-event imbalance, and product intercomparison are handled;
- whether uncertainty from retrieval, classification, reference data, aggregation,
  temporal consistency, and sensor/product changes propagates into the headline claim;
- whether trend, decline, recovery, breakpoint, policy-period, or attribution claims
  separate temporal signal from seasonality, autocorrelation, disturbance, and product
  version changes;
- whether maps and inventories report accuracy, bias, false positives/negatives, and
  spatially explicit uncertainty.

Typical revision direction: add independent blocked validation, reference-data
uncertainty, product intercomparison, temporal-consistency checks, sensitivity to
aggregation and thresholds, and carefully bounded map, trend, or policy claims.

# Editorial criteria and processes

This document provides an outline of the editorial process involved in publishing a scientific paper (Article) in _Nature_, and describes how manuscripts are handled by editors between submission and publication.

Editorial processes are described for the following stages: At submission | After submission | After acceptance

## At submission

**Criteria for publication**

The criteria for publication of scientific papers (Articles) in _Nature_ are that they:

- report original scientific research (the main results and conclusions must not have been published or submitted elsewhere)
- are of outstanding scientific importance
- reach a conclusion of interest to an interdisciplinary readership.

Further editorial criteria may be applicable for different kinds of papers, as follows:

- **large dataset papers**: should aim to either report a fully comprehensive data set, defined by complete and extensive validation, or provide significant technical advance or scientific insight.
- **technical papers:** papers that make solely technical advances will be considered in cases where the technique reported will have significant impacts on communities of fellow researchers.
- **therapeutic papers:** in the absence of novel mechanistic insight, therapeutic papers will be considered if the therapeutic effect reported will provide significant impact on an important disease.

Articles published in Nature have an exceptionally wide impact, both among scientists and, frequently, among the general public.


## After submission

### **What happens to a submitted Article?**

The first stage for a newly submitted Article is that the editorial staff consider whether to send it for peer-review. On submission, the manuscript is assigned to an editor covering the subject area, who seeks informal advice from scientific advisors and editorial colleagues, and who makes this initial decision. The criteria for a paper to be sent for peer-review are that the results seem novel, arresting (illuminating, unexpected or surprising), and that the work described has both immediate and far-reaching implications. The initial judgement is not a reflection on the technical validity of the work described, or on its importance to people in the same field.  
Special attention is paid by the editors to the readability of submitted material. Editors encourage authors in highly technical disciplines to provide a slightly longer summary paragraph that descries clearly the basic background to the work and how the new results have affected the field, in a way that enables nonspecialist readers to understand what is being described. Editors also strongly encourage authors in appropriate disciplines to include a simple schematic summarizing the main conclusion of the paper, which can be published with the paper as Supplementary Information. Such figures can be particularly helpful to nonspecialist readers of cell, molecular and structural biology papers.  
Once the decision has been made to peer-review the paper, the choice of referees is made by the editor who has been assigned the manuscript, who will be handling other papers in the same field, in consultation with editors handling submissions in related fields when necessary. Most papers are sent to two or three referees, but some are sent to more or, occasionally, just to one. Referees are chosen for the following reasons:

- independence from the authors and their institutions
- ability to evaluate the technical aspects of the paper fully and fairly
- currently or recently assessing related submissions
- availability to assess the manuscript within the requested time.

### **Referees' reports**

The ideal referee's report indicates

- who will be interested in the new results and why
- any technical failings that need to be addressed before the authors' case is established.

Although _Nature_'s editors themselves judge whether a paper is likely to interest readers outside its own immediate field, referees often give helpful advice, for example if the work described is not as significant as the editors thought or has undersold its significance. Although _Nature_'s editors regard it as essential that any technical failings noted by referees are addressed, they are not so strictly bound by referees’ editorial opinions as to whether the work belongs in _Nature_.

# QA checklist

## Reviewer-isolation checks

- Reviewer emphasis briefs were fixed before any report was generated.
- Each reviewer received only the immutable manuscript/source packet, common criteria, report skeleton, and its own emphasis brief.
- Each reviewer ran in a separate context, subagent, process, or invocation and received no other review, ledger, synthesis, consensus hint, or overlap target.
- Every individual report was finalized and locked before comparison began.
- No individual report cites, agrees with, answers, anticipates, or refers to another reviewer.
- Cross-review synthesis was generated afterward in a separate editor/author-facing pass and was not fed back to reviewers.
- If technical isolation was unavailable, the output explicitly says mutual blindness was not guaranteed or provides only one reviewer report for the invocation.

## Grounding checks

- Every substantive evaluation should be traceable to either:
  - `references/editorial criteria and processes.md`, or
  - manuscript facts explicitly supplied by the user.
- No reviewer persona detail should appear beyond allowed `emphasis` labels.
- No technical failing should be invented from domain habit alone when the supplied material does not show it.
- Every substantive concern has a stable concern ID, `claim_pointer`, and `evidence_pointer`.
- Page, line, figure, and table identifiers are supplied or directly verified; otherwise the pointer says `location not provided` or `not assessable from supplied material`.

## Technical coverage checks

- The internal 12-axis matrix was considered without being dumped into the final report.
- Each axis is marked internally as `applicable`, `not applicable`, or `not assessable`; absence of evidence is not silently treated as a defect.
- The technical taxonomy supplements the five source-grounded Nature axes and does not create policy claims or severity statistics.

## Severity and blocking checks

- Every emitted concern is classified as Major or Minor from its impact on the manuscript's case,
  not from tone, difficulty, cost, or a desired quota.
- Every Major Concern displays `Blocking Yes` or `Blocking No` and gives a rationale consistent
  with the concern and resolution test.
- `Blocking Yes` is used only when the current manuscript cannot establish its central case until
  the concern is resolved.
- No Minor Comment is blocking, and no core evidence, validity, ethics, or integrity problem is
  downgraded to Minor merely because it can be described briefly.
- Localized presentation, terminology, citation, and reporting issues remain Minor unless they
  materially affect inference or reproducibility.
- Empty tiers say `None identified from the supplied material`; concerns are never invented to fill
  Major/Minor sections or equalize reviewer counts.

## Coverage checks

- Confirm all three reviewer reports exist.
- Confirm all reviewers received the same source packet and criteria, with only their preassigned emphasis briefs differing; no invented identity or unequal evidence access explains their conclusions.
- Confirm each reviewer still addresses all core axes, even if briefly.
- Confirm each reviewer visibly contains both `Major Concerns` and `Minor Comments` sections.
- Confirm a `Cross-review synthesis (post-review; not shown to reviewers)` section exists.
- Confirm a `Risk / unsupported claims` section exists.

## Boundary checks

- Confirm the output stays in reviewer-assessment mode, not author-response mode.
- Confirm the output does not claim a final editorial decision.
- Confirm broad-interest judgment is expressed cautiously, because the source assigns that final judgment to editors.

## Style checks

- Reviewer reports and synthesis avoid em dashes, en dashes, and colons as routine prose punctuation when a sentence boundary, comma, semicolon, parentheses, or a short label followed by a new line would be clearer.
- Necessary hyphens in compound terms and stable IDs such as `R1-M1` remain intact.
- Source-faithful titles, quotations, formulas, identifiers, URLs, times, and required machine-readable syntax are not altered merely to remove punctuation.

## Non-invention checks

- No invented reviewer identity, specialty, institution, or selection history.
- No invented experiments, controls, analyses, line numbers, citations, prior-work details, or figure-specific content absent from the input.
- If evidence is partial, mark `AUTHOR_INPUT_NEEDED` or `Not assessable from provided material`.

## Consistency checks

- Verifiable manuscript facts should stay consistent across all three reviewers even though their analyses were independent.
- Divergence may reflect weighting or interpretation of the same evidence, not access to different or invented facts.
- Technical failings listed in the synthesis should match issues already raised in at least one individual report.
- Consensus issues were raised by at least two reviewer reports and map to the same underlying issue key.
- Consensus blocking and other consensus major concerns preserve the original severity and
  blocking status of the source concerns.
- The minor-revision checklist contains only supported Minor Comments and cross-references their IDs.
- Preserve important single-reviewer concerns as weighting differences instead of deleting them.

## Overlap checks

- Normalize concerns to synthesis keys only after all individual reports are frozen.
- Measure pairwise overlap descriptively as `shared synthesis keys / smaller report issue count` when useful.
- Do not revise, redistribute, suppress, or add concerns to hit an overlap target. High overlap can be legitimate independent consensus; low overlap can be legitimate difference in judgment.
- Deduplicate only inside the post-review synthesis and preserve links to the original reviewer-local concern IDs.

## Final release rule

- If the skill cannot produce a grounded three-reviewer package without major invention, it should return a bounded draft review with explicit missing-information flags rather than pretending certainty.
- If the skill cannot isolate reviewer contexts, it must not label a multi-reviewer package mutually blind; use separate invocations or state the technical limitation.
- Do not release the report when Major/Minor labels or Blocking flags conflict with their stated
  rationale, manuscript impact, or resolution test.
- Do not release habitual dash-heavy or colon-heavy prose without first rewriting it with clearer sentence structure.

# Report structure

## Contents

- [Default output contract](#default-output-contract)
- [Review setup](#review-setup)
- [Per-reviewer structure](#per-reviewer-structure)
- [Concern traceability and severity display](#concern-traceability-and-severity-display)
- [Cross-review synthesis structure](#cross-review-synthesis-structure)
- [Risk / unsupported claims section](#risk-unsupported-claims-section)
- [Style rules](#style-rules)


## Default output contract

- The default output should contain these sections in order:
  1. `Review setup`
  2. `Reviewer 1`
  3. `Reviewer 2`
  4. `Reviewer 3`
  5. `Cross-review synthesis (post-review; not shown to reviewers)`
  6. `Risk / unsupported claims`

## Review setup

- Include:
  - `Input scope`
  - `Assessment boundary`
  - `Shared manuscript claim summary`
  - `Visible evidence base`
  - `Missing materials affecting confidence`, when applicable

## Per-reviewer structure

- Each reviewer report should use the same skeleton:
  - `Overall assessment`
  - `Who would be interested in the results, and why`
  - `Major strengths`
  - `Major Concerns`
  - `Minor Comments`
  - `Technical failings that need to be addressed before the case is established`
  - `Assessment against Nature-style criteria`
  - `Recommendation posture`
- `Assessment against Nature-style criteria` should explicitly touch:
  - `originality`
  - `scientific importance`
  - `interdisciplinary readership`
  - `technical soundness`
  - `readability for nonspecialists`
- `Recommendation posture` should stay reviewer-like, for example:
  - `supportive if technical concerns are resolved`
  - `promising but broad-interest case remains underdeveloped`
  - `currently not established from the provided evidence`

## Concern traceability and severity display

- Give each substantive concern a stable local ID: `R1-M1`, `R1-M2`, `R1-m1`, and so on.
- Use this shape for each Major Concern:

```text
R1-M1 [experimental-design]
**Severity** Major
**Blocking** Yes / No
**Claim pointer** [faithful one-sentence paraphrase of the challenged claim or reporting element]
**Evidence pointer** [section / figure / table, or "location not provided"]
**Concern** [evidence-grounded critique]
**Why it matters** [effect on the central case, important inference, significance, or reproducibility]
**Resolution test** [evidence, analysis, clarification, or claim adjustment that would resolve it]
```

- Use this shorter shape for each Minor Comment:

```text
R1-m1 [writing-clarity]
**Severity** Minor
**Affected element** [claim or reporting element]
**Evidence pointer** [section / figure / table, or "location not provided"]
**Issue** [localized, evidence-grounded problem]
**Required correction** [specific correction that would close it]
```

- A `claim_pointer` is not a quotation unless the exact wording was supplied.
- An `evidence_pointer` may use a page or line number only when the number was supplied or directly verified.
- Minor presentation concerns may point to the affected reporting element instead of a scientific claim.
- The `Technical failings that need to be addressed before the case is established` line is a
  short roll-up that cross-references `Blocking Yes` IDs; do not duplicate the full concern prose.
- Use uppercase `M` IDs for Major Concerns (`R1-M1`) and lowercase `m` IDs for Minor Comments
  (`R1-m1`). Do not change an ID's case after assignment.
- Every reviewer must show both section headings, but either section may say
  `None identified from the supplied material`. Do not force a minimum count.
- Do not emit the complete internal 12-axis coverage matrix.

## Cross-review synthesis structure

- Generate this section only after all individual reports have been frozen. It is part of the editor/author-facing package and is never shown to the simulated reviewers.
- Include:
  - `Consensus strengths`
  - `Consensus blocking concerns`
  - `Other consensus major concerns`
  - `Where emphasis differs across reviewers`
  - `Minor revision checklist`
  - `Broad-interest / significance readout`
  - `Most important issues to resolve before a strong Nature-style case is established`
- List a concern under either consensus concern section only when at least two reviewer reports raise the same underlying issue.
- Keep meaningful single-reviewer concerns visible under `Where emphasis differs across reviewers`.
- Deduplicate repeated Minor Comments in the checklist and preserve their original IDs as cross-references.
- Do not edit the individual reports after deduplication or synthesis.

## Risk / unsupported claims section

- Include explicit flags for:
  - unsupported novelty claims
  - significance claims not established by the supplied evidence
  - missing controls, validations, or comparisons
  - readability claims that cannot be assessed from the supplied excerpt
  - any place where the review necessarily relied on partial material

## Style rules

- Keep tone formal, direct, and evidence-based.
- Avoid em dashes, en dashes, and colons as routine prose punctuation. Prefer sentences, commas, semicolons, parentheses, or a short label followed by a new line. Keep necessary hyphens in compound terms and concern IDs. Preserve punctuation in faithful source text, formulas, identifiers, URLs, times, and required machine-readable syntax.
- Make the scientific criticism as direct as the evidence warrants, but never use ridicule,
  hostility, insinuation, or exaggerated language as a substitute for severity.
- Do not write as the authors.
- Do not write a rebuttal, action plan, or editorial decision letter unless the user explicitly asks for one.
- Do not invent line numbers, figure panels, datasets, prior studies, or missing analyses.

# Review axes

## Core axes derived from the source

- `originality`
  - Ask whether the work appears to report original scientific research and whether the main results or conclusions seem genuinely new from the provided material.
  - Flag when novelty is asserted but not well distinguished from prior work.
- `scientific importance / significance`
  - Ask whether the work appears to be of outstanding scientific importance.
  - Distinguish field-local usefulness from broader scientific importance.
- `interdisciplinary readership interest`
  - Ask whether the conclusion appears interesting beyond the immediate specialty.
  - Note whether the implications feel immediate and far-reaching versus narrow and incremental.
- `technical soundness / technical failings`
  - Ask whether the authors' case is technically established from the evidence shown.
  - Identify concrete technical failings that must be addressed before the case is established.
- `readability for nonspecialists`
  - Ask whether a nonspecialist reader could understand the basic background, what was done, and how the results affect the field.
  - Use this axis especially for highly technical manuscripts.

## Axis-specific prompts

- For `originality`:
  - What is the claimed advance?
  - Is the distinction from prior work explicit and credible in the supplied manuscript?
- For `scientific importance / significance`:
  - Does the manuscript support a case for outstanding importance, or only competent incremental progress?
  - Are the implications immediate and far-reaching, or mainly field-internal?
- For `interdisciplinary readership interest`:
  - Who outside the immediate area would care, and why?
  - Is the conclusion framed in a way that broad scientific readers can grasp?
- For `technical soundness / technical failings`:
  - Which parts of the causal or evidentiary chain are under-supported?
  - What missing controls, analyses, validations, or logic gaps currently weaken the authors' case?
- For `readability for nonspecialists`:
  - Is the summary logic accessible?
  - Does the manuscript rely on unexplained jargon, compressed context, or unclear field impact?

## Weighting guidance for the three reports

- Assign these emphasis briefs before any reviewer receives the manuscript, and do not change them in response to another report.
- `Reviewer 1` should usually foreground `technical soundness / technical failings`.
- `Reviewer 2` should usually foreground `originality` plus `scientific importance / significance`.
- `Reviewer 3` should usually foreground `interdisciplinary readership interest` plus `readability for nonspecialists`.
- All three reviewers should still cover all axes briefly; the difference is weight, not scope omission.

## Missing-evidence handling

- If the manuscript text or figures are incomplete, do not infer absent validations or prior-work distinctions.
- Use explicit markers such as:
  - `Not assessable from provided material`
  - `AUTHOR_INPUT_NEEDED`
  - `Evidence not shown in the supplied manuscript excerpt`

## Things this axis set must not do

- Do not replace source-grounded axes with generic peer-review checklists unrelated to the local source.
- Do not force exhaustive domain-specific methodological critique when the provided material does not support it.
- Do not convert readability comments into copyediting line edits unless the user explicitly asks for that level of intervention.

# Reviewer workflow

## Contents

- [Default execution order](#default-execution-order)
- [Input handling](#input-handling)
- [Immutable review-packet checklist](#immutable-review-packet-checklist)
- [Concern-ledger fields](#concern-ledger-fields)
- [Cross-review generation rule](#cross-review-generation-rule)
- [Failure-safe behaviour](#failure-safe-behaviour)


## Default execution order

1. Identify the input package.
   - Determine whether the user supplied a full manuscript, abstract-only draft, selected sections, figures, notes, or a pre-submission concept summary.
2. Build an immutable review packet.
   - Include the supplied manuscript/source, verified source anchors, assessment boundary, and common journal criteria.
   - Do not include suspected concerns, a shared interpretation, another report, or a draft synthesis.
3. Define all reviewer emphasis briefs before review begins.
   - Keep the source packet and report skeleton identical; vary only the declared emphasis.
4. Generate each reviewer report in an isolated context.
   - Give the reviewer only the immutable packet, common rules, report skeleton, and its own emphasis brief.
   - Within that context, independently extract the central claim, key evidence, stated significance, implied audience, visible limitations, and missing material.
   - Independently apply `originality`, `scientific importance`, `interdisciplinary interest`, `technical soundness`, and `readability for nonspecialists`.
5. Build one private concern ledger per reviewer.
   - Load `technical-concern-taxonomy.md` and mark each axis `applicable`, `not applicable`, or `not assessable` without access to any other reviewer's ledger.
   - Give every supported concern a reviewer-local issue key, `major` or `minor` severity, a blocking flag for Major Concerns, severity rationale, `claim_pointer`, `evidence_pointer`, and resolution test.
   - Keep the ledger private to that reviewer; expose only the fields needed to make emitted concerns traceable.
6. Freeze all reviewer reports.
   - Do not let reviewers read, cite, agree with, answer, or anticipate one another.
   - Do not redistribute, add, remove, or rephrase concerns after comparison merely to change overlap.
   - Render separate `Major Concerns` and `Minor Comments` sections. If a tier has no grounded item, write `None identified from the supplied material` rather than filling a quota.
7. Generate a post-review synthesis in a separate context.
   - Summarize consensus blocking concerns, other major concerns, the minor-revision checklist,
     points of emphasis divergence, and the most decision-relevant technical and significance risks.
   - Reconcile reviewer-local issue keys only now. Treat an issue as consensus only when at least two frozen reports independently raise the same underlying concern.
8. Run final QA.
   - Check context isolation, locked-report status, evidence anchors, post hoc overlap mapping, groundedness, consistency, coverage, and non-invention.

## Input handling

- Acceptable inputs include:
  - manuscript draft
  - abstract or summary paragraph
  - introduction, results, discussion, or methods excerpts
  - figure legends or selected figures
  - author notes describing the claimed contribution
- If the input is thin, the skill should still provide a bounded review, but it must clearly state the assessment boundary.

## Immutable review-packet checklist

- Put only these common inputs into every isolated reviewer context:
  - supplied manuscript/source material
  - verified section, figure, table, equation, page, or block anchors
  - assessment boundary and missing-file inventory
  - common journal criteria and report skeleton
  - that reviewer's preassigned emphasis brief
- Do not put these into the shared packet:
  - extracted concerns or visible technical gaps
  - a shared claim-evidence interpretation
  - another reviewer report or ledger
  - overlap targets, consensus labels, or synthesis notes

## Concern-ledger fields

Use this internal shape before drafting reviewer prose:

```yaml
issue_key: experimental-design-control-selection
axis: experimental-design
applicability: applicable
severity: major
blocking: yes
severity_rationale: The missing control prevents the supplied comparison from isolating the central treatment effect.
claim_pointer: The treatment effect is attributed to the intervention.
evidence_pointer: Results, "Primary outcome"; Figure 2
evidence_status: located
concern: The supplied comparison does not isolate the intervention effect.
resolution_test: Show an appropriate control or narrow the causal claim.
reviewer_id: Reviewer 1
```

- Use section headings and supplied figure/table identifiers before page or line numbers.
- Use `location not provided` or `not assessable from supplied material` when an exact pointer cannot be verified.
- Never infer an absent figure, analysis, control, or manuscript location.
- Use `blocking: yes` only for a grounded Major Concern that prevents the current manuscript from
  establishing its central case. Minor Comments always use `blocking: no` internally and do not
  need to display the field in the final report.

## Cross-review generation rule

- Run synthesis only after all individual reports are final and locked.
- Treat the synthesis as editor/author-facing; never send it back into any reviewer context.
- The cross-review synthesis should consolidate, not average away, reviewer differences.
- A consensus item must map post hoc to equivalent concerns raised by at least two reviewer reports.
- Preserve consequential single-reviewer concerns under weighting differences; do not drop them merely because they lack consensus.
- It must separate:
  - shared strengths
  - consensus blocking concerns
  - other shared major concerns
  - minor revision checklist
  - differences in significance weighting
  - differences in readership/readability judgment

## Failure-safe behaviour

- If isolated contexts are unavailable, produce one reviewer report per invocation or disclose that mutual blindness cannot be guaranteed. Do not silently simulate independence inside a shared drafting context.
- When evidence is absent, say the case is not yet established from the supplied material.
- When significance is unclear, distinguish `potentially interesting` from `demonstrated broad importance`.
- When readability is weak, describe the barrier to nonspecialist comprehension instead of rewriting the manuscript unless asked.

# Role boundaries

## Reviewer mutual blindness

- Treat every reviewer as unable to see any other reviewer's report, notes, concern ledger, or recommendation.
- Give all reviewers the same immutable manuscript/source packet and common journal criteria, plus only their own preassigned emphasis brief.
- Use a separate context, subagent, process, or invocation for each reviewer. Do not claim mutual blindness when the execution environment cannot provide isolation.
- Finalize and lock individual reports before any comparison. Natural overlap and disagreement must remain intact.
- Create cross-review synthesis only in a separate post-review pass for the editor/author-facing package. Never feed that synthesis back to reviewers.
- Do not use phrases such as `as Reviewer 1 noted`, `I agree with the other reviewer`, or `the reviewers collectively believe` inside an individual report.

## Allowed reviewer differences

- Assign reviewer `emphasis` before any report is generated.
- Valid emphasis patterns for this skill are limited to source-grounded axes such as:
  - `technical validity / technical failings emphasis`
  - `significance / originality emphasis`
  - `interdisciplinary readership / readability emphasis`
- These emphasis labels are working lenses, not claimed referee identities.

## Forbidden inventions

- Do not invent reviewer identities, including:
  - named disciplines not required by the source
  - `statistics reviewer`, `ethics reviewer`, `clinical reviewer`, `methods reviewer`, or similar role titles
  - seniority, geography, gender, institutional type, or prior relationship to the field
- Do not claim the reviewers were chosen for reasons other than those stated in the source.
- Do not simulate confidential editor knowledge, hidden reviewer expertise, or access to related submissions unless the user explicitly supplied such information.

## Editor-versus-reviewer separation

- Reviewers in this skill may:
  - assess who would care about the results and why
  - identify technical failings that block the authors' case
  - comment that significance seems overstated or undersold
  - note whether the manuscript appears hard for nonspecialists to read
- Reviewers in this skill must not:
  - act as if they are the handling editor
  - state final editorial outcomes as facts
  - claim authority over referee selection
  - replace the editor's broad-readership judgment with invented certainty

## Output behaviour rules

- Each reviewer should independently assess the same manuscript/source packet. Similarity is allowed and must not be optimized away.
- Disagreement may arise from weighting or interpretation of the same supplied evidence, not from fabricated access to different facts.
- If a requested evaluation would require a role the source does not define, keep the comment generic and evidence-based instead of creating a specialist persona.

## Safe phrasing examples

- Prefer:
  - `Reviewer 1 places greatest weight on technical failings that currently weaken the authors' case.`
  - `Reviewer 2 places greatest weight on originality and scientific importance.`
  - `Reviewer 3 places greatest weight on interdisciplinary reach and readability for nonspecialists.`
- Avoid:
  - `Reviewer 2 is a senior translational oncologist.`
  - `Reviewer 3 serves as the statistical referee.`
  - `Reviewer 1 was selected because they recently reviewed a competing submission.`

# Source basis

## Authoritative local source

- Primary local source: `references/editorial criteria and processes.md`
- Scope of authority:
  - publication criteria for `Nature` Articles
  - peer-review entry criteria used by editors before external review
  - referee selection basis
  - ideal referee report content
- This skill must treat that file as the only authoritative local source for reviewer-facing behaviour in the MVP.

## Direct source extracts converted into working rules

- Publication criteria for Articles:
  - papers should report `original scientific research`
  - papers should be of `outstanding scientific importance`
  - papers should `reach a conclusion of interest to an interdisciplinary readership`
- Peer-review entry criteria used by editors:
  - results seem `novel`
  - results are `arresting`, meaning illuminating, unexpected, or surprising
  - work has `immediate and far-reaching implications`
  - this initial decision is `not a reflection on technical validity` or field-local importance
- Readability expectation relevant to reviewer assessment:
  - submitted material receives `special attention` for readability
  - highly technical work should explain background and field impact clearly enough for `nonspecialist readers`
- Referee selection basis:
  - `independence` from authors and institutions
  - ability to evaluate `technical aspects` fully and fairly
  - may be `currently or recently assessing related submissions`
  - `availability` within the requested review time
- Ideal referee report content:
  - indicate `who will be interested in the new results and why`
  - indicate `technical failings` that must be addressed before the authors' case is established
- Editor-versus-referee boundary in the source:
  - editors judge whether work is likely to interest readers `outside its immediate field`
  - referees may still help when significance was overestimated or `undersold`
  - editors are strictly concerned that `technical failings` be addressed
  - editors are `not strictly bound` by referee editorial opinions on whether the work belongs in `Nature`

## Local rule summary

- Reviewer outputs must evaluate the manuscript against source-grounded axes only:
  - `originality`
  - `scientific importance / significance`
  - `interest beyond the immediate field / interdisciplinary readership`
  - `technical soundness / technical failings`
  - `readability for nonspecialists` when inferable from the manuscript
- Reviewer outputs must not pretend to make the editor's acceptance decision.
- Reviewer outputs may comment on whether significance seems overstated or understated, because the source explicitly allows helpful referee advice there.
- Reviewer outputs must distinguish:
  - what is supported by manuscript evidence
  - what is missing or technically weak
  - what cannot be assessed from provided material
- When the manuscript packet is incomplete, the skill must use `AUTHOR_INPUT_NEEDED` or equivalent missing-evidence flags instead of inventing facts.

## Conservative implementation choices

- The skill returns exactly `3 mutually blind reviewer reports + 1 post-review synthesis` by default.
  - This is a repo-level implementation choice, not a direct source requirement.
- The three reviewers receive the same immutable source packet but work in mutually blind contexts with preassigned emphasis briefs; they do not receive shared concerns or other reports.
  - Mutual blindness is a repo-level simulation integrity rule, not a claim about every journal workflow.
- Reviewer differences must not rely on invented identity, seniority, institution, demographic profile, or narrow specialty role.
  - This is a conservative anti-hallucination rule derived from the limited source basis.
- The output includes an explicit `Risk / unsupported claims` section.
  - This is a local QA device, not an official Nature format requirement.
- The skill uses a 12-axis technical concern taxonomy as an internal coverage checklist.
  - This is a repo-level organizational device, not an official Nature taxonomy and not a claim about concern prevalence in historical reviews.
- Each substantive concern carries a claim pointer and evidence pointer.
  - This is a local traceability rule; it must never cause the skill to invent locations or manuscript facts.
- Pairwise reviewer concern overlap is measured only after reports are frozen.
  - It is descriptive evidence for synthesis, never a target used to redistribute concerns or manufacture diversity.
- The skill uses explicit section labels such as `Review setup`, `Reviewer 1`, and `Cross-review synthesis (post-review; not shown to reviewers)`.
  - This is a formatting contract for usability, not a source claim.

## Implementation implications

- If the user asks for an author rebuttal, route to `nature-response`, not this skill.
- If the user asks for simulated peer review, stay in reviewer mode:
  - assess claims
  - identify likely interested readership
  - identify technical failings
  - avoid drafting editorial decision language as the default output
- If the manuscript seems technically valid but not clearly broad-interest, the reports may say so; the source explicitly separates technical validity from editorial selection.
- If the manuscript is broad-interest but evidence is incomplete, the reports must still foreground technical failings because the source treats them as essential before the authors' case is established.

# Technical concern taxonomy

Use this reference to build an internal concern ledger after the five source-grounded Nature axes have been assessed. It is a coverage and traceability aid, not an official journal taxonomy, reviewer-persona selector, or historical-frequency model.

## Twelve internal axes

| Axis | Check only when applicable |
|---|---|
| `novelty-significance` | The claimed advance is distinguished from prior work and its importance is supported rather than asserted. |
| `mechanism-evidence` | Mechanistic statements are supported by discriminating evidence rather than a compatible observation alone. |
| `experimental-design` | Comparators, controls, replication units, conditions, sampling, and bias controls support the stated inference. |
| `statistical-rigor` | Estimands, assumptions, uncertainty, multiplicity, power, and model validation are adequate for the claim. |
| `reproducibility` | Methods, code, data, versions, seeds, protocols, and reporting detail permit independent scrutiny or reuse where appropriate. |
| `clinical-validity` | Cohort definition, endpoint choice, external validation, calibration, clinical utility, and generalizability support clinical claims. |
| `ethical-governance` | Human/animal approvals, consent, privacy, dual-use, permissions, and responsible data handling are reported when required. |
| `data-resource-quality` | Dataset completeness, provenance, documentation, quality control, accessibility, and intended reuse are credible. |
| `figures-and-tables` | Visual encodings, labels, denominators, uncertainty, scale bars, legends, and accessibility accurately represent the results. |
| `writing-clarity` | The argument, terminology, abstract/body consistency, and nonspecialist explanation make the evidence chain understandable. |
| `claim-moderation` | Strength, scope, novelty, generality, and translational language do not exceed the supplied evidence. |
| `causal-vs-correlative` | Association, prediction, mediation, intervention, and causation are distinguished according to study design and evidence. |

## Applicability rule

For every axis, record one of:

- `applicable`: the manuscript makes a claim or presents evidence that activates the check;
- `not applicable`: the axis is genuinely outside the manuscript's design or claims;
- `not assessable`: the axis could matter, but the supplied material is insufficient.

Do not turn `not assessable` into a presumed flaw. State the assessment boundary when the missing material affects confidence.

## Concern construction

Emit a concern only when it is supported by the supplied manuscript material. Record:

- `issue_key`: a concise normalized key used to detect overlap;
- `axis`: one primary technical axis;
- `severity`: `major` or `minor` according to effect on the authors' case;
- `blocking`: `yes` or `no`; only a Major Concern may be blocking;
- `severity_rationale`: one sentence explaining the concern's effect on the central case;
- `claim_pointer`: a faithful paraphrase of the challenged claim or affected reporting element;
- `evidence_pointer`: a verified section, figure, table, page, or line location;
- `evidence_status`: `located`, `location_missing`, or `not_assessable`;
- `concern`: why the visible evidence does not yet support the claim or reporting need;
- `resolution_test`: what evidence, analysis, clarification, or claim adjustment would close the concern.

Use `location not provided` when the critique is grounded but the exact location cannot be verified. Never manufacture a location to make the ledger look complete.

## Severity and blocking calibration

Classify impact, not tone, difficulty, cost, or preferred reviewer style.

| Classification | Use when | Typical resolution |
|---|---|---|
| `major`, `blocking: yes` | The current evidence cannot establish a central conclusion, or a validity, ethics, governance, or data-integrity problem prevents a credible scientific case. | Decisive evidence or analysis, correction of the invalid design/reporting, transparent integrity resolution, or narrowing/removal of the unsupported central claim. |
| `major`, `blocking: no` | The issue materially weakens inference, novelty, significance, generalizability, reproducibility, or an important part of the evidence chain, but does not by itself invalidate the entire central case. | Substantive analysis, validation, methodological clarification, structural revision, stronger comparison, or meaningful claim moderation. |
| `minor`, `blocking: no` | The issue is localized and does not change the central conclusion or interpretation of the core evidence. | Precise wording, definition, citation, figure/table/legend correction, localized reporting detail, or limited clarification. |

Calibration rules:

- A missing detail is Major when it prevents evaluation or reproduction of a result central to the
  paper; it is Minor when the result remains interpretable and the correction is localized.
- A figure or statistical issue is not automatically Minor. Misleading uncertainty, denominators,
  scales, tests, or replicate definitions may be Major or blocking when they affect inference.
- A writing issue is Major when ambiguity changes the main claim or scientific interpretation;
  ordinary clarity, terminology, and formatting issues are Minor.
- `not assessable` is an evidence-status label, not a severity. Do not convert absent material into
  a Major Concern unless the supplied package was expected to contain it and the omission itself is
  verifiable.
- Minor Comments must be actionable and manuscript-specific; omit taste-only copyediting.
- Never manufacture concerns to meet a numeric quota. Use `None identified from the supplied
  material` when a severity tier has no grounded item.

## Reviewer-local use

- Keep the visible labels as `Reviewer 1`, `Reviewer 2`, and `Reviewer 3` with preassigned emphasis briefs.
- Apply the taxonomy independently inside each isolated reviewer context. Do not allocate concerns or axes based on another report.
- Do not expose specialist personas such as `Statistics Reviewer` or infer reviewer-selection history.
- Use reviewer-local issue keys while drafting. Map equivalent concerns to synthesis keys only after all reports are frozen.
- Classify Major and Minor concerns according to evidence and emphasis, not fixed counts. A reviewer
  may legitimately have no concern at one severity level.

---
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](<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.

# Punctuation-style behavior fixture

## Synthetic input

The manuscript supports one Major Concern and two Minor Comments. The review needs several explanatory transitions, parenthetical qualifications, and stable concern IDs.

## Expected behavior

- Write reviewer prose and post-review synthesis without relying on em dashes, en dashes, or colons as sentence connectors.
- Use a new sentence, comma, semicolon, parentheses, or a short label followed by a new line according to the grammatical relationship.
- Keep stable IDs such as `R1-M1` and established hyphenated terms such as `pre-submission`.
- Preserve punctuation in source-faithful titles, quotations, formulas, identifiers, URLs, times, and required machine-readable syntax when changing it would make the source or format inaccurate.
- Format concern headings without dash or colon punctuation, for example `R1-M1 [experimental-design]`.
- Format structured fields as bold labels followed by content, for example `**Severity** Major`.

## Forbidden behavior

- Do not repeatedly join clauses with dash punctuation or colons.
- Do not place a colon after every heading, label, or introductory phrase by habit.
- Do not replace punctuation mechanically when it belongs to a stable ID, compound term, formula, identifier, URL, time, title, faithful quotation, or required machine-readable syntax.
- Do not make sentences longer or less readable merely to avoid a punctuation mark.

## Pass/fail checklist

- [ ] No avoidable em-dash, en-dash, or colon punctuation appears in generated prose.
- [ ] Structured labels do not require trailing colons.
- [ ] Concern IDs and necessary hyphens remain correct.
- [ ] Replacement punctuation preserves the original logical relationship.
- [ ] Source-faithful and machine-readable material remains accurate.

# Reviewer-independence behavior fixture

## Synthetic request

The user supplies one complete manuscript and asks for three reviewer reports plus a synthesis. Reviewer 1 identifies a missing control. Reviewer 2 could independently identify the same issue or focus elsewhere. Reviewer 3 receives no special evidence. The execution environment supports isolated reviewer contexts.

## Expected behavior

- Fix all three emphasis briefs before generating any report.
- Give every reviewer the same immutable manuscript/source packet, common criteria, report skeleton, and only its own emphasis brief.
- Run Reviewer 1, Reviewer 2, and Reviewer 3 in separate contexts, subagents, processes, or invocations.
- Let every reviewer build its own fact assessment and private concern ledger.
- Freeze all three reports before comparing concern IDs or drafting synthesis.
- Allow natural duplication: if Reviewer 2 independently finds the missing control, preserve it in both reports.
- Generate `Cross-review synthesis (post-review; not shown to reviewers)` only after the reports are locked.
- Label the missing-control issue consensus only if at least two frozen reports independently raised it.
- Keep post-review deduplication inside the synthesis; preserve the original reviewer-local IDs.

## Forbidden behavior

- Do not pass Reviewer 1's report, notes, concern ledger, recommendation, or suspected concerns to Reviewer 2 or Reviewer 3.
- Do not tell a reviewer what another reviewer noticed or failed to notice.
- Do not write `as another reviewer noted`, `I agree with Reviewer 1`, or equivalent cross-review language inside an individual report.
- Do not use a shared concern ledger to assign issues across reviewers before drafting.
- Do not rewrite, suppress, add, or redistribute concerns after comparison to meet a duplication target or manufacture distinct personalities.
- Do not feed the synthesis back into any reviewer context.
- Do not claim mutual blindness if all reports were drafted in one shared context without an explicit limitation notice.

## Fallback when isolation is unavailable

- Produce one reviewer report per invocation, or clearly state before output that technical mutual blindness cannot be guaranteed.
- Never hide this limitation behind reviewer numbering or different writing styles.

## Pass/fail checklist

- [ ] Reviewer inputs contain no other reviewer output or analytical hints.
- [ ] Reviewer contexts are isolated.
- [ ] Reports are frozen before comparison.
- [ ] Individual reports contain no cross-review references.
- [ ] Natural overlap remains unchanged.
- [ ] Synthesis is clearly post-review and not shown to reviewers.
- [ ] Consensus is derived only from independently raised concerns.

# Severity-tiering behavior fixture

## Synthetic input

A complete synthetic manuscript claims that a diagnostic model generalizes across hospitals. The
Results report only a single-hospital internal random split and provide no external-site or temporal
validation. The Discussion repeats the broad generalization claim. In Figure 2, the main text
correctly defines the error bars, but the legend does not repeat that definition. The Abstract uses
the acronym `DHI` before defining it. No page or line numbers are supplied.

## Expected behavior

- Keep exactly three mutually blind anonymous reviewer reports plus a post-review synthesis generated only after the reports are frozen.
- Show separate `Major Concerns` and `Minor Comments` sections in every reviewer report; use
  `None identified from the supplied material` when a reviewer has no grounded item in one tier.
- Classify the unsupported cross-hospital generalization as a Major Concern under
  `clinical-validity`, `experimental-design`, or `claim-moderation`.
- Mark that Major Concern `Blocking Yes` because the supplied evidence does not establish the
  manuscript's central generalization claim. Allow either external/temporal validation or narrowing
  the claim as the resolution test.
- Classify the omitted Figure 2 legend definition and undefined Abstract acronym as Minor Comments
  because the supplied facts make them localized presentation corrections.
- Use uppercase `M` IDs for Major Concerns and lowercase `m` IDs for Minor Comments.
- Include a deduplicated minor-revision checklist in the synthesis and retain source concern IDs.

## Forbidden behavior

- Do not downgrade the unsupported central generalization claim to Minor because claim narrowing
  may be easy to write.
- Do not upgrade the legend or acronym issues to Major merely to make the review sound severe.
- Do not invent additional concerns, external datasets, hospitals, metrics, line numbers, or
  reviewer specialties.
- Do not use hostile or insulting phrasing to signal that a concern is serious.
- Do not list an issue as consensus unless at least two reviewer reports raise the same issue key.
- Do not pass one reviewer's report or concern ledger to another reviewer, and do not rewrite reports after comparison to control overlap.

## Pass/fail checklist

- [ ] Every reviewer visibly has Major and Minor sections.
- [ ] Major IDs use `M`; Minor IDs use `m`.
- [ ] Every Major Concern displays a calibrated Blocking flag.
- [ ] The central generalization gap is Major and Blocking.
- [ ] The two localized reporting issues remain Minor.
- [ ] Empty tiers are explicit and no severity quotas are used.
- [ ] The synthesis separates blocking, other major, and minor-checklist items.

from pathlib import Path


ROOT = Path(__file__).parents[1]


def read(relative: str) -> str:
    return (ROOT / relative).read_text(encoding="utf-8")


def test_severity_and_blocking_contract_is_present() -> None:
    router = read("SKILL.md")

    assert "Major Concerns" in router
    assert "Minor Comments" in router
    assert "Blocking Yes" in router
    assert "Minor Comments are never blocking" in router
    assert "Do not impose a concern quota" in router


def test_reviewers_are_isolated_before_synthesis() -> None:
    router = read("SKILL.md")

    assert "genuinely separate context" in router
    assert "Freeze each individual report before comparing" in router
    assert "not shown to reviewers" in router
    assert "Do not let one reviewer read" in router


def test_traceability_and_non_invention_are_required() -> None:
    router = read("SKILL.md")

    assert "claim_pointer" in router
    assert "evidence_pointer" in router
    assert "Do not invent experiments" in router


def test_punctuation_guard_is_part_of_the_reviewer_contract() -> None:
    router = read("SKILL.md")

    assert "Avoid em dashes, en dashes, and colons" in router
    assert "Do not use dash punctuation or colons" in router

# Traceable-review behavior fixture

## Synthetic input

A manuscript excerpt claims that treatment X causes outcome Y. The supplied Results section reports an observational association in Figure 2, but the excerpt contains no intervention, temporal analysis, or stated control strategy. No page or line numbers are supplied.

## Expected behavior

- Keep exactly three mutually blind anonymous reviewer reports plus a post-review synthesis generated only after the reports are frozen.
- Create at least one grounded concern under `causal-vs-correlative` or `experimental-design`.
- Classify the unsupported central causal claim as a Major Concern and display a calibrated
  `Blocking Yes` flag.
- Give the concern a stable ID, a faithful claim pointer, and an evidence pointer to `Results; Figure 2`.
- Use a resolution test that allows either stronger causal evidence or narrower associative language.
- Mark missing Methods detail as `not assessable` rather than asserting that controls were absent from the full manuscript.
- Include the concern in consensus only if at least two reports actually raise it.
- Preserve other supported single-reviewer concerns under weighting differences.
- Show both Major Concerns and Minor Comments sections without inventing a Minor Comment when the
  supplied excerpt does not support one.

## Forbidden behavior

- Invent a page number, line number, sample size, statistical result, control, or reviewer specialty.
- Present the internal 12-axis matrix in the user-facing report.
- Claim that the editor should accept or reject the manuscript.
- Add unrelated concerns merely to reduce reviewer overlap.
- Pass another reviewer's report, ledger, or suspected concern into an individual reviewer context.