# Hodios paste pack: Peer review

Everything in Peer review from Hodios, the open prompt library by Hermes IDE: 13 entries, catalog 2026.1004.3.

Every entry is dedicated to the public domain under CC0 1.0. Copy, change and share them freely, no attribution needed.

Browse and search the library at https://hermes-ide.com/prompts

## How to use

Find an entry below and copy the text inside its block into ChatGPT, claude.ai or any chat. Replace each [PLACEHOLDER] with your own material. Personas, rules and styles work best as custom instructions or project instructions.

## Contents

- Peer review
  - [Assess a paper's reproducibility](#assess-reproducibility) (prompt)
  - [Check a journal or conference for legitimacy](#check-journal-legitimacy) (prompt)
  - [Check a manuscript against its reporting guideline](#check-manuscript-reporting) (prompt)
  - [Peer reviewer](#peer-reviewer) (persona)
  - [Practise writing your first peer review](#practise-peer-review) (prompt)
  - [Review a grant proposal as a panel member](#review-grant-proposal) (prompt)
  - [Review a thesis chapter as an examiner would](#review-thesis-draft) (prompt)
  - [Review the statistics in a manuscript](#review-statistical-methods) (prompt)
  - [Score a batch of conference abstracts](#score-conference-abstracts) (prompt)
  - [Write a journal editor's decision letter](#write-editor-decision-letter) (prompt)
  - [Write a peer review](#write-peer-review) (prompt)
  - [Write an editor or area-chair meta-review](#write-meta-review) (prompt)
  - [Write the response-to-review section of a grant resubmission](#write-grant-resubmission-response) (prompt)

---

<a id="assess-reproducibility"></a>

## Assess a paper's reproducibility

`assess-reproducibility` · prompt · Peer review · https://hermes-ide.com/prompts/assess-reproducibility

Assesses a paper's reproducibility, covering data and code availability, methods detail, materials, preregistration and computational environment, and lists what a replicator would be missing.

````markdown
<context>
Reproducibility means another researcher can obtain the same results from the same data and code; replicability means a new study finds the same thing with new data. Both depend on what a paper discloses. Assessors look at: data availability (in a trusted repository with a persistent identifier, licence and documentation, or a justified restriction with a stated access route; "available on request" is weak), code availability (archived version, dependencies, environment, random seeds, instructions to run), materials and resources (reagents, antibodies with identifiers, cell-line authentication, organisms, instruments and settings, software versions), methods detail sufficient to repeat each step, analysis transparency (pre-registration or registered report, deviations reported, all outcomes reported), and whether the reported numbers can be traced from the data. Standards differ by field and data type: sensitive human data and qualitative data may justifiably be restricted, and that should not be penalised if access is explained.
</context>

<task>
Assess the reproducibility of this paper.
<paper>
[PAPER_TEXT]
</paper>

1. Identify the field, study type and the main claims, so the assessment focuses on what supports them.
2. Score each dimension as Available, Partial, Missing or Not applicable, with the evidence quoted from the text: data; code and computational environment; materials and resources; methods detail; pre-registration and deviations; outcome and analysis reporting completeness; traceability from data to reported numbers.
3. Act as a replicator: walk through the steps needed to reproduce the main result and list every point where you would have to guess or ask the authors (a parameter, a version, an exclusion rule, a preprocessing step, a seed, a recipe, a stimulus set).
4. Judge whether restrictions are justified (privacy, consent, third-party licences, biosafety) and whether a controlled-access route is given.
5. Write specific, polite requests to the authors that would close the gaps, in order of importance.
</task>

<constraints>
- Quote the text for every score. If the text supplied lacks a section (for example no data statement or no supplement), say so and score it as "Not provided in the text" rather than Missing.
- Do not claim you checked a repository, link or code; you have only the text unless the user gives more.
- Do not penalise justified restrictions on sensitive data; do flag unjustified "available on request".
- Separate reproducibility gaps from scientific criticism of the design, which belongs in a regular review.
- If only an abstract is supplied, say that reproducibility cannot be assessed and list what is needed.
</constraints>

<output_format>
## Overall assessment
Three sentences: how reproducible the main result is and the biggest gap.
## Scorecard
A table: dimension | score | evidence (quoted) | note.
## What a replicator would be missing
Numbered, in the order of the workflow.
## Requests to the authors
Numbered, most important first.
## Limits of this assessment
What could not be judged from the text supplied.
</output_format>
````

---

<a id="check-journal-legitimacy"></a>

## Check a journal or conference for legitimacy

`check-journal-legitimacy` · prompt · Peer review · https://hermes-ide.com/prompts/check-journal-legitimacy

Checks whether a journal or conference is legitimate or predatory using indexing, editorial, peer-review, fee and invitation signals, and lists exactly what to verify and where before submitting.

````markdown
<context>
Predatory journals and conferences take fees without providing real peer review, editing, indexing or archiving, and publishing in one can harm a career and waste good work. Hijacked journals go further by cloning a real journal's name and website. No single list is reliable, so checks combine signals: whether claimed indexing is real (DOAJ, Scopus source list, Web of Science Master Journal List, MEDLINE through the NLM Catalog, noting that being in PubMed Central is not the same as MEDLINE); whether the ISSN is registered; whether claimed memberships (COPE, OASPA) appear on those organisations' own member lists; whether the editorial board are real, relevant scholars who list the role themselves; whether peer review and fees are transparent; whether metrics are genuine (an impact factor comes only from Clarivate's Journal Citation Reports); and the tone and promises of invitations. The Think. Check. Submit. checklist summarises these. Legitimate new or small journals can fail some checks, so the result is a weighed judgement, not a single test.
</context>

<task>
Assess whether this venue is legitimate.
<journal>
[JOURNAL]
</journal>

1. Note what you were given and what is missing (website, ISSN, publisher). If the name is close to a well-known journal, raise the possibility of a hijacked or look-alike journal and say how to find the real journal's official site.
2. Assess each signal from the information given: identity (name, ISSN, publisher, address), claimed indexing and memberships, metrics, editorial board, peer-review description and promised timelines, fees and when they are disclosed, scope (narrow and coherent, or everything from medicine to engineering), archiving and licensing, retraction and correction policy, and for conferences the organiser, venue, past proceedings, and whether the event is repeated under many names. Mark each as concerning, reassuring, or unknown.
3. If an invitation was given, analyse it: flattery, generic greetings, unrelated topic, urgency, promised acceptance or review in days, requests to pay early, and sender address.
4. Give a verdict with a confidence level: likely legitimate, caution (verify before submitting), likely predatory, or cannot tell from the information. Explain which signals drove it.
5. List what to verify and where, in order of how much each check settles.
6. Say what to do if it is predatory or the author has already submitted or paid (withdraw in writing, do not sign copyright transfer, ask for confirmation, contact the institution's library or research office).
</task>

<constraints>
- Do not state that a venue is or is not indexed, a COPE member or on any list from memory; say what to check and where. If you recognise the name, you may say so, labelled as something to confirm.
- Do not call a venue predatory on one signal alone; new and regional journals legitimately lack some markers. Weigh the signals and show the reasoning.
- Avoid relying on any single blacklist or whitelist; explain why lists are a starting point only.
- Be specific and calm; the author may already have submitted.
</constraints>

<output_format>
## Verdict
The verdict, confidence, and the signals behind it in two to four sentences.
## Signals
A table: signal | what you found | concerning, reassuring or unknown.
## Invitation red flags
A list quoting the problem phrases, or "No invitation given".
## What to verify
A numbered checklist: check | where | what a good result looks like.
## If it is predatory
Steps for before and after submission or payment.
</output_format>
````

---

<a id="check-manuscript-reporting"></a>

## Check a manuscript against its reporting guideline

`check-manuscript-reporting` · prompt · Peer review · https://hermes-ide.com/prompts/check-manuscript-reporting

Checks a manuscript against its reporting guideline, such as CONSORT, PRISMA, STROBE, ARRIVE or COREQ, item by item, and lists what is missing and where to add it. For authors and reviewers.

````markdown
<context>
Reporting guidelines, collected by the EQUATOR Network, list the minimum information readers need to understand, appraise and replicate a study of a given design: CONSORT for randomised trials, SPIRIT for trial protocols, PRISMA for systematic reviews, STROBE for observational studies, ARRIVE for animal research, STARD for diagnostic accuracy, TRIPOD for prediction models, COREQ for interviews and focus groups, SRQR for qualitative research in general, CARE for case reports, and extensions for specific designs (such as cluster trials). Many journals require a completed checklist at submission. Checking reporting is not the same as judging quality: a well-reported study can still be weak, and a missing item is a reporting gap, not proof that something was not done.
</context>

<task>
Check this manuscript.
<manuscript>
[MANUSCRIPT]
</manuscript>

1. Identify the study design from the methods. Confirm the guideline fits, or choose the right one if none was given, and name any relevant extension (for example CONSORT for cluster trials, PRISMA for abstracts, STROBE extensions). If the stated guideline does not fit the design, say so and use the right one.
2. Go through the guideline item by item, in its order and grouped by its sections (title and abstract, introduction, methods, results, discussion, other information). For each item: a short paraphrase of what it asks, a status (reported, partly reported, not reported, not applicable), where it is reported (section and a short quote), and what to add if it is not fully reported.
3. Give special attention to the items reviewers most often find missing for this design, for example for trials: allocation concealment, who was blinded, the pre-specified primary outcome, the participant flow diagram, harms and registration; for systematic reviews: the full search strategy, the risk-of-bias method and certainty of evidence; for observational studies: the handling of confounders and missing data; for qualitative studies: researcher reflexivity and the sampling rationale.
4. Summarise: the number of items fully, partly and not reported, and the overall picture.
5. List the priority fixes: the gaps an editor or reviewer would most likely raise, with suggested wording or the information to add.
</task>

<constraints>
- Paraphrase checklist items in your own words, and do not reproduce long checklist text. Use item numbers only if you are confident of them for the version used; otherwise use section and topic labels, and tell the user to complete the official checklist from the guideline's website for submission.
- Judge only from the text provided. If figures, tables or supplements are referenced but not included, mark the dependent items "cannot check: [material] not provided".
- Do not assume something was done because it is usual; a missing item is "not reported".
- This is a reporting check, not a quality appraisal. Point to a risk-of-bias assessment if the user wants a judgement on validity.
- If the manuscript is long, check every item, keeping each table row short; do not skip sections.
</constraints>

<output_format>
## Guideline and design
Design, guideline used (with extension), and why.
## Summary
Counts by status and two or three sentences on the overall picture.
## Item-by-item check
Table: section | item (paraphrased) | status | where reported (quote) | what to add.
## Priority fixes
Numbered list, most important first, each with suggested wording or the information needed.
</output_format>
````

---

<a id="peer-reviewer"></a>

## Peer reviewer

`peer-reviewer` · persona · Peer review · https://hermes-ide.com/prompts/peer-reviewer

Fair, rigorous peer reviewer who separates fatal flaws from fixable issues, checks every claim against its evidence and writes respectful, actionable reviews. For refereeing and pre-submission reads.

````markdown
From now on, work as this persona: Peer reviewer.

You are an experienced peer reviewer who has refereed for journals and conferences across empirical fields and served as an associate editor. You review the way you would want to be reviewed: you read the whole paper carefully before judging it, you take the authors' aims seriously, and you hold the work to the standard its claims require.

How you work:
- You start by restating the paper's question, design, main findings and claimed contribution in your own words. If you cannot, the paper has a clarity problem, and you say so before anything else.
- You check every major claim against its evidence: does the design support the claim (especially causal and general claims), do the numbers in the abstract, text, tables and figures agree, are the effect sizes and uncertainty reported and meaningful, and are limitations acknowledged where they matter.
- You judge the methods against the question, not against the study you would have done. You consider the standard reporting guideline for the design and the field's norms, and you look at data, code and materials availability.
- You sort what you find: fatal flaws that the authors cannot fix with this study, major issues that could change the conclusions but can be addressed, and minor issues of clarity and presentation. You say which is which.
- For every issue you give the location, what the problem is, why it matters for the conclusion, and what would resolve it. You ask for new experiments or data only when the conclusions cannot stand without them.
- You make a recommendation that follows from the issues, and you are willing to recommend acceptance when the work is sound.

What you flag:
- Claims beyond the evidence: causal language from observational data, generalisation beyond the sample, "no effect" from a non-significant result, novelty asserted rather than shown.
- Analyses that do not match the design, unplanned multiplicity, selective reporting and unexplained exclusions.
- Missing information that would stop someone from evaluating or repeating the work.
- Possible research-integrity problems (duplicated images, impossible numbers, text overlap), raised only confidentially to the editor, with the evidence and without accusation.

Your habits:
- You are respectful and impersonal: you critique the work, never the authors, and you acknowledge real strengths.
- You do not ask authors to cite your own work or papers you cannot verify, and you never invent references.
- You declare when something is outside your expertise and suggest the editor seek a specialist reviewer.
- You keep manuscripts confidential, and you remind the person you help to check whether the venue allows AI assistance with review material.
- When helping authors before submission, you play the toughest fair reviewer they are likely to meet, then help them pre-empt the criticism.
````

---

<a id="practise-peer-review"></a>

## Practise writing your first peer review

`practise-peer-review` · prompt · Peer review · https://hermes-ide.com/prompts/practise-peer-review

Coaches an early-career researcher through writing a peer review of a manuscript, asking for their assessment section by section and critiquing the review they write rather than writing it for them.

````markdown
<context>
New reviewers learn by writing reviews and getting feedback on them, not by reading a model review. Common first-review mistakes: summarising instead of evaluating, nitpicking style while missing a design flaw, asking for a different study, mixing major and minor issues, making demands without saying why, an unkind or sarcastic tone, and a recommendation that does not follow from the comments. A good coach asks the trainee to commit to their own judgement first, then shows what a seasoned reviewer would also look at, and critiques the review as a piece of writing. Real manuscripts under review are confidential, and many journals forbid uploading them to AI tools.
</context>

<task>
Coach me through writing a peer review of this [FIELD] manuscript for a general journal.

<manuscript>
[MANUSCRIPT]
</manuscript>

This is a conversation. Ask, wait for my answer, then give feedback. Never write a section of the review for me before I have tried it.

First turn (Before we start):
1. Remind me in one or two sentences that a manuscript I received as a reviewer is confidential and may not be shared with AI tools under many journals' policies, and that practising on a published paper, a preprint or my own draft avoids the problem. If the text looks like a confidential submission, ask me to confirm I am allowed to use it before continuing.
2. Explain in three lines what an editor wants from a review: an assessment of whether the conclusions follow from the evidence, the most important problems ranked, and a recommendation that follows.
3. Ask me for my two- or three-sentence summary of what the paper claims and how. Stop.

Then work through these stages, one per turn, in this order: summary of claims; importance and fit for the journal type; methods and design; results and statistics; interpretation and limitations; presentation and reporting (including the reporting guideline usual in [FIELD]). For each stage:
4. Ask one or two focused questions that prompt my own assessment (for example "What would you need to see to believe the main effect is not confounded by age?").
5. When I answer, say what I got right, then name what an experienced reviewer would also check here and why, phrased as a question I can investigate rather than a ready-made verdict.
6. Ask me to turn my points into review comments, then critique the comments for specificity, evidence, actionability, tone and whether each is major or minor.

Final stage: ask me to assemble the full review and a recommendation. Then give Feedback on your review: a scorecard (accuracy of the summary, depth on methods, ranking of issues, actionability, tone, recommendation consistent with the comments), the three changes that would most improve it, and one strength to keep.
</task>

<constraints>
- Keep each turn short enough to read in two minutes, and end every turn with a question or task for me.
- Work only from the manuscript text. If a section, figure or table is missing, say so instead of guessing what it contains.
- Hold the paper to the standards of [FIELD]; if you are unsure of a field convention, say so.
- Push back if my criticism asks for a different study, is unfair, or is unsupported; explain how to rephrase it as a fair comment.
- If I ask you to just write the review, explain that the point is to practise, and offer a smaller step instead (for example, one model comment for comparison after I write mine).
- Do not invent references, statistics or quotes.
</constraints>

<output_format>
## Before we start
First turn only.
## Your turn
Each turn: brief feedback on my last answer, what an experienced reviewer would also check, then the next question or task.
## Feedback on your review
Final turn only: the scorecard as a table (Criterion | Rating 1-5 | Why), three improvements, one strength.
</output_format>
````

---

<a id="review-grant-proposal"></a>

## Review a grant proposal as a panel member

`review-grant-proposal` · prompt · Peer review · https://hermes-ide.com/prompts/review-grant-proposal

Reviews a grant proposal against the funder's criteria as a panel reviewer would, with strengths, weaknesses, a score rationale and ranked fixes. For applicants before submission and for reviewers.

````markdown
<context>
Panels decide quickly. A reviewer reads the summary and aims first and forms a view of significance and fit within minutes, then reads the approach looking for reasons the work might fail. Proposals lose points for an unclear central question, aims that depend on each other, preliminary data that do not support feasibility, vague methods ("appropriate statistical analyses"), unjustified sample sizes, ambition beyond the budget or timeline, missing risk mitigation, and budgets that do not match the work. Good reviews are specific, tie every comment to a criterion, separate major from minor weaknesses, and are written so the applicant can act on them. Scores should follow from the stated strengths and weaknesses, on the funder's own scale.
</context>

<task>
Review this proposal (pre-submission).
<proposal>
[PROPOSAL]
</proposal>

1. Summarise the proposal in three or four sentences: question, aims, approach, and the claimed contribution, so the applicant can see whether a reviewer understood it as intended.
2. For each criterion, list strengths and weaknesses, label each weakness as major (would likely lower the score substantially) or minor, and give a score on the funder's scale with a one-line rationale that follows from those points. Keep the scale's direction: on some scales a lower number is better (for example 1 = exceptional, 9 = poor), so state which end is best in the scores table. If no criteria were given, use the common ones and a five-point scale where 5 is best, and say so.
3. Check the things panels check: is the question clear and important; do the aims follow from it and stand independently; do preliminary data support feasibility; are design, sample size, analysis and rigour (controls, blinding, randomisation, reproducibility, or for qualitative work sampling and credibility) adequate; is the timeline realistic; are risks named with alternatives; does the team have the expertise; is the budget aligned with the work; are ethics, data management and impact addressed where required.
4. Give an overall impression: where the proposal would likely land (competitive, borderline, unlikely to be funded in its current form) and the single biggest reason.
5. For pre-submission feedback, rank the fixes by how much they would improve the score per hour of work, with concrete wording or structural suggestions. For an assigned review, phrase the output as a professional review the applicant would receive.
6. List the questions a panel discussion would raise.
</task>

<constraints>
- Base every comment on the proposal text. Quote or point to the passage. Do not assume facts that are not there, and do not invent the funder's criteria or scale.
- Be direct and fair: name real strengths, and do not soften major weaknesses into minor ones.
- Do not speculate about the applicants' identity, institution prestige or demographics; judge the proposal.
- For an assigned review, remind the user that proposals are confidential and that many funders do not allow reviewers to put proposal text into AI tools; tell them to check the funder's policy before using this for a real review.
- A mock score is not a prediction. Say so once.
</constraints>

<output_format>
## Overall impression
Two to four sentences with the likely standing and main reason.
## Scores by criterion
One line naming the scale and which end is best, then a table: criterion | score | rationale.
## Strengths
Bullets by criterion.
## Weaknesses
Bullets by criterion, each tagged (major) or (minor), with the passage it refers to.
## Fixes ranked by impact
Numbered list, highest impact first, each with a concrete suggestion.
## Questions a panel would ask
Bullets.
</output_format>
````

---

<a id="review-thesis-draft"></a>

## Review a thesis chapter as an examiner would

`review-thesis-draft` · prompt · Peer review · https://hermes-ide.com/prompts/review-thesis-draft

Reviews a thesis or dissertation chapter as an examiner would, judging contribution, argument, methods, use of literature and coherence, and returns prioritised revisions and likely defence questions.

````markdown
<context>
Examiners read a thesis asking whether the candidate has met the standard for the degree, and they judge each chapter by its job in the whole. A literature review should build a critical argument toward the gap, not summarise sources one by one. A methods chapter should justify choices against alternatives and show awareness of their limits. Results chapters should report findings clearly and connect them to the questions. Discussion chapters should interpret, relate findings to the literature, state the contribution and its limits precisely, and not overclaim. Common examiner concerns are a contribution that is not stated or not shown, chapters that do not connect, descriptive rather than critical writing, unjustified methods, and conclusions that go beyond the evidence. At master's level the bar is competent, independent, well-executed research; at doctoral level it is an original contribution to knowledge, usually of publishable quality.
</context>

<task>
Review this chapter at phd level.
<chapter>
[CHAPTER_TEXT]
</chapter>

1. Identify the chapter's type and its job in the thesis, and state its main argument in two sentences as an examiner would summarise it. If the argument cannot be stated, that is the first finding.
2. Assess against the criteria that fit the chapter type: contribution and originality (shown, not asserted), argument and structure (does each section advance it; signposting), methods and justification, use of literature (critical synthesis, currency, balance, accurate representation), quality of evidence and analysis, coherence with the thesis aims, and academic writing (clarity, precision, referencing consistency).
3. Rate each criterion as Meets the standard, Needs revision, or Major concern, at the given level, with the evidence from the text.
4. Prioritise revisions: Must fix before submission (would draw examiner criticism or affect the outcome), Should fix (would strengthen the chapter noticeably), and Could fix (polish). Give each a location and a concrete action.
5. List the five to eight questions an examiner would most likely ask about this chapter in the defence or viva, with a note on what a strong answer would cover.
6. Add up to ten line-level notes on the most important passages.
</task>

<constraints>
- Be honest and specific. Do not soften a major problem into a minor one, and do not invent problems to look thorough. If the chapter is strong, say so.
- Judge the work, not the candidate. Use a respectful, direct examiner's tone.
- Do not rewrite the chapter. Short example rewrites of one or two sentences are fine where they show the fix.
- Do not judge whether cited sources say what the chapter claims unless the text shows it; flag claims that look like they need checking.
- If the thesis aim is not given, infer it from the chapter, say so, and note where the assessment depends on it.
- Remind the user once that their institution's regulations and their supervisor's guidance decide what is required.
</constraints>

<output_format>
## Examiner's overall view
A short paragraph, including whether the chapter currently meets the phd standard.
## Strengths
Three to five bullets.
## Assessment by criterion
A table: criterion | rating | evidence | comment.
## Prioritised revisions
Three groups (must, should, could), each item with location and action.
## Likely examination questions
Numbered, with what a strong answer covers.
## Line-level notes
Quoted passage and note.
</output_format>
````

---

<a id="review-statistical-methods"></a>

## Review the statistics in a manuscript

`review-statistical-methods` · prompt · Peer review · https://hermes-ide.com/prompts/review-statistical-methods

Reviews a manuscript's statistics as a statistical referee would, checking design fit, assumptions, multiplicity, effect sizes, missing data and whether the conclusions follow from the analysis.

````markdown
<context>
Journals send papers to statistical reviewers because the errors that change conclusions are often statistical: an analysis that does not match the design (ignoring clustering, pairing or repeated measures), pseudoreplication, many outcomes or subgroups tested without a plan, p values without effect sizes or intervals, dichotomised continuous variables, complete-case analysis with substantial missing data, models with too many parameters for the events, selective reporting, and conclusions that go beyond what was estimated (causal claims from observational data, "no effect" from a non-significant test). A good statistical review is specific, explains why each issue matters for the conclusion, and asks for something the authors can do. It also says when the statistics are sound.
</context>

<task>
Review the statistics in this manuscript.
<manuscript>
[MANUSCRIPT_METHODS_AND_RESULTS]
</manuscript>

1. Summarise the design, the unit of analysis, the primary outcome, the estimand or main comparison, and the analysis, as you understand them. Note anything you had to infer.
2. Check the fit between design and analysis: independence of observations (clusters, repeated measures, multiple measurements per animal or participant), paired versus unpaired tests, correct model family for the outcome type, and adjustment for design factors such as stratification.
3. Check the sample size justification and whether the study was powered for the primary outcome; do not recommend post hoc power calculations.
4. Check assumptions and their diagnostics, model specification (covariate selection, overfitting relative to events or sample size, collinearity), and handling of outliers and transformations.
5. Check multiplicity: number of outcomes, time points, subgroups and models; whether a primary outcome was pre-specified (and matches any registration); and whether exploratory analyses are labelled.
6. Check reporting of estimates: effect sizes with confidence intervals, exact p values, consistency between text, tables and abstract. Recompute what can be recomputed from the given numbers (for example a p value from a test statistic and degrees of freedom, percentages from counts, whether reported means are possible for integer-scale data with the given n) and show the working.
7. Check missing data: amount by group, mechanism assumed, method used, and sensitivity analyses.
8. Judge whether the conclusions follow, especially causal language, generalisation and claims of "no difference" from non-significant results.
</task>

<constraints>
- Distinguish errors that could change the conclusions from matters of preference or presentation. Do not present a defensible alternative choice as an error.
- Every issue gives its location, the problem, why it matters for the conclusion, and a specific request (an analysis, a sensitivity check, a clarification or a change of wording).
- Ask for information rather than assuming the worst when the methods are unclear.
- Do not invent numbers. Recalculations use only reported values and show the formula and inputs.
- If the statistics are sound, say so plainly and keep the list of minor issues short.
- Start with one line reminding the reviewer that manuscripts under review are confidential and to check that the journal allows AI assistance.
</constraints>

<output_format>
One reminder line, then:
## Summary of design and analysis
One paragraph.
## Major statistical issues
Numbered: location - problem - why it matters - request.
## Minor statistical issues
Numbered, one or two lines each.
## Checks performed
A table: check | result | note (including any recalculations).
## Do the conclusions follow
Claim by claim, short.
## Recommendation on the statistics
Acceptable as is, minor revision, major revision, or requires re-analysis, with the deciding reasons.
</output_format>
````

---

<a id="score-conference-abstracts"></a>

## Score a batch of conference abstracts

`score-conference-abstracts` · prompt · Peer review · https://hermes-ide.com/prompts/score-conference-abstracts

Scores a batch of conference abstracts consistently against the committee's criteria, with a short evidence-based justification each and flags for borderline cases, conflicts and missing information.

````markdown
<context>
Abstract scoring drifts. The first abstracts get scored harder or softer than the last, a well-known lab's name nudges the score up, a fluent abstract is mistaken for a rigorous one, and borderline submissions get the same flat middle score with no reason. Committees need scores that apply one standard to every abstract, a short justification that points to the text, and honest flags where a human must decide: borderline cases, possible conflicts, missing results, or work outside the call. These scores are a first pass to help a reviewer, who signs off every score; final decisions stay with the committee.
</context>

<task>
Score these abstracts on a 1-5 scale per criterion.

<criteria>
[CRITERIA]
</criteria>

<abstracts>
[ABSTRACTS]
</abstracts>

1. Write scoring anchors before scoring: for each criterion, one line per score level (or for the lowest, middle and top levels if the scale is long) describing what an abstract at that level looks like. Apply weights exactly as the criteria state. If the scale is categorical (for example accept / weak accept / weak reject / reject), do not turn it into numbers: rate each criterion in the categories and give an overall recommendation with the rule you used to combine them, stated once.
2. Score each abstract against the anchors, criterion by criterion. Base every score on what the abstract states: the question, the method, the sample or data, the results (or whether results are still pending), and the relevance to the track. Ignore author names, institutions and writing polish beyond what the clarity criterion covers.
3. Justify each abstract in one to three sentences that cite specific content ("n=12 single-site pilot, no comparison group" rather than "weak methods").
4. Flag, without letting the flag change the score:
   - Borderline: total within one point of the cut-off the chairs gave (without one, the abstracts around the expected acceptance rate, or the middle third of the ranking), or criteria that disagree sharply.
   - Conflict: an author or institution matching the reviewer's affiliations, or an obvious personal connection.
   - Missing information: no results, no method, or claims that cannot be judged from the abstract.
   - Scope: outside the call or track.
   - Integrity: possible duplicate submission, results that look implausible, or ethics concerns (for example human participants with no mention of approval where the field expects it).
5. Calibration pass: sort by total, reread the top three, the bottom three and every borderline abstract against the anchors, and adjust any score that drifted. Report what you changed.
6. Before you answer, check that every abstract has a score for every criterion, numeric totals add up with the weights, and no justification relies on author identity.
</task>

<constraints>
- Start with one line reminding the user that submissions are confidential, to check the conference's policy on AI tools, and that they are responsible for the final scores.
- Never infer quality from author names, institutions, countries or language fluency.
- Do not invent results or details missing from an abstract; score what is there and flag what is missing.
- Use the committee's scale and criteria exactly; do not add criteria of your own.
- If the criteria or scale are missing or unclear, ask for them before scoring and stop.
</constraints>

<output_format>
One reminder line, then:
## Scoring anchors
A table per criterion: Score | What it looks like.
## Scores
Table: Abstract id | one column per criterion | Weighted total (or overall recommendation on a categorical scale) | Justification.
## Flags
Table: Abstract id | Flag type | Detail. "None" if there are none.
## Ranking and calibration notes
The abstracts ranked by total, the adjustments made in the calibration pass and why, and any pattern the committee should know (for example many abstracts with pending results).
</output_format>
````

---

<a id="write-editor-decision-letter"></a>

## Write a journal editor's decision letter

`write-editor-decision-letter` · prompt · Peer review · https://hermes-ide.com/prompts/write-editor-decision-letter

Drafts the author-facing letter for a journal decision already made, from desk reject to accept, with essential and optional revisions, reviewer conflicts resolved and wording that cannot be misread.

````markdown
<context>
Authors read the decision letter more closely than anything else the journal sends, and they read it for what it lets them do next. A good one states the decision in the first two sentences using the journal's decision category, tells authors which concerns they must address for the paper to be acceptable and which are optional, resolves conflicting reviewer requests instead of passing them on, says exactly what to submit and by when, and is courteous without false encouragement. Poor letters forward the reviews with a one-line verdict, leave authors to satisfy contradictory demands, promise acceptance after a major revision, blur "reject" and "reject and resubmit" so authors cannot tell whether a new submission is welcome, or turn a desk reject into a page of criticism nobody asked for. This prompt drafts the letter once the editor has decided; weighing the reports to reach a decision is a separate job. Review material is confidential, and some journals restrict the use of AI tools with it.
</context>

<task>
Draft the decision letter. Decision: major.

<editor_notes>
[EDITOR_NOTES]
</editor_notes>

1. Consistency check. Compare the decision with the reviews and the editor's notes. If the decision seems at odds with them (for example "minor" when a reviewer reports a flaw in the main analysis that the editor does not dismiss, or a reason in the notes that is about the authors rather than the paper), say so and say what would reconcile it. Do not change the decision yourself.
2. Write the letter. Every letter opens with the manuscript title and number (or placeholders), the decision in plain words in the first two sentences, and one or two sentences on why, in terms of the paper's contribution and the main issues. Then, by decision:
   - accept: the final checks still needed (data availability statement, reporting checklist, figure files, licence or copyright form) and what happens next (proofs, publication).
   - minor or major: "Essential revisions", numbered, each stating the problem, why it matters and what would resolve it, with its source (R1, R2 or Editor). Merge overlapping reviewer points. Where reviewers conflict, state which approach the editor prefers, following the editor's notes. Then "Optional suggestions", numbered and short. Then what to submit (a point-by-point response, a marked-up version) and the deadline from the notes or a placeholder. For major, say plainly that the revised paper will be re-reviewed and that acceptance is not guaranteed; for minor, say whether it will go back to reviewers or be checked by the editor.
   - reject-resubmit: say that this version is declined and a new submission is welcome, list the changes a new submission would need, and say it will be treated as a new manuscript, possibly with new reviewers.
   - reject: the main reasons, respectfully and specifically enough to help the authors elsewhere; a transfer offer only if the notes include one; no wording that implies a resubmission here is welcome.
   - desk-reject: short. The editor's reason in two or three sentences, that the paper was not sent for review so this is not a judgement of its full scientific merit, and a pointer to more suitable venues only if the notes give one. Do not add criticisms of your own.
   - Close courteously, refer to the reviewer reports below (except for a desk reject), and leave a signature placeholder.
3. Before you answer, check that every essential revision traces to a reviewer or the editor's notes, nothing in the letter reveals or hints at reviewer identity, the decision wording in the opening matches major, and the tone fits it.
</task>

<constraints>
- Start with one line reminding the user to check that the journal allows AI assistance with confidential review material.
- Do not introduce new scientific criticisms of your own; if you notice a gap, put it in the note to the editor.
- Do not repeat hostile or personal remarks from a review in the letter; flag them in the note to the editor.
- Do not promise acceptance, and do not invent journal policies, deadlines or transfer options; use placeholders.
- If the decision is anything but desk-reject and the reviews are missing, or the editor's notes are too thin to justify the decision, ask for them and stop.
</constraints>

<output_format>
One reminder line, then:
## Consistency check
Two or three sentences: consistent, or the mismatch and what would resolve it.
## Decision letter
The letter, ready to edit, with placeholders in square brackets.
## Note to the editor
Points for the editor only: reviewer comments not to forward as written, possible conflicts, gaps you noticed, or "None".
</output_format>
````

---

<a id="write-peer-review"></a>

## Write a peer review

`write-peer-review` · prompt · Peer review · https://hermes-ide.com/prompts/write-peer-review

Writes a constructive manuscript review with a summary, major and minor issues, methodological and reporting concerns, and a reasoned recommendation. Use when refereeing a paper.

````markdown
<context>
Editors value reviews that show the reviewer understood the paper, separate fatal problems from fixable ones, explain why each issue matters, and say what would resolve it. Authors value reviews that are specific and respectful. Weak reviews are vague ("the methods are unclear"), demand a different study, insist on citing the reviewer's own work, or nitpick style while missing a design flaw. Peer-review manuscripts are confidential, and many publishers restrict uploading them to AI tools, so the reviewer remains responsible for following the venue's policy and for every judgement in the report.
</context>

<task>
Review this manuscript:
<manuscript>
[MANUSCRIPT]
</manuscript>

1. Before judging, summarise the paper's question, design, main findings and claimed contribution in your own words.
2. Assess whether the question matters and whether the contribution is new, judging only from what the manuscript itself shows and cites.
3. Check the methods against the question: design, sample and power, measures, controls, analysis choices, handling of missing data and multiple comparisons, and whether the conclusions follow from the results. Name the reporting guideline that applies (for example CONSORT, STROBE, PRISMA, ARRIVE, COREQ, TRIPOD) and note the important items missing.
4. Check reproducibility: availability of data, code and materials, and whether the methods are described well enough to repeat.
5. Sort issues into major (could change the conclusions or the decision) and minor (clarity, presentation, small analyses). For each major issue give the location, the problem, why it matters and what would resolve it.
6. Make a recommendation (accept, minor revision, major revision or reject) that follows from the major issues.
</task>

<constraints>
- Every issue points to a specific section, table, figure or line and proposes a resolution. No vague criticism.
- Stay within the paper's aims: do not ask for a different study, and request new experiments or data only when the conclusions cannot stand without them.
- Do not ask the authors to cite particular papers unless a missing citation is needed for a specific claim, and never suggest references you cannot verify.
- Be respectful and impersonal: critique the work, never the authors. Acknowledge real strengths.
- Do not speculate about the authors' identity or intentions. Raise suspected misconduct (duplicated images, impossible numbers, plagiarism) only in the confidential comments, with the evidence.
- If the text provided is only part of the manuscript, say so and limit the review to what you can see.
- Start the report with one line reminding the reviewer to check that the venue permits AI assistance and to keep the manuscript confidential.
</constraints>

<output_format>
One reminder line, then:
## Summary
One paragraph.
## Overall assessment
Strengths and the main concerns in three to five sentences.
## Major issues
Numbered: location — problem — why it matters — what would resolve it.
## Minor issues
Numbered, one or two lines each.
## Reporting and reproducibility
The guideline that applies, missing items, and data and code availability.
## Recommendation
The recommendation and the two or three reasons that decide it.
## Confidential comments to the editor
Anything not for the authors, or "None".
</output_format>
````

---

<a id="write-meta-review"></a>

## Write an editor or area-chair meta-review

`write-meta-review` · prompt · Peer review · https://hermes-ide.com/prompts/write-meta-review

Writes an editor or area-chair meta-review that synthesises referee reports, resolves disagreements on the merits, states the decision rationale and lists required and optional changes.

````markdown
<context>
A meta-review is not an average of scores. The editor or area chair weighs the arguments, decides which concerns are valid and decisive, resolves disagreements by reasoning about the evidence and the reviewers' expertise, and explains the decision so authors know what would change it. Weak meta-reviews restate each review in turn, count votes, introduce new objections without saying so, or leave authors unsure what to do. Good ones are short, specific, fair to authors and reviewers, and consistent with the venue's criteria. Review material is confidential, and some venues restrict the use of AI tools with it.
</context>

<task>
Write the meta-review.
<reviews>
[REVIEWS]
</reviews>

1. Summarise the submission and its claimed contribution in two or three sentences.
2. Identify the points of consensus: strengths and concerns raised by more than one reviewer or uncontested.
3. Identify the disagreements. For each, state both positions, weigh them on the merits (is the concern supported by the paper's content, did the author response address it, which reviewer has the relevant expertise or engaged more closely), and say how you resolve it and why.
4. Separate decisive issues (would change the decision) from secondary ones.
5. Recommend a decision using the venue's options, and give the rationale in terms of the venue's criteria. If the reviews do not support a clear decision, state the options and what would tip the balance.
6. List the required changes for acceptance and the optional suggestions, each traceable to a reviewer or marked as the meta-reviewer's own.
7. Note anything the editor or programme chairs should know confidentially: a review that is unprofessional, superficial or shows a possible conflict of interest, or suspected misconduct with the evidence.
</task>

<constraints>
- Base the decision on the arguments in the reviews and the paper's content as described, not on score averages.
- Mark any new concern you raise as your own; do not attribute it to reviewers.
- Do not reveal reviewer identities or speculate about authors' identities.
- Do not let personal or irrelevant factors (the authors' reputation, prior disputes) influence the recommendation; if the user asks for that, decline and explain briefly.
- Keep the tone respectful and impersonal. Disregard or downweight hostile or unsupported remarks, and say so in the confidential note rather than repeating them to authors.
- Start with one line reminding the user to check that the venue allows AI assistance with confidential review material.
</constraints>

<output_format>
One reminder line, then:
## Meta-review
Summary, consensus, disagreements and their resolution, decision and rationale, in 250 to 450 words unless the venue template says otherwise.
## Required changes
Numbered, with source (R1, R2, AC).
## Suggested changes
Numbered, with source.
## Note to the editor or programme chairs
Confidential points, or "None".
</output_format>
````

---

<a id="write-grant-resubmission-response"></a>

## Write the response-to-review section of a grant resubmission

`write-grant-resubmission-response` · prompt · Peer review · https://hermes-ide.com/prompts/write-grant-resubmission-response

Writes the introduction or response-to-review section of a grant resubmission, grouping criticisms by theme, stating each change and where it is, and disagreeing with evidence.

````markdown
<context>
A resubmission is read by a panel that may include new members who never saw the first version. The response section has to work on its own: it shows that the applicants understood the critique, that the application is now stronger, and exactly where to find each change. Panels mark down responses that go reviewer by reviewer and repeat every minor point, that grovel or argue, that claim changes the new text does not contain, or that ignore the criticisms that actually drove the score. Strong responses lead with the issues that mattered most, group overlapping criticisms into themes, answer each with a concrete change and its location, and disagree rarely, briefly and with evidence. Funders set their own rules for this section (length, whether to mark changes in the text, what may be included), and those rules change, so the applicant must check the current instructions.
</context>

<task>
Write the response-to-review section for this resubmission, within 1 page(s).

<reviews>
[REVIEWS]
</reviews>

<changes_made>
[CHANGES_MADE]
</changes_made>

1. Extract every distinct criticism from the reviews. Note who raised it, whether more than one reviewer or the panel discussion raised it, and whether it was named as a major weakness or a reason for the score.
2. Group the criticisms into themes (for example rationale, approach and feasibility, rigour and statistics, team and environment, preliminary data). Rank themes by how much they drove the score.
3. Match each criticism to an item in the changes made. List any criticism with no matching change as a gap. Do not invent a change to fill it.
4. Draft the response:
   - An opening of two or three sentences: thank the reviewers once, name the main improvements, and say how the changes are shown in the text if the funder's instructions allow marking.
   - One short paragraph per theme, in rank order. Start with a neutral paraphrase of the concern (not a long quote), then the change, then its location (aim, section, page or figure).
   - Where the applicants did not make a change, say so plainly and give the evidence: a citation, new data, a feasibility argument or a design reason. Keep the tone factual and never suggest the reviewer misread the application.
   - Mention strengths the reviewers praised only if a change might seem to threaten them.
5. Fit the space: estimate the length (about 500 words per page at typical grant formatting, to be checked against the funder's font and margin rules) and cut minor points into a single closing sentence if needed.
6. Before you answer, check that every change you state appears in the changes made, every location matches, every major criticism is answered or listed as a gap, and the draft fits the page limit.
</task>

<constraints>
- Never state a change, a result or new data that is not in the changes made.
- Do not reveal or guess reviewers' identities, and do not quote critiques at length.
- Avoid flattery, apology and defensiveness; one line of thanks is enough.
- Do not state the funder's formatting rules as fact; tell the applicant to check the current instructions for this scheme.
- If the reviews or changes are too thin to match (for example only a score, or "we revised everything"), ask for the specific critiques or the list of changes and stop.
</constraints>

<output_format>
## Gaps to close first
Criticisms with no matching change, each with a suggested action (change the application, add a sentence of rebuttal with evidence, or accept and explain). "None" if there are none.
## Response to review
The section text, ready to paste, with theme headings in bold if space allows. State the estimated length.
## Criticism to change map
Table: Criticism | Raised by | Theme | Change made | Location.
## Notes for the applicant
Up to five points: funder rules to check, places where the new application should be strengthened to match the response, and any tone risk.
</output_format>
````
