rebuttal-response

Name: rebuttal-response
Author: Boom5426

69installs28forks

How to install rebuttal-response?

boom5426/nature-paper-skills/rebuttal-response

$npx -y skills add Boom5426/Nature-Paper-Skills --skill rebuttal-response

Installs into the current project.

Summary

Use when responding to journal or conference reviewer comments and you need a structured author response, aligned manuscript edits, and clear decisions about when to clarify, add evidence, concede, or respectfully disagree.

Files · 1

View on GitHub

SKILL.md

1	# Rebuttal Response
2
3	## Overview
4
5	Use this skill when reviewer comments already exist and the task is no longer generic manuscript revision. The goal is to produce a response package that is credible, efficient, and easy for editors or reviewers to verify.
6
7	This skill is not for redesigning the whole paper. Use `manuscript-optimizer` first if the manuscript itself is structurally unstable. Use this skill when the paper is in revision mode and each comment must be turned into an explicit response and, where needed, a concrete manuscript change.
8
9	## When To Use
10
11	Use this skill when:
12	- Reviewer comments, decision letters, or revision requests are available
13	- The user needs a point-by-point response letter
14	- The manuscript and response document need to stay synchronized
15	- Some comments should lead to new analyses or text changes, while others should be answered by clarification
16	- The revision requires deciding where to concede and where to push back
17
18	Do not use this skill for:
19	- Initial manuscript drafting
20	- Submission-preflight QA before any reviewer feedback exists
21	- Generic peer review written from the reviewer side
22
23	## Response Principle
24
25	Every reviewer comment should end in exactly one of these outcomes:
26	- clarified in response only
27	- revised in the manuscript
28	- revised in both manuscript and response
29	- respectfully declined with justification
30
31	Do not leave a comment in the vague middle ground where the reply sounds polite but the action taken is unclear.
32
33	## Triage Categories
34
35	Classify each comment before writing:
36
37	- misunderstanding
38	The paper may already contain the answer, but it was not easy enough to find.
39	- clarity problem
40	The intended claim is defensible, but the wording or organization caused confusion.
41	- evidence gap
42	The reviewer is asking for support that is genuinely missing or too weak.
43	- scope mismatch
44	The request is reasonable in general but outside the paper's actual contribution or revision budget.
45	- incorrect premise
46	The reviewer comment is based on a factual or interpretive error.
47	- high-risk criticism
48	The comment challenges novelty, validity, leakage, controls, statistics, or overclaim.
49
50	Triage first. Only then decide what to change.
51
52	## Severity And Readiness
53
54	Assign each comment a severity:
55
56	- `minor`
57	presentation, clarity, formatting, citation, or small method-detail issue
58	- `major`
59	evidence, validation, method, statistics, interpretation, or scope issue that may affect editorial confidence
60	- `blocking`
61	ethics, compliance, data integrity, unsupported central claim, or another issue that should not be drafted around
62	- `unclear`
63	insufficient information to judge severity safely
64
65	Label the package honestly at the end:
66
67	- `ready_to_submit`
68	- `draft_with_placeholders`
69	- `needs_author_input`
70	- `blocked`
71
72	## Response Order
73
74	1. Parse all reviewer comments into atomic items.
75	2. Mark each item by triage category.
76	3. Decide the action:
77	- clarify
78	- edit text
79	- add analysis
80	- add experiment
81	- narrow claim
82	- decline with justification
83	4. Update the manuscript first when the response depends on a real change.
84	5. Write the response letter against the updated manuscript, not against the old draft.
85	6. Cite exact revised locations whenever possible:
86	- section
87	- figure
88	- table
89	- line or paragraph location if available
90	7. End with a short revision summary for the editor if the venue expects one.
91
92	## Editor-Efficiency Rule
93
94	Assume the editor is scanning quickly for three things:
95	- whether you agree or disagree with the comment
96	- what concrete revision was made
97	- where that revision can be found
98
99	Do not write replies that only say the manuscript was revised without specifying the change.
100
101	## Decision Rules
102
103	### When To Concede
104
105	Concede when:
106	- the reviewer correctly identifies an evidence gap
107	- a claim is stronger than the data
108	- wording created a reasonable misunderstanding
109	- a control, comparison, or limitation statement is missing
110
111	Best move:
112	- narrow the claim
113	- add the missing evidence if feasible
114	- explicitly thank the reviewer for improving precision
115
116	### When To Clarify Without Major New Work
117
118	Use clarification when:
119	- the result already exists but was buried
120	- the reviewer missed a definition, setup, or metric explanation
121	- the requested point can be handled by reorganizing text or adding cross-references
122
123	Best move:
124	- revise the manuscript for discoverability
125	- do not imply that a major scientific flaw was fixed if the issue was presentation
126
127	### When To Push Back
128
129	Push back only when:
130	- the request depends on a false premise
131	- the requested experiment is outside the paper's stated scope
132	- the request would require a different paper rather than a fair revision
133	- the current evidence

People who liked this also viewed

6 picks

Type

rebuttal-response

69installs28forks

View on GitHub

How to install rebuttal-response?

boom5426/nature-paper-skills/rebuttal-response

$npx -y skills add Boom5426/Nature-Paper-Skills --skill rebuttal-response

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Rebuttal Response
2
3	## Overview
4
5	Use this skill when reviewer comments already exist and the task is no longer generic manuscript revision. The goal is to produce a response package that is credible, efficient, and easy for editors or reviewers to verify.
6
7	This skill is not for redesigning the whole paper. Use `manuscript-optimizer` first if the manuscript itself is structurally unstable. Use this skill when the paper is in revision mode and each comment must be turned into an explicit response and, where needed, a concrete manuscript change.
8
9	## When To Use
10
11	Use this skill when:
12	- Reviewer comments, decision letters, or revision requests are available
13	- The user needs a point-by-point response letter
14	- The manuscript and response document need to stay synchronized
15	- Some comments should lead to new analyses or text changes, while others should be answered by clarification
16	- The revision requires deciding where to concede and where to push back
17
18	Do not use this skill for:
19	- Initial manuscript drafting
20	- Submission-preflight QA before any reviewer feedback exists
21	- Generic peer review written from the reviewer side
22
23	## Response Principle
24
25	Every reviewer comment should end in exactly one of these outcomes:
26	- clarified in response only
27	- revised in the manuscript
28	- revised in both manuscript and response
29	- respectfully declined with justification
30
31	Do not leave a comment in the vague middle ground where the reply sounds polite but the action taken is unclear.
32
33	## Triage Categories
34
35	Classify each comment before writing:
36
37	- misunderstanding
38	The paper may already contain the answer, but it was not easy enough to find.
39	- clarity problem
40	The intended claim is defensible, but the wording or organization caused confusion.
41	- evidence gap
42	The reviewer is asking for support that is genuinely missing or too weak.
43	- scope mismatch
44	The request is reasonable in general but outside the paper's actual contribution or revision budget.
45	- incorrect premise
46	The reviewer comment is based on a factual or interpretive error.
47	- high-risk criticism
48	The comment challenges novelty, validity, leakage, controls, statistics, or overclaim.
49
50	Triage first. Only then decide what to change.
51
52	## Severity And Readiness
53
54	Assign each comment a severity:
55
56	- `minor`
57	presentation, clarity, formatting, citation, or small method-detail issue
58	- `major`
59	evidence, validation, method, statistics, interpretation, or scope issue that may affect editorial confidence
60	- `blocking`
61	ethics, compliance, data integrity, unsupported central claim, or another issue that should not be drafted around
62	- `unclear`
63	insufficient information to judge severity safely
64
65	Label the package honestly at the end:
66
67	- `ready_to_submit`
68	- `draft_with_placeholders`
69	- `needs_author_input`
70	- `blocked`
71
72	## Response Order
73
74	1. Parse all reviewer comments into atomic items.
75	2. Mark each item by triage category.
76	3. Decide the action:
77	- clarify
78	- edit text
79	- add analysis
80	- add experiment
81	- narrow claim
82	- decline with justification
83	4. Update the manuscript first when the response depends on a real change.
84	5. Write the response letter against the updated manuscript, not against the old draft.
85	6. Cite exact revised locations whenever possible:
86	- section
87	- figure
88	- table
89	- line or paragraph location if available
90	7. End with a short revision summary for the editor if the venue expects one.
91
92	## Editor-Efficiency Rule
93
94	Assume the editor is scanning quickly for three things:
95	- whether you agree or disagree with the comment
96	- what concrete revision was made
97	- where that revision can be found
98
99	Do not write replies that only say the manuscript was revised without specifying the change.
100
101	## Decision Rules
102
103	### When To Concede
104
105	Concede when:
106	- the reviewer correctly identifies an evidence gap
107	- a claim is stronger than the data
108	- wording created a reasonable misunderstanding
109	- a control, comparison, or limitation statement is missing
110
111	Best move:
112	- narrow the claim
113	- add the missing evidence if feasible
114	- explicitly thank the reviewer for improving precision
115
116	### When To Clarify Without Major New Work
117
118	Use clarification when:
119	- the result already exists but was buried
120	- the reviewer missed a definition, setup, or metric explanation
121	- the requested point can be handled by reorganizing text or adding cross-references
122
123	Best move:
124	- revise the manuscript for discoverability
125	- do not imply that a major scientific flaw was fixed if the issue was presentation
126
127	### When To Push Back
128
129	Push back only when:
130	- the request depends on a false premise
131	- the requested experiment is outside the paper's stated scope
132	- the request would require a different paper rather than a fair revision
133	- the current evidence

People who liked this also viewed

6 picks

Type