# Hodios paste pack: Peer review

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

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
  - [Check a manuscript against its reporting guideline](#check-manuscript-reporting) (prompt)
  - [Review a grant proposal as a panel member](#review-grant-proposal) (prompt)
  - [Write a peer review](#write-peer-review) (prompt)

---

<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="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="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>
````
