nature-reviewer

Name: nature-reviewer
Author: Yuan1z0825

2.7kinstalls1.8kforks

How to install nature-reviewer?

yuan1z0825/nature-skills/nature-reviewer

$npx -y skills add Yuan1z0825/nature-skills --skill nature-reviewer

Installs into the current project.

Summary

Simulate a Nature-style reviewer assessment from the referee perspective rather than an author rebuttal. Use when the user wants a pre-submission review, reviewer report, peer-review style critique, novelty/significance/technical soundness assessment, reviewer-style manuscript ev

Files · 1

View on GitHub

SKILL.md

1	# Nature Reviewer Assessment Skill
2
3	Use this skill to simulate a `Nature`-style reviewer assessment package from the referee
4	side.
5
6	This skill is for reviewer-style manuscript evaluation, not for drafting the authors'
7	response. If the user wants rebuttal writing, route to `nature-response`.
8
9	## Default stance
10
11	- Ground the review only in the local source basis plus manuscript facts supplied by the user.
12	- Evaluate the manuscript against source-grounded axes: `originality`, `scientific importance`, `interdisciplinary readership`, `technical soundness`, and `readability for nonspecialists`.
13	- Use the 12-axis technical concern taxonomy only as an internal coverage checklist; it supplements but never replaces the five source-grounded axes.
14	- Return exactly `3 reviewer reports + 1 cross-review synthesis` unless the user explicitly asks for another structure.
15	- The three reviewers may differ only in `emphasis`; do not invent reviewer identities, specialties, institutions, or biographies.
16	- Identify who would be interested in the results and why.
17	- Identify technical failings that must be addressed before the authors' case is established.
18	- Give every substantive concern a stable ID, a faithful `claim_pointer`, and a verifiable `evidence_pointer`; mark missing locations instead of inventing them.
19	- Distinguish clearly between what is supported, what is weak, and what is not assessable from the provided material.
20	- 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.
21	- Do not claim the editor's final decision or certainty about fit to `Nature`.
22
23	## Accepted inputs
24
25	The skill may receive:
26
27	- full manuscript draft
28	- abstract, summary paragraph, or cover-summary style text
29	- introduction, results, discussion, or methods excerpts
30	- figure legends, selected figures, or result notes
31	- author notes in Chinese or English describing the claimed contribution
32	- pre-submission positioning notes
33
34	If the provided material is partial, perform a bounded review and mark the assessment boundary explicitly.
35
36	## Workflow
37
38	1. Identify the input scope and whether the job is a reviewer-style assessment rather than rebuttal drafting.
39	2. Extract a shared manuscript fact base: main claim, visible evidence, claimed significance, likely readership, and visible limitations.
40	3. Check readiness and label missing evidence or missing sections instead of inventing them.
41	4. Assess the manuscript using the source-grounded axes.
42	5. Build an internal concern ledger using `references/technical-concern-taxonomy.md`; record applicability, claim/evidence pointers, severity, and the resolution test for each supported concern.
43	6. If the manuscript clearly falls into a technical domain covered by `references/domain-specific-review-gates.md`, load only the relevant domain section and use it to sharpen the technical-soundness critique.
44	7. Generate `Reviewer 1`, `Reviewer 2`, and `Reviewer 3` using shared facts but different emphasis. Reuse ledger issue keys internally so repeated concerns can be measured and cross-referenced.
45	8. Generate a `Cross-review synthesis` that captures consensus and weighting differences. Label an issue as consensus only when at least two reviewer reports raise the same underlying concern.
46	9. Run QA for evidence anchoring, overlap, groundedness, coverage, role boundaries, and non-invention.
47
48	## Output format
49
50	Unless the user asks for another format, return:
51
52	```text
53	Review setup
54	- Input scope:
55	- Assessment boundary:
56	- Shared manuscript claim summary:
57	- Visible evidence base:
58	- Missing materials affecting confidence:
59
60	Reviewer 1
61	- Overall assessment:
62	- Who would be interested in the results, and why:
63	- Major strengths:
64	- Major concerns:
65	- Technical failings that need to be addressed before the case is established:
66	- Assessment against Nature-style criteria:
67	- Recommendation posture:
68
69	For each substantive concern:
70	- Concern ID: R1-M1
71	- Axis:
72	- Claim pointer:
73	- Evidence pointer:
74	- Concern and resolution test:
75
76	Reviewer 2
77	[Same structure]
78
79	Reviewer 3
80	[Same structure]
81
82	Cross-review synthesis
83	- Consensu

People who liked this also viewed

6 picks

Type

nature-reviewer

2.7kinstalls1.8kforks

View on GitHub

How to install nature-reviewer?

yuan1z0825/nature-skills/nature-reviewer

$npx -y skills add Yuan1z0825/nature-skills --skill nature-reviewer

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Nature Reviewer Assessment Skill
2
3	Use this skill to simulate a `Nature`-style reviewer assessment package from the referee
4	side.
5
6	This skill is for reviewer-style manuscript evaluation, not for drafting the authors'
7	response. If the user wants rebuttal writing, route to `nature-response`.
8
9	## Default stance
10
11	- Ground the review only in the local source basis plus manuscript facts supplied by the user.
12	- Evaluate the manuscript against source-grounded axes: `originality`, `scientific importance`, `interdisciplinary readership`, `technical soundness`, and `readability for nonspecialists`.
13	- Use the 12-axis technical concern taxonomy only as an internal coverage checklist; it supplements but never replaces the five source-grounded axes.
14	- Return exactly `3 reviewer reports + 1 cross-review synthesis` unless the user explicitly asks for another structure.
15	- The three reviewers may differ only in `emphasis`; do not invent reviewer identities, specialties, institutions, or biographies.
16	- Identify who would be interested in the results and why.
17	- Identify technical failings that must be addressed before the authors' case is established.
18	- Give every substantive concern a stable ID, a faithful `claim_pointer`, and a verifiable `evidence_pointer`; mark missing locations instead of inventing them.
19	- Distinguish clearly between what is supported, what is weak, and what is not assessable from the provided material.
20	- 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.
21	- Do not claim the editor's final decision or certainty about fit to `Nature`.
22
23	## Accepted inputs
24
25	The skill may receive:
26
27	- full manuscript draft
28	- abstract, summary paragraph, or cover-summary style text
29	- introduction, results, discussion, or methods excerpts
30	- figure legends, selected figures, or result notes
31	- author notes in Chinese or English describing the claimed contribution
32	- pre-submission positioning notes
33
34	If the provided material is partial, perform a bounded review and mark the assessment boundary explicitly.
35
36	## Workflow
37
38	1. Identify the input scope and whether the job is a reviewer-style assessment rather than rebuttal drafting.
39	2. Extract a shared manuscript fact base: main claim, visible evidence, claimed significance, likely readership, and visible limitations.
40	3. Check readiness and label missing evidence or missing sections instead of inventing them.
41	4. Assess the manuscript using the source-grounded axes.
42	5. Build an internal concern ledger using `references/technical-concern-taxonomy.md`; record applicability, claim/evidence pointers, severity, and the resolution test for each supported concern.
43	6. If the manuscript clearly falls into a technical domain covered by `references/domain-specific-review-gates.md`, load only the relevant domain section and use it to sharpen the technical-soundness critique.
44	7. Generate `Reviewer 1`, `Reviewer 2`, and `Reviewer 3` using shared facts but different emphasis. Reuse ledger issue keys internally so repeated concerns can be measured and cross-referenced.
45	8. Generate a `Cross-review synthesis` that captures consensus and weighting differences. Label an issue as consensus only when at least two reviewer reports raise the same underlying concern.
46	9. Run QA for evidence anchoring, overlap, groundedness, coverage, role boundaries, and non-invention.
47
48	## Output format
49
50	Unless the user asks for another format, return:
51
52	```text
53	Review setup
54	- Input scope:
55	- Assessment boundary:
56	- Shared manuscript claim summary:
57	- Visible evidence base:
58	- Missing materials affecting confidence:
59
60	Reviewer 1
61	- Overall assessment:
62	- Who would be interested in the results, and why:
63	- Major strengths:
64	- Major concerns:
65	- Technical failings that need to be addressed before the case is established:
66	- Assessment against Nature-style criteria:
67	- Recommendation posture:
68
69	For each substantive concern:
70	- Concern ID: R1-M1
71	- Axis:
72	- Claim pointer:
73	- Evidence pointer:
74	- Concern and resolution test:
75
76	Reviewer 2
77	[Same structure]
78
79	Reviewer 3
80	[Same structure]
81
82	Cross-review synthesis
83	- Consensu

People who liked this also viewed

6 picks

Type