# Hodios paste pack: Literature review Everything in Literature review from Hodios, the open prompt library by Hermes IDE: 20 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 - Literature review - [Appraise a study's risk of bias](#appraise-study-quality) (prompt) - [Build a database search strategy](#build-search-string) (prompt) - [Build a literature matrix](#build-literature-matrix) (prompt) - [Chase citations from seed papers](#chase-citations) (prompt) - [Extract effect-size data for a meta-analysis](#extract-data-for-meta-analysis) (prompt) - [Find research gaps](#find-research-gaps) (prompt) - [Literature review track](#literature-review-track) (workflow) - [Plan a scoping review](#plan-scoping-review) (prompt) - [Plan and interpret a meta-analysis](#plan-meta-analysis) (prompt) - [Read a research paper together, section by section](#read-paper-with-me) (prompt) - [Reconcile conflicting studies](#reconcile-conflicting-studies) (prompt) - [Research librarian](#research-librarian) (persona) - [Run a rapid evidence review](#run-rapid-evidence-review) (prompt) - [Screen titles and abstracts](#screen-studies) (prompt) - [Set up a reference manager library for a thesis or project](#set-up-reference-library) (prompt) - [Summarise a research paper](#summarize-paper) (prompt) - [Write a literature review section](#write-literature-review-section) (prompt) - [Write a PRISMA flow report](#write-prisma-flow-report) (prompt) - [Write a systematic review protocol](#write-systematic-review-protocol) (prompt) - [Write an annotated bibliography](#write-annotated-bibliography) (prompt) --- ## Appraise a study's risk of bias `appraise-study-quality` · prompt · Literature review · https://hermes-ide.com/prompts/appraise-study-quality Appraises a study's risk of bias with the tool that fits its design, such as RoB 2, ROBINS-I, CASP or Newcastle-Ottawa, justifying each judgement with quotes. For reviewers and practitioners. ````markdown Critical appraisal asks how much a study's result can be trusted, and the right questions depend on the design. Risk-of-bias tools structure that judgement: RoB 2 for randomised trials (randomisation process, deviations from intended interventions, missing outcome data, measurement of the outcome, selection of the reported result; Low risk, Some concerns or High risk); ROBINS-I for non-randomised studies of interventions (confounding, selection of participants, classification of interventions, deviations from intended interventions, missing data, measurement of outcomes, selection of the reported result; Low, Moderate, Serious or Critical); the Newcastle-Ottawa Scale for cohort and case-control studies (selection, comparability, outcome or exposure); CASP or JBI checklists for qualitative and other designs; QUADAS-2 for diagnostic accuracy; AMSTAR 2 for systematic reviews. A judgement is only credible when it is tied to what the paper actually reports. Reporting quality and risk of bias are different things: a well-written paper can still be biased, and a poorly reported one gets "no information", not a guess. Appraise this study. [STUDY] 1. Identify the design from the methods (not from the title or the authors' label) and choose the tool. If the stated design and the methods disagree, say so and appraise the design actually used. If your review protocol specifies a tool or tool version, it overrides this choice. 2. If the tool judges one result at a time, name the result and, for trials, the effect of interest (assignment to the intervention, the usual intention-to-treat effect, unless the user says otherwise). 3. Go through every domain or checklist item of the tool. For each: the signalling questions or criteria you considered, the answer, the judgement, and a supporting quote from the text with its location. Where the paper is silent, write "no information" and say what you would need. 4. Give the overall judgement using the tool's own rule: for RoB 2, low only if every domain is low, high if any domain is high or if several domains have some concerns that together substantially lower confidence in the result, otherwise some concerns; for ROBINS-I, at least as severe as the worst domain; for the Newcastle-Ottawa Scale, stars per section and the total, noting that totals hide which section failed; for checklists without an overall score (CASP, JBI), a reasoned summary rather than a count of yes answers. 5. Explain in plain words what the main risks mean for the result: in which direction the bias would push the estimate, if that can be reasoned, and how much it matters. 6. Say what information would change the judgement, such as a protocol, trial registration, or details on allocation concealment. - Every judgement needs a quote or a precise pointer to the text. No quote, no judgement: use "no information" or "unclear". - Do not reward or penalise on reputation, journal, sample size alone or statistical significance; these are not risk-of-bias domains. - Paraphrase the tool's signalling questions rather than reproducing whole checklists, and tell the user to complete the official form for publication. - Separate reporting gaps from evidence of bias. - If only an abstract is provided, say an appraisal is not possible on that basis, list the information needed, and give at most a provisional view clearly labelled as such. - Appraisal involves judgement; in a systematic review it should be done independently by two reviewers. Say so once. ## Design and tool Design as identified, tool chosen and why, result and effect being appraised. ## Domain judgements Table: domain or item | key questions considered | judgement | supporting quote (location). ## Overall judgement One line with the overall rating, then two to four sentences on what it means for the result. ## What would change the judgement Bullets. ```` --- ## Build a database search strategy `build-search-string` · prompt · Literature review · https://hermes-ide.com/prompts/build-search-string Builds a Boolean search strategy for PubMed, Scopus, Web of Science or Google Scholar with concepts, synonyms, controlled vocabulary, filters and a search log. For systematic and narrative reviews. ````markdown A review is only as good as its search. Good strategies split the question into a few concepts, capture each concept with both controlled vocabulary (MeSH in PubMed, Emtree in Embase, subject headings elsewhere) and free-text synonyms, combine synonyms with OR and concepts with AND, and adapt the syntax to each database's field tags. Common failures are searching the whole question as one phrase, adding too many concepts (which kills recall), forgetting spelling variants and truncation, and filters that silently drop relevant records. Systematic reviews favour sensitivity and must be reproducible to the character; narrative reviews can trade some recall for precision. Build a search strategy for: [RESEARCH_QUESTION] Databases: PubMed, Scopus, Web of Science, Google Scholar 1. Frame the question with the framework that fits (PICO or PECO for interventions and exposures, PCC for scoping reviews, SPIDER or PEO for qualitative questions). Decide which two to four elements become search concepts; outcomes and comparators are usually left out of the search to protect recall, and say why for each element you drop. 2. For each concept, list: controlled-vocabulary terms per database (with explode or no-explode choices), free-text synonyms, British and American spellings, abbreviations, and truncation or wildcards. Mark any subject heading you are not certain exists with "(verify)". 3. Write one complete, copy-ready string per database in its own syntax: PubMed field tags such as [tiab] and [Mesh]; Scopus TITLE-ABS-KEY(); Web of Science TS=; Ovid line-by-line with numbered sets where Ovid is listed. For Google Scholar, write a short string under its length limit and explain that it is a supplementary source, not a reproducible database search. 4. Recommend filters and limits (date, language, study design, humans) with the trade-off of each. Prefer validated search filters for study design (for example the Cochrane highly sensitive search strategy for randomised trials in PubMed) over database limits, and name the filter rather than reproduce it from memory if you are not sure of its exact text. 5. Explain how to test the strategy: check it retrieves the known key papers, and if not, which concept or term caused the miss; look at the first 50 results for precision; adjust. 6. Add supplementary methods suited to the review type: citation chasing, trial registries, preprint servers, grey literature. - Never run, cite or count results you have not seen. You write strings; the user runs them and records counts. - Use correct Boolean grouping with parentheses, and keep each concept in its own bracketed OR block. - Do not invent MeSH or Emtree terms. Flag uncertain ones with "(verify)" and tell the user to check them in the database's thesaurus browser. - If the question is too vague to search (no clear population, exposure or phenomenon), propose two or three searchable versions and ask which to use before writing strings. - If the review is systematic, recommend having the strategy peer reviewed (PRESS checklist) and involving a librarian. ## Question framing Framework table: element | content | searched (yes or no) | why. ## Concept table Table: concept | controlled vocabulary (per database) | free-text terms. ## Search strings One fenced code block per database, labelled with the database and interface. ## Filters and limits Bullets with trade-offs. ## Testing the strategy Numbered steps. ## Search log An empty table to fill in: database | interface | date run | string version | results | notes. ```` --- ## Build a literature matrix `build-literature-matrix` · prompt · Literature review · https://hermes-ide.com/prompts/build-literature-matrix Extracts a comparison matrix across several papers (question, design, sample, findings, limitations) with every cell traceable to its source. Use when organising sources for a literature review. ````markdown A literature matrix (also called an evidence or synthesis table) puts every study on the same row structure so the reviewer can compare them and write a thematic synthesis instead of a list of summaries. It is only useful if it is faithful: a cell that paraphrases loosely, fills a gap with a guess or mixes up two papers poisons every later step of the review. Build a matrix from these sources: [PAPERS] Columns: citation, research question, design, sample and setting, measures, key findings, limitations 1. Give each paper a short ID (first author + year, adding a/b for duplicates) and use it in every section. 2. Fill one row per paper and one cell per column, using that paper's text only. 3. Keep numbers exactly as written, with units and the comparison they belong to (for example "OR 1.42, 95% CI 1.10-1.83, smokers vs non-smokers"). 4. When a value is not stated, write "NR" (not reported). When you derived it rather than read it (for example a design you inferred from the description), add "[inferred]" and keep the inference minimal. 5. After the table, record anything that made extraction uncertain and the patterns a reviewer should check next. - Never fill a cell from general knowledge about the paper or its authors. NR is a correct answer. - Keep each cell under about 25 words; put longer detail in the extraction notes. - Use the same vocabulary across rows (for example always "RCT", "cohort", "cross-sectional") so the columns can be sorted and compared. - If the input looks like a single paper, or the papers cannot be told apart, say so and ask how to split them before building the table. - Patterns are prompts for the reviewer to verify, not conclusions. Do not rank studies as better or worse unless a quality column was requested. ## Matrix A Markdown table with "ID" as the first column, then the requested columns, one row per paper in chronological order. ## Extraction notes Bullets: ID, the cell, and what was ambiguous, missing or inferred. "None" if clean. ## Patterns to check Three to five bullets naming agreements, disagreements or differences in design, population or measures across rows, each citing the IDs involved. ```` --- ## Chase citations from seed papers `chase-citations` · prompt · Literature review · https://hermes-ide.com/prompts/chase-citations Plans backward and forward citation chasing from seed papers with the right tools, screening, iteration rounds, a stopping rule and a search log fit for reporting. ````markdown Citation searching follows the links between papers: backward through the reference lists of seed papers, and forward to the later papers that cite them. It finds studies that keyword searches miss because of inconsistent terms, and the TARCiS statement recommends it as a supplementary method for most systematic searches, with its terms and processes reported precisely. Results depend on the seed set: seeds that are all from one group or one database will reproduce that group's citation network. Tools differ in coverage (Web of Science, Scopus, Google Scholar, OpenAlex, Semantic Scholar, Lens) and visual tools such as citation-network mappers help with discovery but are hard to report reproducibly. Without a stopping rule, chasing never ends; without a log, it cannot be reported. Plan citation chasing from these seeds: [SEED_PAPERS] 1. Check the seed set: how many, whether each meets the review's eligibility criteria, spread across years, authors, countries, designs and terminology. Point out clusters (for example three seeds from the same lab) and the kinds of seed to add. If the review topic or the role of chasing is not stated, ask before planning. 2. Plan backward chasing: extract reference lists (from full texts or a database's reference export), deduplicate against records already screened, and screen with the same criteria and process as the main search. 3. Plan forward chasing: which two complementary sources to use for "cited by" and why (one curated index plus one broad open index is a good default), export format, deduplication, and how to handle preprints and later versions of the same work. 4. Plan iteration: what counts as a new seed for the next round (newly included studies only), how many rounds are allowed, and how to record the generation each record came from. 5. Set the stopping rule: stop when a round yields no new included studies, or at a stated maximum of rounds, or when the remaining yield per hour drops below a stated level; state which applies. 6. Mention optional adjacent methods (co-citation and similar-article features, contacting authors) and how to report them separately if used. - Do not invent references, citation counts or DOIs, and do not claim which papers cite the seeds; that comes from running the searches. - Name tools by what they do and their coverage limits; mark any feature or limit you are unsure about as "to check". - Keep screening identical to the main search (same criteria, same reviewers) so results are comparable. - The plan must be reportable: every step leaves a date, source, count and file. ## Seed set check A table: seed | eligible? | year | group or country | note. Then the gaps and suggested additions. ## Chasing plan Numbered steps for backward, forward and iteration, each with tool, export, deduplication and screening. ## Stopping rule The rule in one sentence, with the numbers. ## Search log template A table with columns: round | direction | seed | source | date | records retrieved | after deduplication | screened in | included. ## Reporting text A short methods paragraph describing the citation searching, with [placeholders] for dates and counts. ```` --- ## Extract effect-size data for a meta-analysis `extract-data-for-meta-analysis` · prompt · Literature review · https://hermes-ide.com/prompts/extract-data-for-meta-analysis Builds a data-extraction form and extracts effect-size inputs from study reports with their locations, logging every conversion and flagging missing statistics. For meta-analysis teams. ````markdown Extraction errors are common in meta-analyses and often go unnoticed: a standard error copied as a standard deviation, a change score mixed with a final value, the wrong time point, a per-protocol number used where intention-to-treat was planned, or a cluster trial treated as individually randomised. Good practice is a piloted form, duplicate extraction, a recorded source location for every number, and an explicit log of every derived value and the formula used, so a second extractor and the reader can check it. Missing statistics are requested from authors or handled by a pre-specified method, never filled in by guesswork. Extract data for the outcome "[OUTCOME]" from these studies. [STUDY_TEXTS] 1. Build the extraction form for this outcome: study identifiers, design and unit of randomisation, population, arms and their definitions, time point, analysis population (ITT or per protocol), measure and direction (whether higher is better), and the statistics needed for the outcome type (continuous: n, mean, SD per arm or a between-group difference with its CI or SE; binary: events and n per arm; time-to-event: HR with CI), plus adjusted or unadjusted, and notes. 2. Extract every field for each study, quoting the location (section, table or figure) for each number. Use "not reported" when absent. When several candidates exist (time points, scales, analysis sets), list them and say which matches the outcome definition and why. 3. Where the needed statistic is not reported directly but can be derived, derive it and log it: SD from SE (SD = SE × √n), SD from a 95% CI of a mean (for large samples, SD = √n × (upper − lower) / 3.92, using the t distribution for small samples), SE of a difference from its CI or from an exact p value and test statistic, and standardised mean differences from t or F for two groups. For medians with IQR or range, flag skew, name the estimation method if one is used, and recommend a sensitivity analysis excluding the estimated values. 4. Flag unit-of-analysis issues: cluster designs (needs the ICC or a design effect), crossover trials, multi-arm trials sharing a control group, and multiple outcomes from the same participants. 5. Where inputs are complete, compute the effect size the user's outcome implies (for example Hedges' g with its variance, mean difference, log odds ratio or log risk ratio) and show the inputs. Mark these as needing verification in statistical software. - Never estimate, impute or "approximately read" a number that the text does not give or that cannot be derived exactly from given numbers. Graph-only data are marked "figure only; digitise with a plot-digitising tool and record it". - A p value reported as "p < 0.05" cannot be used to derive a statistic; say so. - Keep the direction of effect consistent across studies and record when a scale had to be reversed. - Show every calculation with its inputs so a second extractor can check it. - If a study's text is too partial to extract from, say what is missing rather than extracting from the abstract alone without saying so. ## Extraction form A table: field | definition | allowed values. ## Extracted data One table per outcome: study | design | arm | n | statistic(s) | time point | analysis set | location. ## Conversions log Numbered: study | derived value | formula | inputs | result. ## Missing or unclear Per study: what is missing, whether to contact authors, and the exact request to send. ## Effect sizes A table of computed effects with variance or CI, or "not computable" with the reason. ```` --- ## Find research gaps `find-research-gaps` · prompt · Literature review · https://hermes-ide.com/prompts/find-research-gaps Identifies gaps, contradictions and open questions across a set of abstracts or notes, ties each to its sources and turns it into a researchable question. Use when scoping a thesis, grant or review. ````markdown "No one has studied X" is the most common unsupported claim in theses and grant proposals. A real gap is specific (what is unknown, for whom, under which conditions), sits in a body of evidence the writer can cite, and matters for theory or practice. Gaps also come in kinds that call for different studies: an evidence gap, a contradiction between findings, a population or context nobody has sampled, a method that was never applied, a theory that was never tested, or knowledge that never reached practice. Analyse these sources: [SOURCES] 1. Give each source a short ID (first author + year) if it has none, and map what the set covers: questions, populations, settings, designs, measures and time periods. 2. Find gaps of these kinds, and only where the sources support them: evidence gap, contradictory findings, population or context gap, methodological gap, theoretical gap, practice gap. 3. For each contradiction, propose the most likely explanations visible in the sources (different populations, measures, designs, time periods, analysis choices) before calling it unresolved. 4. Turn the strongest gaps into specific, answerable research questions, each with a design that could answer it. 5. Rate your confidence in each gap. A gap visible only because this set is small or narrow is low confidence. - Every gap and contradiction cites the IDs that show it. If you cannot point to sources, it is not a gap; drop it. - The sources are a sample, not the literature. Never write "no study has…"; write "none of these sources…", and say what search would confirm the gap. - Do not bring in studies from memory as evidence. You may name a search term, database or kind of study to look for. - If the sources are too few or too unrelated to compare (for example fewer than three on the same topic), say so and give what you can, marked as preliminary. - Prefer three strong gaps to ten thin ones. ## Coverage Four to six bullets on what the set covers and what it is mostly made of (designs, populations, years). ## Gaps A table: # | kind | the gap in one sentence | evidence (IDs and what they show) | why it matters | confidence (high / medium / low). ## Contradictions For each: the finding in conflict, the IDs on each side, likely explanations. "None found" if none. ## Open questions Numbered research questions, each with a suggested design and the gap number it addresses. ## Before you claim a gap Three to five concrete searches (terms, databases or review types) to run before writing that the gap exists. ```` --- ## Literature review track `literature-review-track` · workflow · Literature review · https://hermes-ide.com/prompts/literature-review-track Takes a literature review from research question and search strategy through screening, an extraction matrix and a written synthesis, with approval between steps. For students and researchers. ````markdown Runs a literature review on "[RESEARCH_QUESTION]" the way a supervisor would expect: a protocol first, a reproducible search, transparent screening, a faithful extraction matrix, then a thematic synthesis. Each step writes one artifact and stops for approval, and later steps build on the approved artifacts instead of re-asking. Rules for every step: work only from records and texts the user supplies or that you retrieved with a search tool in this session; never invent a paper, citation, DOI or count; say "not reported" or "not available" instead of guessing; and keep a running list of decisions so the review can be reported honestly (for example with PRISMA for systematic reviews). ## Steps Work through these steps in order. Do not skip a gate. 1. question (plan) 2. search (discover) 3. screen (discover) 4. extract (discover) 5. synthesize (build) ### Step 1: Question and protocol Turn "[RESEARCH_QUESTION]" into a review protocol the rest of the track can follow. 1. Ask, in one message, only what you need and cannot infer: the purpose (thesis chapter, article, grant, policy brief), the review type they need or can afford (narrative, scoping, systematic, rapid), the deadline, the citation style, and any must-include sources or databases they have access to. If the question is too broad to search, propose two or three narrower versions to choose from. 2. Restate the question with the framework that fits it: PICO or PECO for interventions and exposures, PEO or SPIDER for qualitative and mixed questions, PCC for scoping reviews. Show each element. 3. Write inclusion and exclusion criteria: population, intervention or phenomenon, comparator, outcomes, study designs, languages, publication years and publication types (for example peer-reviewed only, or including preprints and grey literature), each with a one-line reason. 4. List the main concepts the search must cover, and the outcome or themes the synthesis will report. Write the protocol as Markdown with sections Question, Framework, Criteria, Concepts, Deliverable (with review type and citation style). Flag any criterion that will make the review too narrow (very few studies likely) or too broad (thousands of records). Stop and wait for approval. Save this step's result to `reviews/literature-review/01-protocol.md`. **Gate:** stop here and wait for the user's approval before step 2 (search). ### Step 2: Search strategy Using the approved protocol, design a search that someone else could rerun and get the same records. 1. For each concept, list synonyms, spelling variants, truncation (for example `adolescen*`) and the database's controlled vocabulary where one exists (MeSH for PubMed, Emtree for Embase, ERIC descriptors, APA Thesaurus terms). Flag any subject heading you are not sure exists. 2. Combine terms with OR inside a concept and AND across concepts, then write one string per database, adapted to its syntax and field tags. 3. Add supplementary methods: backward and forward citation chasing from key papers, grey literature sources that fit the field, and trial or preprint registries where relevant. 4. If you have a web or literature search tool, run the strings, and record the date, the database and the number of results for each. If you do not, give the strings and ask the user to run them and paste back the exported records (titles, abstracts and citation details). Write a search log as Markdown: a table of database | string | date run | results, followed by the supplementary methods. Never list papers you did not retrieve in this session or receive from the user, and never estimate a result count you did not see. Stop and wait for approval and for the records. Save this step's result to `reviews/literature-review/02-search-log.md`. **Gate:** stop here and wait for the user's approval before step 3 (screen). ### Step 3: Screening Screen the records the user supplied against the approved criteria. 1. Remove duplicates (same title and first author, or same DOI) and count them. 2. Screen titles and abstracts. For each record give a decision, include, exclude or unsure, and for exclusions the single criterion that fails (for example "wrong population", "not empirical", "outside date range"). Treat "unsure" as include for full-text review; it is cheaper to read one more paper than to miss one. 3. Screen the full texts the user then provides, with a reason for every exclusion. 4. Count records at each stage: identified, duplicates removed, screened, excluded at title and abstract, full texts assessed, excluded with reasons, included. For a narrative or rapid review, a decisions table and the final counts are enough; note what you simplified. Write the screening record as Markdown: a decisions table (ID | citation | decision | reason) and the counts laid out as a PRISMA-style flow in text. For a systematic review, remind the user that a second, independent screener on at least a sample of records is expected, and how to report agreement. Stop and wait for approval and for the full texts of included studies. Save this step's result to `reviews/literature-review/03-screening.md`. **Gate:** stop here and wait for the user's approval before step 4 (extract). ### Step 4: Extraction and appraisal Extract data from the included studies into one matrix. 1. Use these columns unless the protocol says otherwise: ID (first author + year), aim, design, setting and country, sample (size and who), exposure or intervention, comparator, outcomes and measures, key findings with numbers, limitations, funding. 2. Fill each cell from that study's text only. Copy numbers exactly. Write "NR" when a value is not reported and add "[inferred]" when you derived it rather than read it. 3. Appraise each study with a tool that fits its design and say which one you used, for example RoB 2 for randomised trials, ROBINS-I for non-randomised interventions, the CASP or JBI checklists for qualitative and observational studies, and MMAT for mixed methods. Give the overall judgement and the one or two domains that drive it. For a narrative review, a short strengths-and-limitations note per study may replace the tool. 4. Note anything that makes studies hard to compare (different measures, follow-up times or definitions). Write the matrix and the appraisal table as Markdown, followed by extraction notes listing every NR, every inference and every judgement call. Stop and wait for approval. Save this step's result to `reviews/literature-review/04-matrix.md`. **Gate:** stop here and wait for the user's approval before step 5 (synthesize). ### Step 5: Synthesis Write the review's synthesis from the approved matrix and appraisal, answering "[RESEARCH_QUESTION]". 1. Group the findings into themes that answer the question, not one paragraph per study. For quantitative findings that cannot be pooled, use a structured narrative synthesis: group by outcome, report direction and size of effects, and give weight to the stronger designs and lower risk of bias. 2. For each theme, write a topic sentence that makes a claim, the evidence from several studies, and why studies agree or differ. 3. State how confident the evidence lets you be for each main finding (for example strong, moderate, limited, conflicting) and why, in the spirit of GRADE where it applies. 4. Close with the gaps the review exposes and the limitations of the review itself: databases searched, languages, single screener, date of search. 5. Cite only included studies, in the citation style set in the protocol (APA if none was given), and add the reference list. Write the synthesis as Markdown with a methods summary paragraph (search, screening counts, appraisal tools), the thematic findings, the gaps, the limitations and the references. Finish with what the user must check before submitting: missing citation details, claims resting on one study, counts to confirm. Save this step's result to `reviews/literature-review/05-synthesis.md`. ```` --- ## Plan a scoping review `plan-scoping-review` · prompt · Literature review · https://hermes-ide.com/prompts/plan-scoping-review Plans a scoping review from a topic, first testing whether scoping is the right review type, then the PCC question, iterative search, selection, charting form and PRISMA-ScR reporting. ````markdown Scoping reviews map the extent, range and nature of evidence on a topic, clarify concepts, or identify gaps; they do not answer a question about effectiveness. The usual framework is Arksey and O'Malley as refined by Levac and colleagues and JBI: identify the question, identify relevant studies, select studies, chart the data, collate and report, with optional stakeholder consultation. They are reported with PRISMA-ScR and the protocol is usually registered on OSF or published. The common mistakes are using a scoping review because a systematic review sounds like too much work, writing a question too vague to set eligibility criteria, appraising quality and then drawing effectiveness conclusions, and charting forms that collect everything and summarise nothing. Plan a scoping review on this topic. [TOPIC] 1. Decide whether a scoping review fits. Compare it with a systematic review, rapid review, evidence gap map and narrative review for this purpose, and recommend one. If another type fits better, say so plainly and give the reason. Continue with the scoping plan only if mapping still serves the purpose (for example to check whether enough studies exist before a systematic review), and say what it can and cannot conclude; otherwise stop after the recommendation and list what the better-fitting review needs next. 2. Write the review question and two or three sub-questions, and the PCC elements (Population, Concept, Context) with definitions precise enough to apply consistently. 3. Write eligibility criteria per PCC element plus evidence sources (primary studies, reviews, grey literature, policy documents), languages and dates, each with a reason. 4. Plan the search: databases suited to the field, grey literature and registries, the three-step JBI approach (initial limited search to harvest terms, full search, reference lists), a draft concept-block structure with [TERM TO CONFIRM] placeholders, and the role of an information specialist. 5. Plan selection: pilot on 25 to 50 records until agreement is acceptable, two reviewers, how criteria may be refined iteratively and how that is documented. 6. Design the charting form: fields that each map to a sub-question, with a definition and allowed values, plus a pilot on a few sources and a rule for when the form may change. 7. Plan collation: descriptive counts, tables and charts by key characteristics, and a basic qualitative content analysis where it serves the sub-questions; state whether critical appraisal will be done and why (it is optional and never turns findings into effectiveness claims). 8. Optional consultation with stakeholders: who, when and what for. 9. Give a realistic timeline for the team size implied. - Do not invent existing reviews, study counts or thesaurus terms; tell the user to search for existing and ongoing scoping reviews (for example in OSF, JBI Evidence Synthesis and databases) before going further. - Every criterion must be one two reviewers would apply the same way; replace vague words like "relevant" with definitions. - Keep conclusions within scope: the plan must not promise to establish what works. - Name PRISMA-ScR and the registration route; say that PROSPERO does not register scoping reviews. ## Is a scoping review right The comparison in a short table (review type | answers | fits this purpose?) and the recommendation. ## Question and PCC The question, sub-questions, and a table: element | definition | include | exclude. ## Plan Numbered sections for search, selection, collation, consultation and timeline, with the draft search structure in a code block. ## Charting form A table: field | definition | allowed values or format | sub-question served. ## Reporting and registration PRISMA-ScR items to plan for now, and the registration route. ## Open decisions Choices left to the team, with the options. ```` --- ## Plan and interpret a meta-analysis `plan-meta-analysis` · prompt · Literature review · https://hermes-ide.com/prompts/plan-meta-analysis Plans and interprets a meta-analysis, deciding whether to pool, the effect measure and model, heterogeneity, subgroup and sensitivity analyses, publication-bias checks and certainty. For review teams. ````markdown A meta-analysis is only as meaningful as the decision to combine the studies. Experienced reviewers first ask whether the studies answer the same question closely enough to pool, then choose an effect measure that suits the outcome and is comparable across studies, and a model that matches their assumptions: a random-effects model when true effects are expected to vary (usually), with REML or Paule-Mandel estimates of between-study variance and, with few studies, the Hartung-Knapp-Sidik-Jonkman adjustment. Heterogeneity is described with tau², a prediction interval and I² with its confidence interval, never I² alone. Subgroup analyses and meta-regression are few, pre-specified and interpreted as observational. Funnel-plot methods need roughly ten or more studies and detect small-study effects, not proof of publication bias. Certainty is rated with GRADE. Plan a meta-analysis for this question and, if pooled results are given, interpret them. [QUESTION] [INCLUDED_STUDIES_SUMMARY] 1. Decide whether pooling is appropriate: compare populations, interventions, comparators, outcomes, designs and risk of bias. If some studies should not be combined, say which and why, and propose separate analyses or a structured narrative synthesis (SWiM). 2. Choose the effect measure for each outcome (mean difference, standardised mean difference with Hedges' correction, risk ratio, odds ratio, risk difference, hazard ratio) and explain the choice, including how to handle different scales, change versus final scores and mixed binary and continuous reporting. 3. Choose the model and estimator, and the confidence-interval method, with the reason, and say what changes if there are fewer than about five studies. 4. Handle dependencies: multi-arm trials, cluster and crossover designs, and several effect sizes per study (choose one by rule, or use a multilevel model or robust variance estimation). 5. Plan heterogeneity assessment and at most a few subgroup analyses or meta-regressions tied to a stated rationale, with the minimum number of studies per covariate. 6. Plan sensitivity analyses: excluding high risk-of-bias studies, influence and leave-one-out diagnostics, alternative estimators or models, and imputed or converted data. 7. Plan small-study and publication-bias checks suitable for the number of studies, and say which ones not to run if there are too few. 8. If pooled results are provided, interpret them: the effect and its CI in plain words, the prediction interval, clinical or practical importance against a stated threshold, how heterogeneity and bias limit the conclusion, and a provisional GRADE rating per domain. - Do not recommend pooling studies just because the software allows it; a precise average of incompatible studies is misleading. - Never present a fixed-effect result as the main analysis when heterogeneity is expected, without justification. - Do not invent study results or pooled numbers. If you illustrate, label numbers as hypothetical. - If a decision should have been pre-specified in the protocol, say so, and treat post hoc choices as exploratory. - Name software options generically (for example the metafor or meta packages in R, Stata, RevMan) only as examples. ## Should these studies be pooled Verdict and reasons, with any studies to analyse separately. ## Analysis plan A table: outcome | effect measure | model and estimator | CI method | dependency handling. ## Heterogeneity and subgroups What to report and the pre-specified subgroups with rationale. ## Sensitivity and small-study effects The analyses and when each applies. ## Interpretation Only if results were given: plain-language reading, prediction interval, importance, limits, provisional GRADE table. ## Reporting The PRISMA 2020 items this plan feeds, and the forest and funnel plots to produce. ```` --- ## Read a research paper together, section by section `read-paper-with-me` · prompt · Literature review · https://hermes-ide.com/prompts/read-paper-with-me Reads a research paper with the user one section at a time, explaining terms and methods at their level and asking questions that check understanding before moving on. For learning to read papers. ````markdown People learn to read research by doing it with someone who knows how: read the abstract and figures first to get the map, then work through the sections asking what each one is for, what the authors did and why, and whether the evidence supports the claim. A summary skips that learning. A good reading partner explains at the reader's level, checks understanding with questions rather than lectures, separates what the paper says from interpretation, and points out where even experienced readers should slow down (the methods behind the headline result, the comparison actually made, the size and uncertainty of effects, and the limitations the authors underplay). Read this paper with me. My level: student. [PAPER_TEXT] This is a conversation, one section per turn. First turn: 1. Give a map: the question the paper asks, the type of study, the main claim, and the list of sections we will read, in a recommended order (for most papers: abstract, figures and tables, introduction, methods, results, discussion). 2. Read the first section with me (step 3), then stop. Each later turn, for the next section: 3. Explain what this section is for, then go through it in short chunks: what it says in plain words, terms and methods explained at my level (add each new term to a running glossary), and one note on what a careful reader notices here. 4. Ask me one or two questions that check understanding, not memory (for example "Why do you think they used a control group here?" or "What would the result look like if the effect were zero?"). Wait for my answers. 5. When I answer, tell me what I got right, correct misunderstandings kindly and precisely, and then move to the next section only when I say so. After the last section: summarise what the paper shows and does not show, give the three strongest and three weakest points, show the glossary, and suggest what to read next to understand it better (types of sources, not invented titles). - Work only from the text provided. If a section, figure or table is missing, say so and do not guess what it contains. - If the input is only a title, DOI, link or abstract, say that you cannot read the paper from that and ask for the full text (or offer to read just the abstract, clearly limited). - Match the level: for student, define every technical term and statistical result in plain words; for practitioner, focus on methods, applicability and effect sizes; for expert, keep explanations short and go straight to design choices, assumptions and alternative explanations. - Keep each turn short enough to read in two or three minutes. Never dump the whole paper at once. - Mark your own interpretation and critique as such, separate from what the authors claim. - Do not invent references, numbers or quotes. ## Map of the paper First turn only. ## Section reading The section name as a heading, chunked explanation, a "careful reader notices" note, and the glossary additions. ## Check your understanding One or two questions, then stop and wait. ```` --- ## Reconcile conflicting studies `reconcile-conflicting-studies` · prompt · Literature review · https://hermes-ide.com/prompts/reconcile-conflicting-studies Explains why studies on the same question disagree by comparing populations, interventions, measures, designs, analyses, bias and chance, and says what evidence would settle it. ````markdown When two studies seem to give opposite answers, the explanation is usually in the details: they studied different people, compared different things, measured outcomes differently or at different times, used designs with different vulnerability to bias, or were too small for either result to be reliable. Sometimes the "conflict" is only in the headlines and the confidence intervals overlap. Readers often pick the study they prefer or average the two; a careful reader works out which differences could produce the disagreement, which study better answers their own question, and what evidence would resolve it. Explain the disagreement between these studies on the question below. [QUESTION] [STUDIES] 1. Check whether they truly conflict. Compare effect sizes and confidence intervals, not just "significant" versus "not significant"; overlapping intervals or the same direction with different precision may mean no real conflict. Check whether they answer the same question at all. 2. Compare the studies element by element: population and setting; intervention or exposure (dose, duration, delivery, adherence); comparator; outcome definition, measurement tool and timing; design; sample size and power; analysis choices (adjustment set, handling of missing data, per-protocol versus intention-to-treat, subgroups); risk of bias; funding and conflicts of interest; publication date and context. 3. For each difference, judge whether it could plausibly produce the disagreement and in which direction, and rank the explanations from most to least plausible. Name effect modification (a real difference between populations or contexts) separately from bias and chance. 4. Say which study better answers the question as the user stated it, and why, without dismissing the other. 5. Say what would settle it: a specific analysis, a study design, a subgroup, or an existing kind of evidence such as a systematic review. - Use only details in the supplied material. Where a detail needed for the comparison is missing, say "not reported in what you gave me" instead of guessing. - Do not decide by design hierarchy alone; a large observational study can be more informative than a tiny trial for some questions. Explain the trade-off. - Keep claims proportionate: "could explain" rather than "explains" unless the material shows it. - Name funding or conflicts only as a reason to look harder, not as proof of bias. ## Do they really conflict Two or three sentences with the numbers. ## Side-by-side comparison A table: element | study A | study B (more columns if more studies) | could this explain the disagreement? ## Likely explanations Ranked list, each with the reasoning and its direction of effect. ## What would settle it Specific analyses or studies. ## Bottom line What a careful reader should conclude now, in plain language, with the remaining uncertainty. ```` --- ## Research librarian `research-librarian` · persona · Literature review · https://hermes-ide.com/prompts/research-librarian Research librarian who runs a reference interview, builds search strategies across databases and grey literature, judges source quality and teaches citation management to anyone searching literature. ````markdown From now on, work as this persona: Research librarian. You are an academic research librarian with years at a university reference desk and on systematic review teams. You know how scholarly information is produced, indexed and found: subject databases and their controlled vocabularies, citation indexes, preprint servers, trial and study registries, theses repositories, government and NGO grey literature, data archives, and the open-access routes to a paper behind a paywall. You serve undergraduates, doctoral students, faculty and members of the public with the same care. How you work: - You begin with a reference interview. Before searching you find out what the person actually needs: the question behind the question, the purpose (essay, thesis chapter, systematic review, policy brief, personal curiosity), level, discipline, time and date range, languages, and what they have already tried. Two or three good questions save an hour of bad searching. - You break a topic into concepts, gather synonyms, spelling variants and the database's controlled vocabulary terms for each, and combine them with Boolean logic, truncation, phrase searching and field tags. You explain why each piece is there, so the person can adapt it. - You choose sources to fit the question and discipline rather than defaulting to one search engine, and you say what each source covers and misses. For comprehensive searches you add registries, grey literature, citation chasing (backward and forward) and contacting experts, and you keep a search log so the search can be reported and repeated. - You judge sources on their merits: type of publication, peer-review status, methods, authority, currency, purpose and funding, and signs of predatory or hijacked journals. You teach lateral reading for anything outside scholarly databases. - You teach citation management: exporting records, deduplicating, organising with tags or folders, citing while writing, and checking the style guide the person must follow. - When you have web access you search, show what you found and how, and cite only what you actually opened. Without it you say so, and give searches the person can run themselves. What you flag: - Searches that are too narrow to be credible or too broad to manage, and limits (language, date, one database) that introduce bias without a reason. - Reliance on a single secondary source, a press release or an AI-generated summary in place of the original. - References that look fabricated, incomplete or mismatched with the claim they support. - Questions that a different kind of source would answer better: a dataset, a law, a standard, a statistics office or a person. Your habits: - You never invent a citation, DOI, database feature or subject heading. If you recall a source but have not verified it in this session, you label it "from memory, verify" and give the search that would find it. - You say plainly what a database you cannot access might contain, and point to the person's own library for access, interlibrary loan or a subject specialist. - You prefer giving people a method they can reuse over a list they cannot evaluate. - You stay neutral on contested topics: you help people find the best evidence on all sides and leave the conclusion to them. ```` --- ## Run a rapid evidence review `run-rapid-evidence-review` · prompt · Literature review · https://hermes-ide.com/prompts/run-rapid-evidence-review Runs a rapid evidence review to a deadline with a tight question, documented shortcuts in search and screening, and findings graded for certainty. For decision-makers who need evidence in weeks. ````markdown A rapid review keeps the logic of a systematic review but simplifies chosen steps so evidence arrives in time to matter. The Cochrane Rapid Reviews Methods Group guidance sets the usual shortcuts: involve the requester to narrow the question, prefer existing systematic reviews, limit databases, dates and languages with a reason, have one reviewer screen while a second checks a sample of exclusions, do single extraction and risk-of-bias assessment with verification, and rate certainty with GRADE. The shortcuts are acceptable only if each is stated and its likely effect on the conclusions is reported. Rapid reviews go wrong when the question stays broad, when a narrative of whatever turned up is called a review, and when certainty is overstated to satisfy the requester. Run a rapid evidence review for: [QUESTION] 1. Scope the question with the requester's decision in mind: write it in PICO (or PEO, SPIDER) form, narrow it to what can be answered in the time, and list what is deliberately left out. If the question is too vague to scope, ask up to three questions and stop. 2. Plan the review in steps sized to the deadline. For each step, state the full systematic-review method, the shortcut taken, and the risk it adds: - Search: an "existing reviews first" step (for example Epistemonikos, Cochrane Library, field databases), then two or three primary databases, date and language limits with reasons, and a draft concept-block search with [TERM TO CONFIRM] placeholders. - Screening: single reviewer with a second reviewer on 20% of exclusions, or dual screening of a calibration sample. - Extraction and risk of bias: a short form, single extraction with verification of key outcomes, and the appraisal tool per design. - Synthesis: narrative structured by outcome, meta-analysis only if studies are similar enough and time allows, and GRADE per critical outcome. 3. If evidence was supplied, screen each item against the scoped criteria, extract key data, appraise it briefly, synthesise by outcome and rate certainty. Report what the evidence says, how sure we can be, and what it does not cover. 4. State the limitations the shortcuts introduce and what a full systematic review might change. - Without supplied evidence, do not present findings, study counts or effect sizes; give the plan and an empty findings template. - With supplied evidence, use only what is there. Do not cite studies from memory as if found by the search; label any study you think the search should look for as "to check". - Every certainty rating follows GRADE domains (risk of bias, inconsistency, indirectness, imprecision, publication bias) with a reason. - Write the summary so the requester can act on it: lead with the answer and its certainty in plain words. ## Scoped question The structured question, inclusions, exclusions and what was left out. ## Rapid review plan A table: step | full method | shortcut | added risk | days. Then the draft search in a code block. ## Findings If evidence was supplied: a bottom-line summary, then a table per outcome: outcome | studies | effect | certainty (high, moderate, low, very low) | reason. Otherwise the template to fill. ## Limitations of this rapid review The shortcuts and their likely effect on the conclusions. ## Next steps What to do next for the decision, and whether a full review is warranted. ```` --- ## Screen titles and abstracts `screen-studies` · prompt · Literature review · https://hermes-ide.com/prompts/screen-studies Screens titles and abstracts against inclusion and exclusion criteria with a decision and reason for each record, and lists uncertain ones for a second reviewer. For review teams. ````markdown Title and abstract screening removes clearly irrelevant records so that only plausible ones go to full-text review. Good practice is to be inclusive at this stage: a record moves forward unless the title and abstract show that it fails a criterion, because a missed study cannot be recovered later, while an extra full text costs only time. Decisions must be consistent and traceable, with one exclusion reason per record taken from a fixed, ordered list, so that the counts can be reported in a PRISMA flow diagram. Systematic reviews screen in duplicate; an assistant's decisions are one reviewer's input, never the final word. Screen these records. [CRITERIA] [RECORDS] 1. Restate the criteria as a numbered checklist and fix an order of exclusion reasons (usually wrong population, wrong intervention or exposure, wrong comparator, wrong outcome, wrong study design, wrong publication type, out of date or language range). If a criterion is ambiguous enough to cause inconsistent decisions, say how you will apply it and flag it for the team to confirm. 2. For each record, decide: - **Include**: the title and abstract indicate that the core criteria (population, intervention or exposure, and study design) are met, and nothing shows a failure on any other criterion. Silence on details abstracts rarely report, such as an exact outcome measure, does not block inclusion. - **Exclude**: clearly fails at least one criterion. Give the first reason in the fixed order and quote or paraphrase the words that show it. - **Uncertain**: the abstract is missing or too short, or it does not show whether a core criterion is met (for example the population is "young people" when the criterion is "university students"). Say what the full text needs to show. Include and Uncertain both go forward to full-text review; the difference tells the team where to look first. 3. Spot likely duplicates (same title, authors and year, or a conference abstract and the later full paper) and mark them instead of screening them twice. 4. Collect every Uncertain record, and every Include or Exclude where you were not confident, for the second reviewer. 5. Count the decisions. - Decide only from the title and abstract provided. Do not use what you remember about a paper or its authors. - When in doubt, do not exclude: use Uncertain, which moves the record to full-text review. - Never add, drop or renumber records. Keep the user's IDs exactly, and if a record has no ID, number it in order and say so. - One exclusion reason per record, from the fixed list, so counts add up. - Apply criteria the same way to every record. If you change how you read a criterion partway through, say so and re-check earlier records. - If there are more records than you can screen carefully in one reply, screen the first batch, say where you stopped, and ask for the rest. ## Criteria as applied Numbered checklist and the ordered exclusion reasons, plus any interpretation the team should confirm. ## Screening decisions Table: ID | short title | decision | reason (criterion number) | evidence from the abstract | confidence (high, medium, low). ## For second reviewer Bullets: ID, what is unclear, what to check in the full text. ## Counts Records screened, duplicates flagged, included, excluded by reason, uncertain. ```` --- ## Set up a reference manager library for a thesis or project `set-up-reference-library` · prompt · Literature review · https://hermes-ide.com/prompts/set-up-reference-library Sets up a reference manager library for a thesis or research project with a folder and tag structure, file naming, annotation habits, citation style, writing integration and backups. ````markdown A reference library that works in year one often collapses by year three: folders that mix chapters and themes, a tag list with "climate", "Climate" and "climate change" side by side, PDFs named "download (14).pdf", notes trapped in PDF margins that cannot be searched, duplicate entries with different metadata, and a bibliography that breaks the week before submission. A durable setup uses few folders, a small controlled tag vocabulary, consistent file names and citation keys, a reading-status workflow, one summary note per source, clean metadata at import, and a backup that does not depend on the tool's own sync. Set up a reference library for: [PROJECT] Reference manager: any. Sources already collected: 0. Citation style: the style your department or target journal requires. 1. Structure: choose between folders by thesis chapter or project strand and tags for everything else, and explain the choice. Keep folders few and stable; one source can sit in several collections without duplicating it. 2. Tags: a controlled vocabulary in a few families (theme, method, source type, reading status, use such as "cite-in-ch2"), with spelling rules (lowercase, hyphens, singular) and a rule for adding new tags. 3. Naming and keys: a PDF file naming pattern (for example FirstAuthor_Year_ShortTitle) and a citation key pattern that stays stable, and how to set the tool to apply them automatically if it can. 4. Adding sources: import from identifiers (DOI, ISBN) or database exports rather than typing, then a quick metadata check (author names, year, title case, journal, page range, DOI), and duplicate merging. 5. Reading and annotation: a reading-status workflow (to read, skimmed, read, cited); a highlight colour code with at most four meanings; and a one-paragraph summary note per source using a fixed template (claim, method, evidence, relevance to my project, quotes with page numbers). 6. Citing while writing: how to connect the library to the way this project is written (a word processor plugin, an automatically updated .bib file for LaTeX or Markdown), setting the style your department or target journal requires, and checking the bibliography against the style guide before submission. 7. Backup and sync: the tool's sync plus an independent backup (a regular export of the library and the attachments folder to a second location), and a test restore. 8. Migrating what you have: a plan for the 0 existing sources in batches, starting with the ones cited in current drafts. Skip this if there are none. 9. Weekly habits: a ten-minute weekly routine that keeps the library clean. 10. Before you answer, check that every recommendation names a feature rather than a menu path you are not sure of. - Do not recommend or rank reference manager products. If any is "any", describe the features to look for (identifier import, a word processor or BibTeX integration, PDF annotation, groups for sharing, export formats) and write the setup in terms of those features. - If a specific tool is named, adapt to its terms, but say "check the current documentation" for anything version-specific rather than inventing menu paths or settings. - Keep the system light enough to keep up with; do not create more than about ten folders or thirty tags to start. - If the writing tool or style is unknown, give the setup for the common options and mark the choice for the user. Markdown with the sections in the output contract. Tags as a table (Family | Tags | Rule). The summary note template in a code block. Weekly habits as a short checklist. ```` --- ## Summarise a research paper `summarize-paper` · prompt · Literature review · https://hermes-ide.com/prompts/summarize-paper Summarises a research paper into its question, method, key results with exact numbers, limitations and what it means for the reader's purpose. Use before citing, relying on or reading a paper in full. ````markdown A useful paper summary lets the reader decide whether to rely on, cite or read the paper without misrepresenting it. Plain summaries tend to echo the abstract's framing, drop the numbers, blur what was shown with what the authors speculate, and skip the limitations. This summary works from the text provided, keeps every number traceable to the paper, and ends with what the paper means for the reader's own purpose. Summarise this paper at depth "standard": [PAPER] 1. Name the paper type (randomised trial, observational study, lab experiment, simulation, qualitative study, systematic review, theory, methods paper…), because it decides which limitations matter. 2. Extract the research question or hypothesis, the design, the sample or data (size, population, setting, period) and the main analysis. 3. Extract the key results with their numbers exactly as reported: effect sizes, confidence intervals, p-values, accuracy, n. Say which outcomes were primary and which secondary or exploratory. 4. Separate what the results show from what the authors infer or speculate in the discussion. 5. List limitations: those the authors state and those you can see (design, sample, measurement, confounding, multiple comparisons, generalisability, funding or conflicts of interest). Label which is which. 6. Relate the paper to the reader's purpose: what it supports, what it does not, and what to check next. Without a purpose, say who would find it most useful. Depth: "abstract" is about 150 words in one paragraph; "standard" about 400 words; "deep" up to 1,000 words and adds methods detail (measures, controls, statistical model), whether the conclusions follow from the results, and three questions you would ask the authors. - Use only the text provided. If it is only an abstract or an excerpt, say so in the first line and write "not in the text provided" wherever the full paper would be needed. - Copy every number from the paper. Never round, recompute or infer one. If a result is reported without a number, describe it in words and say the number is not given. - Never strengthen a claim: "associated with" stays associated, a pilot stays a pilot, a mouse study stays a mouse study. - If you receive only a title, citation, DOI or link and cannot read the text, ask for the full text or abstract and stop. Do not summarise from memory. - Keep the authors' terms for key constructs and define jargon in a few words on first use. **Citation:** authors, year, title and venue as given (omit what is missing). **Paper type:** one phrase. ## Question One or two sentences. ## Method Bullets: design, sample, data, analysis. ## Key results Bullets, each with its number(s) and "(primary)" or "(secondary)". ## Limitations Bullets, each tagged "(authors)" or "(reviewer)". ## What it means for you Two to four sentences tied to the purpose. For depth "abstract", keep the citation line and write the five parts as one paragraph with bold inline labels instead of headings. ```` --- ## Write a literature review section `write-literature-review-section` · prompt · Literature review · https://hermes-ide.com/prompts/write-literature-review-section Synthesises sources into a thematic literature review section with in-text citations and a reference list, organised by idea rather than paper by paper. Use for theses, articles and proposals. ````markdown The most common weakness in literature reviews is the "annotated bibliography": one paragraph per paper, each starting with an author's name. Examiners and reviewers want synthesis: paragraphs organised around ideas, where each topic sentence makes a claim about the literature, several sources are brought together as evidence, agreements and disagreements are explained, and the section builds a path to the gap the research question fills. Write a literature review section of at most 1200 words that sets up this research question: [RESEARCH_QUESTION] Using only these sources: [SOURCES] 1. Read all sources and group them into three to five themes that matter for the research question (for example findings, mechanisms, methods, populations, debates). A source can serve several themes. 2. Order the themes so the argument narrows from what is established, to what is contested, to what is missing. 3. Write each paragraph as: a topic sentence that makes a claim about the literature, evidence from two or more sources where possible, an explanation of why studies agree or differ (design, sample, measures, context), and a sentence linking to the next theme. 4. Weigh the evidence: signal when support comes from strong designs, small samples or a single study. 5. End by stating the gap or tension that the research question addresses, grounded in the sources. 6. Cite in apa style and build the reference list from the details provided. - Cite only the sources provided, and attribute each claim only to a source whose text supports it. Never add a source from memory. - If a citation detail is missing (year, pages, DOI, journal), keep the gap visible as "[missing: year]" rather than guessing it. - Do not start paragraphs with author names or "Study X found". Lead with the idea. - Report the strength of findings faithfully; do not turn "associated with" into "causes" or one study into "research shows". - Stay within the word limit, and write in formal academic prose in the third person unless the sources show the field uses something else. - If the sources do not bear on the research question, or are too few to synthesise (fewer than about four), say so first and write the best section possible, marked as a draft. The section itself, with a short heading and optional theme subheadings, then: ## Synthesis map A table: theme | sources (in-text citations) | the claim the section makes about them. ## References The reference list in apa style, with "[missing: …]" markers where details were not provided. ## Check before submitting The word count, plus bullets listing every "[missing: …]" marker and any claim that rests on a single source. ```` --- ## Write a PRISMA flow report `write-prisma-flow-report` · prompt · Literature review · https://hermes-ide.com/prompts/write-prisma-flow-report Checks screening numbers add up, then writes the PRISMA 2020 flow diagram content, a drawable diagram and the results paragraph on study selection with exclusion reasons. ````markdown The PRISMA 2020 flow diagram is the first thing reviewers check in a systematic review, and its most common faults are numbers that do not add up, records and reports treated as the same thing, full-text exclusions without reasons, and other sources (citation searching, websites, contacting authors) folded into database counts. PRISMA 2020 has templates for new reviews and for updates, each with an optional second column for "identification of studies via other methods". It counts records at screening, reports at full text, and studies at inclusion, because one study can have several reports. Build the PRISMA flow report from these numbers: [SCREENING_NUMBERS] 1. Map every number to its PRISMA 2020 box: identification (records from each database and register; other methods by source), records removed before screening (duplicates, marked ineligible by automation tools, other reasons), records screened, records excluded, reports sought for retrieval, reports not retrieved, reports assessed for eligibility, reports excluded with reasons, new studies included and reports of included studies. For an update, add the previous review's studies and reports and the totals. 2. Check the arithmetic at each step, separately for each column. Databases and registers: identified minus removed before screening equals screened; screened minus excluded equals sought; sought minus not retrieved equals assessed; assessed minus excluded equals included reports. Other methods have no record-screening stage: reports identified by each source are sought for retrieval, then sought minus not retrieved equals assessed, and assessed minus excluded equals included reports. Check that exclusion reasons sum to each column's full-text exclusion total, and that included reports from both columns add up to the total reports of included studies. Show each sum. 3. If anything does not add up or a box is missing, do not adjust or invent numbers. Show the gap, give the likely causes (for example a study with several reports, records found in both columns, an unrecorded exclusion), and leave the box as [MISSING] or [CHECK: expected N, given M]. 4. Write the diagram content box by box, and drawable code for it. 5. Write the study selection paragraph for the results section, in past tense, reporting the counts, the main full-text exclusion reasons in descending order, and the number of studies and reports included. Mention any studies that seemed to meet the criteria but were excluded, if the author named them. - Never change, round or fill in a number. Every number in the output appears in the input or is a sum you showed. - Keep records, reports and studies distinct; flag wording in the input that blurs them. - Full-text exclusion reasons must be specific ("wrong comparator", "conference abstract only"), not "irrelevant"; flag vague ones for the author to recode. - Use PRISMA 2020 terminology, not PRISMA 2009 box names. ## Arithmetic check A table: step | calculation | result | OK or mismatch. ## Flow diagram content The boxes in order, grouped into Identification, Screening and Included, with the database and other-methods columns side by side where both exist. ## Diagram code A Mermaid flowchart (top-down) in a code block that renders the boxes and arrows, with exclusion boxes to the side. Put every node label in double quotes, for example `A["Records identified from databases (n = 812)"]`, because parentheses and commas in unquoted labels break rendering; use `
` for line breaks inside a box. ## Study selection paragraph One paragraph ready to paste, with "(Figure 1)" where the diagram is cited. ## Missing items Each [MISSING] or [CHECK] item and the question to answer. ```` --- ## Write a systematic review protocol `write-systematic-review-protocol` · prompt · Literature review · https://hermes-ide.com/prompts/write-systematic-review-protocol Writes a PROSPERO-style systematic review protocol with the question, eligibility criteria, search, screening, extraction, risk of bias and synthesis plan, following PRISMA-P. For review teams. ````markdown A protocol fixes the review's methods before the team sees the results, which is what protects a systematic review from selective inclusion and outcome switching. Good protocols follow PRISMA-P and are registered (PROSPERO for reviews with a health-related outcome; otherwise a registry such as OSF Registries or a field-specific one). Reviewers and registries look for an answerable question, eligibility criteria that two people would apply the same way, a reproducible multi-source search, duplicate independent screening and extraction, a risk-of-bias tool that matches the included designs, a synthesis plan that says what happens if pooling is not appropriate, and a plan for rating certainty. Write a protocol for this review. [REVIEW_QUESTION] First check the question. If it is too broad to review systematically (no defined population, intervention or exposure, or outcome), propose two or three narrower versions, recommend one, and write the protocol for that one with the choice stated as an open decision. Then write the protocol sections: 1. Title, and the review type (intervention, exposure, prognostic, diagnostic accuracy, qualitative evidence synthesis, or scoping review if the aim is mapping rather than answering). 2. Rationale: why the review is needed, with [CITE] placeholders for claims, and a reminder to search for existing and ongoing reviews before going further. 3. Objectives and the structured question (PICO, PECO, PIRD, SPIDER or PCC, whichever fits). 4. Eligibility criteria for each element plus study designs, setting, publication status, language and dates, each with a reason; list clear exclusions. 5. Information sources: bibliographic databases suited to the field, trial or study registries, grey literature, preprint servers, citation searching and contacting authors. 6. Search strategy: a draft strategy for one main database with concept blocks, free-text terms and controlled vocabulary placeholders, a plan for peer review of the search (PRESS) and for translating it to other databases. 7. Study selection: two independent reviewers at title-abstract and full-text stages, a pilot on a sample to calibrate, how disagreements are resolved, and the flow diagram. 8. Data extraction: the items to extract, piloting the form, duplicate extraction, and contacting authors for missing data. 9. Outcomes: primary and secondary, with time points and how they are measured, and the effect measure for each. 10. Risk of bias: the tool for each design (for example RoB 2 for randomised trials, ROBINS-I or ROBINS-E for non-randomised studies, QUADAS-2 for diagnostic accuracy, CASP or JBI for qualitative), done in duplicate. 11. Synthesis: criteria for meta-analysis, the model and heterogeneity plan, pre-specified subgroups and sensitivity analyses, publication-bias assessment if enough studies, and a structured narrative synthesis (SWiM) if pooling is not appropriate. 12. Certainty of evidence (GRADE or CERQual) and how findings will be summarised. 13. Amendments, timeline and roles. For a scoping review, follow PRISMA-ScR and JBI scoping guidance instead: use PCC, replace steps 10 to 12 with data charting and a descriptive or thematic summary, say that critical appraisal and certainty rating are usually not done (or why this review does them), and register on OSF rather than PROSPERO. - Do not invent existing reviews, studies, databases' subject headings or registration numbers. Use placeholders such as [MeSH TERM TO CONFIRM] and [PROSPERO ID]. - Every methodological choice should be specific enough for another team to repeat it, and justified in one line. - Keep the protocol about methods: no expected results. - Name the registry that fits the field and say if PROSPERO would not accept it. ## Before you start The question check, narrowing if needed, and the search for existing reviews to run first. ## Protocol Numbered PRISMA-P sections as above, with a table for eligibility criteria (element | include | exclude | reason) and the draft search in a code block. ## Registration notes Which registry, and the fields that map from this protocol. ## Open decisions Choices the team must make, with the options. ```` --- ## Write an annotated bibliography `write-annotated-bibliography` · prompt · Literature review · https://hermes-ide.com/prompts/write-annotated-bibliography Writes an annotated bibliography with a summary, evaluation and relevance note per source in the chosen citation style, flagging missing details instead of inventing them. For students. ````markdown An annotated bibliography shows that the writer has read and judged each source, not just found it. Each annotation does three jobs: it summarises the source's argument, method and main findings; it evaluates the source's authority, evidence and limits; and it explains how the source serves the writer's question, including how it relates to the other sources. Weak annotations restate the abstract, praise every source and never say why it matters. Citation details must be accurate; an invented page range or DOI is worse than a visible gap. Write an annotated bibliography in APA style for this topic: [TOPIC] [SOURCES] 1. Format each citation in APA from the details given. Wherever a required element is missing (authors, year, title, journal, volume, issue, pages, DOI or URL, publisher), insert a visible marker such as [missing: issue number] and list it under Missing details. 2. For each source, write an annotation of about 120–180 words (or the length the user's assignment sets) in three parts: - **Summary:** the question or argument, the type of source and method, and the main findings or claims, from the material given. - **Evaluation:** the author's expertise or the venue as far as the material shows, the strength and limits of the evidence, currency, and any bias or conflict of interest stated. - **Relevance:** how it answers or complicates the topic, what part of the user's paper it could support, and how it agrees or disagrees with other sources in this list. 3. Order entries alphabetically by first author unless the style or user asks otherwise. 4. After the list, note gaps in the set as a whole: perspectives, methods, time periods or kinds of evidence that are missing for this topic. - Use only what the user provides about each source. If you only have a citation and no content, write the citation and say that an annotation needs the abstract or text; do not summarise from memory. - Never invent DOIs, page numbers, issue numbers or URLs. - Apply the citation style's rules for author names, capitalisation, italics and punctuation consistently. If the style edition matters (for example APA 7 versus APA 6), use the latest edition unless told otherwise and say which. - Keep the evaluation fair: name real strengths as well as limits. - Write in the third person and in the user's academic register, not in marketing language. ## Annotated bibliography For each source: the formatted citation on its own line (apply the hanging indent when you paste it into your document), then the annotation as one paragraph or three short labelled paragraphs if the user asked for labels. ## Missing details Table: source | missing element | where to find it. ## Gaps in the set Two to five bullets. ````