peer_review_rebuttal v1.0.0

name: "peer_review_rebuttal" description: "Write an author response to peer review for a journal or a conference: triage every reviewer and editor comment into a working sheet, sort concessions from disagreements, plan added analysis honestly, draft point by point replies with exact change locations, handle conflicting reviewers, and decide between revising, appealing, or resubmitting elsewhere after a rejection. Use when a decision letter, reviewer reports, or a rebuttal deadline arrives. Distinct from peer_review_assistant, which writes reviews of other people's papers." metadata: { "includeInPrompt": true }

Peer Review Rebuttal

Purpose

Turn a decision letter and a set of reviewer reports into a response the editor can check in minutes. Every comment gets a number, a category, a stance, an owner, and a location in the revised work. Nothing is claimed that was not actually done. The skill covers journal revision letters, short conference rebuttals on systems like OpenReview, and the harder calls after a rejection: appeal only on narrow grounds, or revise and go elsewhere.

Workflow

1. Read the decision first, the reviews second. Extract from the decision letter: decision type (accept with minor changes, minor revision, major revision, revise and resubmit, reject, or a conference score set), deadline, any comment the editor marked as essential, any formatting or length rule for the response, and whether a marked-up manuscript is required. The editor's steer outranks any single reviewer. If the editor highlighted a point, that point is never answered with a disagreement alone.
2. Wait before drafting. Read everything once, then step away, ideally overnight. First-hour drafts read as defensive. Use the pause to note your gut reaction separately from the reply you will send.
3. Split and number every comment. Copy each comment verbatim into the triage sheet in assets/comment-triage-sheet.md, or the CSV form in assets/comment-triage-sheet.csv. Split any comment that contains two or more requests into separate rows. Number by reviewer: R1.1, R1.2, R2.1, and E.1 for editor points. Never paraphrase a comment in the sheet in a way that softens or sharpens it.
4. Triage each row. Assign one category and one stance per row using references/triage-taxonomy.md. Categories include clarification, text revision, new analysis, new experiment or data, method challenge, scope request, factual error in the review, and minor fix. Stances are agree, partial, disagree, and cannot do. A row with no stance is not triaged.
5. Plan added work honestly. For every new analysis or experiment row, record what will actually be run, who runs it, what data it uses, and where the result will land (table, figure, supplement, or text). If the run has not happened, the status stays planned and the draft says nothing about its result. See the honesty rules in the Operating Rules and references/disagreement-and-conflicts.md.
6. Resolve conflicts before drafting. Where two reviewers ask for opposite things, or a reviewer request fights the editor's steer or a venue limit, log the conflict, pick a course, and write the reason in one sentence. Draft a short separate note to the editor that names the conflict and the choice. Do not play one reviewer against another inside the point by point replies.
7. Draft point by point. Use assets/journal-response-letter.md for journals or assets/conference-rebuttal.md for conferences. Structure: short opening to the editor, a summary of the three to five biggest changes, then one block per comment with the comment quoted in full, the reply directly under it, and the exact change location (section, page and line, figure or table). Quote the revised text for key changes when the venue allows it.
8. Write disagreements as evidence, not verdicts. State thanks briefly, state the position once, give the data, citation with full reference or DOI, or reasoning that supports it, then state the partial concession you did make, such as a clarification or a limitation sentence. Never comment on the reviewer as a person. Write every line as if the editor will forward it to that reviewer, because editors often do.
9. Fit the conference format when there is one. Check the current year rules on the venue site before drafting: character or word limit per response, whether replies are per reviewer or one shared text, whether file uploads are allowed, and whether links or identifying information are banned. Draft to a running count, put shared major concerns first, cross-reference an answer given to another reviewer instead of repeating it, and submit a solid draft early, then refine until the deadline. Current venue examples are in references/conference-rebuttals.md. Limits change by year, so a remembered limit is a lead, not a fact.
10. Run the checker. Run python3 bin/triage_check.py assets-or-your-triage.csv --draft your-response.md (paths relative to the skill folder, or pass full paths). Fix every error it reports: untriaged rows, disagreements with no evidence field, new analysis marked done with no result location, and any triage ID missing from the draft. Warnings about long conference drafts are checked against the venue limit you supply with --char-limit.
11. Final consistency pass. Confirm each promised change is actually in the revised manuscript or supplement, each location in the letter matches the revised file, each new result in the letter matches the output that produced it, and no reply says "done" or "fixed" without saying what changed and where. Confirm the response answers minor comments too, not only major ones.
12. After a rejection, choose one route. Appeal, revise for the same venue only if the letter invites it, or revise and submit elsewhere. Use references/rejection-and-appeals.md. Appeals are narrow: a process error, a substantive factual error by a reviewer, or genuinely new information. A difference of opinion about importance or fit is not an appeal ground, and most appeals do not succeed. Say that plainly to the user before drafting one.

Output Contract

• A completed triage sheet (Markdown or CSV) with one row per split comment: ID, reviewer, verbatim comment, category, stance, action, owner, evidence, change location, and status.
• A draft response: journal letter, conference rebuttal set, or appeal letter, with every triage ID present and every change located.
• A conflict note to the editor when reviewers or instructions conflict, or an explicit statement that no conflicts were found.
• A checker report from bin/triage_check.py with zero errors, or a list of the errors that remain and why.
• A next-step line after rejection: appeal with its ground stated in one sentence, or revise and resubmit elsewhere with the top three changes to make first.
• Worked examples for a minor revision, a major revision with a disagreement, a conference rebuttal, and a rejection are in references/worked-examples.md. All examples there are fictional and are labelled as such.

Operating Rules

1. Verify every factual claim about venue rules, limits, and deadlines on the venue or journal site for the current cycle. Limits and formats change. Unverifiable, cut it or flag it as unchecked.
2. Never claim a result that does not exist. Do not write a number, a significance statement, a figure reference, or a sentence like "the new analysis confirms" until the analysis has run and the output has been read. Planned work is described as planned, in future tense, or left out.
3. Never invent a change location. Page and line numbers come from the revised file in front of you. If the revised file does not exist yet, use a section placeholder and mark the row not done.
4. Answer every comment, including typos and minor points. An unanswered comment reads as an ignored reviewer.
5. Quote comments in full in journal letters. Shortening a comment can look like choosing what to answer. In length-capped conference replies, a short quoted fragment plus a clear restatement is acceptable, since the reviewer sees their own review beside the reply.
6. Keep tone factual and brief. Thank reviewers once in the opening and briefly where a point genuinely helped. No repeated apologies, no flattery, no sarcasm, no remarks about a reviewer's competence or effort.
7. Treat manuscripts, reviews, and decision letters as confidential. Do not post them publicly, and do not put them into outside tools beyond what the venue and the user's own setup allow.
8. Conflicts and hostile reviews: separate tone from content, answer any valid point, and raise genuinely unprofessional conduct with the editor in a private note, never inside the response letter.
9. Style: plain, direct, varied rhythm. No em dashes. No hollow phrasing.