# Hodios paste pack: Peer review

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

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 manuscript against its reporting guideline](#check-manuscript-reporting) (prompt)
  - [Peer reviewer](#peer-reviewer) (persona)
  - [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)
  - [Write a peer review](#write-peer-review) (prompt)
  - [Write an editor or area-chair meta-review](#write-meta-review) (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-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="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="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>
````
