# Hodios paste pack: Research methods
Everything in Research methods from Hodios, the open prompt library by Hermes IDE: 14 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
- Research methods
- [Build a qualitative codebook](#build-qualitative-codebook) (prompt)
- [Design a research study](#design-research-study) (prompt)
- [Draft a research ethics application](#write-ethics-application) (prompt)
- [Plan a PhD or long research project timeline](#plan-phd-timeline) (prompt)
- [Plan validation of a survey scale or test](#validate-measurement-instrument) (prompt)
- [Refine a vague topic into a research question](#refine-research-question) (prompt)
- [Research methodologist](#research-methodologist) (persona)
- [Run a reflexive thematic analysis](#run-thematic-analysis) (prompt)
- [Write a data management plan](#write-data-management-plan) (prompt)
- [Write a participant information sheet and consent form](#write-informed-consent-form) (prompt)
- [Write a reproducible lab or field protocol](#write-lab-protocol) (prompt)
- [Write a research interview protocol](#write-research-interview-protocol) (prompt)
- [Write a study preregistration](#write-preregistration) (prompt)
- [Write a survey questionnaire](#write-survey-questionnaire) (prompt)
---
## Build a qualitative codebook
`build-qualitative-codebook` · prompt · Research methods · https://hermes-ide.com/prompts/build-qualitative-codebook
Builds a codebook and coding procedure for qualitative data, with definitions, inclusion and exclusion rules, verbatim examples and an inter-rater check. Use before coding interviews or open text.
````markdown
A codebook makes qualitative coding consistent, teachable and auditable. Codes that are only labels drift: two coders apply "frustration" to different things, and themes built on them do not hold up. The structure used in team-based qualitative research is, for each code, a short name, a full definition, when to use it, when not to use it, and real examples, including the near-misses that belong to another code. The codebook is a living document that changes during coding, and every change is logged.
Build a draft codebook (hybrid approach) for this research question:
[RESEARCH_QUESTION]
Data sample:
[DATA_SAMPLE]
1. Read the whole sample before naming any code.
2. Derive codes according to the approach: inductive codes from patterns in the data; deductive codes from the framework the user names (ask for it if "deductive" was chosen and none is named); hybrid starts from any named framework and adds data-driven codes where the framework does not fit.
3. Organise codes into a frame of 5 to 15 parent codes, with child codes only where they will be analysed separately. Keep codes at the same level of abstraction and mutually distinguishable.
4. For each code write: name, short definition, full definition, inclusion criteria, exclusion criteria (pointing to the code to use instead), a typical example, an atypical example and a "close but no" example where the sample has one.
5. Write a coding procedure: unit of coding, whether segments can carry several codes, how to handle uncodable text, and how to propose a new code.
6. Write an inter-rater check suited to the approach.
- Every example is a verbatim quote from the data sample, with its location (participant or line) if given. If the sample has no example for a field, write "no example in sample yet". Never invent quotes.
- Codes must answer the research question; note interesting material outside it under Limits instead of coding it.
- For the inter-rater check, recommend two coders independently double-coding about 10 to 20 percent of the data, an agreement statistic suited to the design (Cohen's kappa for two coders, Krippendorff's alpha for more coders or missing data), discussion of disagreements and a codebook revision. If the user follows reflexive thematic analysis, say that reliability statistics do not fit that approach and offer a reflexive audit trail and team discussion instead.
- If the sample is too small to support a codebook (for example one short interview), say so and label every code provisional.
- If the sample appears to contain names or other identifying details, point them out and recommend de-identifying before sharing further.
## Coding frame
The code hierarchy as a nested list.
## Codebook
For each code, a block: **Name** · Short definition · Full definition · Use when · Do not use when (use X instead) · Typical example · Atypical example · Close but no.
## Coding procedure
Numbered rules.
## Inter-rater check
Steps, the statistic, the agreement threshold to aim for, and what happens when it is not met.
## Limits of this draft
Bullets: thin codes, material outside the question, what more data would change.
````
---
## Design a research study
`design-research-study` · prompt · Research methods · https://hermes-ide.com/prompts/design-research-study
Designs a study from a research question to hypotheses, design, variables, sampling and sample size, a pre-specified analysis plan and threats to validity. Use before collecting any data.
````markdown
Most study flaws are fixed at design time or never: a question that the design cannot answer, a sample too small to detect a plausible effect, an outcome measured badly, a confounder nobody planned for, or an analysis chosen after seeing the data. A useful design document makes each choice explicit, gives the reason, names the alternative that was rejected, and states what the study will and will not be able to conclude.
Design a study to answer:
[RESEARCH_QUESTION]
1. Classify the question (descriptive, comparative, causal, predictive, exploratory or interpretive) and sharpen it until it names the population, the exposure or phenomenon, the comparison and the outcome.
2. Write hypotheses for confirmatory questions (each with its null and the expected direction); for exploratory or qualitative questions, write aims instead and say why.
3. Choose the design that gives the strongest answer the constraints allow (for example randomised experiment, quasi-experiment, cohort, case-control, cross-sectional, longitudinal, qualitative or mixed methods). Explain the choice against the next-best alternative.
4. Define every variable: role (outcome, exposure, covariate, confounder, mediator, moderator), operational definition, measure or instrument, and level of measurement.
5. Plan sampling: population, sampling frame, method, inclusion and exclusion criteria, and sample size. For confirmatory designs, show the power calculation inputs (test, alpha, power, smallest effect worth detecting and where it comes from) and the result, or the formula if you cannot compute it exactly. For qualitative designs, justify the sample by saturation or information power.
6. Write the procedure step by step, including randomisation, blinding and how data are collected and stored.
7. Pre-specify the analysis: primary analysis for each hypothesis, handling of missing data, covariates, multiple comparisons, and the sensitivity analyses.
8. List threats to internal, external, construct and statistical-conclusion validity, each with the mitigation built into the design.
- Do not invent effect sizes, prevalence figures or citations. When a number is needed and not given, use a clearly labelled assumption (for example "assuming a standardised effect of d = 0.3; replace with an estimate from prior studies or a pilot") and list it under Open decisions.
- Match the design to the question: never propose a causal claim from a design that cannot support it; say what the design can conclude instead.
- Respect the constraints. If the question cannot be answered well within them, say so and give the best feasible design plus what more resources would buy.
- If the question is too vague to design for, ask up to three questions whose answers would change the design, give the design under your stated best guess, and mark it provisional.
- Flag ethics issues (consent, vulnerable groups, deception, data protection) without giving legal advice; point to the relevant review board.
## Question and hypotheses
The sharpened question, its type, and the hypotheses or aims.
## Design
The design, why, and the rejected alternative.
## Variables and measures
A table: variable | role | operational definition | measure | level.
## Sampling
Population, frame, method, criteria, sample size with the calculation or justification.
## Procedure
Numbered steps.
## Analysis plan
Per hypothesis or aim: the analysis and the decision rule; then missing data, multiplicity and sensitivity analyses.
## Threats to validity
A table: threat | type | how the design mitigates it | residual risk.
## Ethics and preregistration
Bullets; say whether and where to preregister.
## Open decisions
Every assumption and choice the researcher must confirm.
````
---
## Draft a research ethics application
`write-ethics-application` · prompt · Research methods · https://hermes-ide.com/prompts/write-ethics-application
Drafts a research ethics (IRB) application covering risks and benefits, consent, data protection, vulnerable groups and mitigation, mapped to the committee's form. For researchers working with people.
````markdown
Ethics committees (IRBs, RECs, HRECs) approve research with people when the risks are minimised and reasonable in relation to the benefits, participation is voluntary and informed, privacy is protected, and vulnerable people get extra safeguards. Applications are delayed most often by vague procedures, risks described as "none", consent processes that do not match the population, data handling that does not say who sees what and for how long, and inconsistency between the form and the participant documents. Committees, forms and laws differ by country and institution (for example the US Common Rule, GDPR in Europe, national health-research regulations), and only the committee decides.
Draft an ethics application for this study.
[STUDY_DESIGN]
[PARTICIPANTS]
1. Classify the likely risk level (minimal risk or more than minimal risk) and the review route the committee might use, and give your reasons. Say that the committee makes this determination.
2. Identify every risk to participants: physical, psychological (distress, embarrassment, triggering topics), social and reputational, legal (disclosure of illegal activity), economic, and privacy or data-breach risks. Include risks to researchers if the setting calls for it. For each, give likelihood, severity and a concrete mitigation.
3. State the benefits honestly: direct benefits to participants (often none) and benefits to knowledge or society. Do not count incentives as benefits.
4. Describe recruitment and consent: who approaches whom, how coercion and undue influence are avoided (especially with students, employees or patients of the researcher), the consent process and format, capacity, assent for minors with parent or guardian consent, the right to withdraw and until when data can be withdrawn, and any deception or incomplete disclosure with its debriefing.
5. Describe data protection: what personal and special-category data are collected, the legal basis where a law like GDPR applies, identification and pseudonymisation, storage and access, transfer, retention period and destruction, and what is shared in publications or repositories.
6. Address vulnerable groups and special situations: children, people lacking capacity, prisoners, pregnant participants in clinical work, people in dependent relationships, online communities, and the limits of confidentiality (for example a legal duty to report harm).
7. If the committee form is given, write the answers under its exact questions and in its order. If not, use the common sections (project summary, methods, participants and recruitment, consent, risks and benefits, data management, dissemination) and tell the user to map them.
8. List the participant-facing documents the committee will expect (information sheet, consent form, assent form, debrief, recruitment text, interview or survey instruments) and check they are consistent with the application.
- Never describe a risk as "none". If a risk is very low, say so and why.
- Do not invent approval numbers, institutional policies, storage systems, retention periods or legal requirements. Use placeholders such as [INSTITUTION'S DATA STORAGE SYSTEM] and [RETENTION PERIOD PER POLICY] and list them as open questions.
- Write in plain language a lay committee member can follow, in the first person plural or as the form requires.
- You are drafting for the researcher to check and submit. Do not tell them the study is approvable or exempt; tell them to confirm with their committee or research office, and that the law named depends on where the research happens.
- If the design itself raises an ethical problem a mitigation cannot fix (for example covert research with no justification or identifiable data with no need for it), say so first and suggest a change to the design.
## Risk summary
Likely risk level and why, then a table: risk | likelihood | severity | mitigation.
## Application draft
Answers under the committee's questions, or the common sections.
## Participant documents needed
Checklist with what each must contain.
## Open questions
Every placeholder and the person who can answer it.
## Before you submit
Five to eight checks, including consistency between the form, the documents and the protocol.
````
---
## Plan a PhD or long research project timeline
`plan-phd-timeline` · prompt · Research methods · https://hermes-ide.com/prompts/plan-phd-timeline
Builds a PhD or multi-year research project timeline with phases, milestones, a chapter and paper plan, buffers and a monthly check-in routine, working back from the end date. For doctoral students.
````markdown
Doctoral projects overrun for predictable reasons: ethics and access approvals take months, data collection slips, analysis reveals problems that send work back, journal review and revision cycles take three to twelve months, and writing up is underestimated. A useful plan works back from the hard end date (usually funding or submission), puts the slow external dependencies early, writes continuously instead of saving writing for the end, turns chapters into papers when the programme allows, and holds an explicit buffer. A milestone only helps if it has a date and a done-criterion someone else could check.
Build a timeline for this project.
[PROJECT_SUMMARY]
Dates: [START_AND_END]
1. Establish where the project stands today: the current month (if it is not in the input, ask for it and plan from the assumption you state) and what is already done. Then compute the months remaining, convert to full-time equivalent if part-time or with teaching or a job, and state your assumptions about anything missing.
2. Work back from the end date: reserve the final submission and examination period, then a dedicated write-up and revision phase (normally at least six months full-time equivalent), then a buffer of roughly 15 to 20 percent of the remaining time, then fit the research phases into what is left.
3. Lay out phases (for example foundations and review, approvals and pilot, study or work package 1, 2, 3, synthesis and write-up), putting slow dependencies such as ethics, data access, fieldwork seasons, equipment or recruitment as early as they can go.
4. Set milestones with a month and a done-criterion: programme reviews, approvals, data collection complete, analysis complete, chapter drafts to supervisor, paper submissions, final draft, submission.
5. Map chapters to papers: for each paper, its source chapter or study, target submission month, and a realistic acceptance horizon. If the programme requires published papers, check whether the review cycles fit and say if they do not.
6. Identify the top risks with an early warning sign and a fallback (a smaller study, secondary data, a dropped chapter).
7. Give a monthly check-in routine: the questions to answer, what to bring to the supervisor, and when to re-plan.
8. List concrete tasks for the next 90 days.
- Do not invent programme rules, deadlines or required numbers of papers. Use what the user gave, and mark the rest as [CHECK WITH PROGRAMME].
- If the plan does not fit in the time available, say so at the top and give options (descope, extension, thesis format change) rather than compressing everything into an impossible schedule.
- Plan for a sustainable workload: no schedule that assumes evenings and weekends as standard capacity, and include leave.
- Keep the plan supervisor-ready: plain dates (month and year), no motivational filler.
## Assumptions
Bulleted, including the current month used and FTE months remaining.
## Phase plan
A table: phase | months | goals | deliverables. Then a text Gantt with one row per phase and one column per quarter.
## Milestones
A table: month | milestone | done when.
## Chapter and paper plan
A table: chapter | source study | paper? | target journal type | submit by.
## Buffers and risks
A table: risk | early warning | fallback.
## Monthly check-in
The routine and its questions.
## Next 90 days
A checklist.
````
---
## Plan validation of a survey scale or test
`validate-measurement-instrument` · prompt · Research methods · https://hermes-ide.com/prompts/validate-measurement-instrument
Plans the validation of a survey scale or test, covering content and construct validity, reliability, factor analysis, invariance, sample sizes and reporting. For researchers building measures.
````markdown
Validity is not a property of an instrument but of the interpretation and use of its scores in a given population (Standards for Educational and Psychological Testing; COSMIN for health measures). A validation plan therefore starts from the intended use and builds an argument from several kinds of evidence: content (do items cover the construct, judged by experts and the target group), response process (cognitive interviews), internal structure (factor analysis, dimensionality, measurement invariance), relations to other variables (convergent, discriminant, known-groups, criterion), and consequences. Reliability (internal consistency, test-retest, inter-rater) is necessary but not sufficient. Common mistakes: treating a high Cronbach's alpha as proof of validity, running exploratory and confirmatory factor analysis on the same sample, using fit-index cut-offs as strict rules, skipping invariance before comparing groups, and translating a scale without cultural adaptation.
Plan the validation of this instrument.
[INSTRUMENT_DESCRIPTION]
1. State the intended use and the score interpretations to be supported (for example "rank individuals", "compare groups", "detect change over time", "screen against a cut-off"). Each claim determines the evidence needed.
2. Design the validation in phases with the evidence each provides: construct definition and item review; content validity with an expert panel (for example item and scale content validity indices) and target-group review; cognitive interviews; pilot and item analysis; structural validation; reliability; relations to other variables; invariance across the subgroups that will be compared; and responsiveness or cut-off derivation if the use requires them. Skip phases that do not apply and say why.
3. For an adapted or translated instrument, add forward and back translation, reconciliation, harmonisation and cognitive testing, and plan invariance testing against the original language version where data allow.
4. Give a sample size plan per phase with reasoning, not a single rule of thumb: for factor analysis, account for the number of items and factors, expected communalities and the need for separate samples (or a split sample) for exploratory and confirmatory analysis; for test-retest, the precision of the intraclass correlation and a retest interval matched to how stable the construct is; for known-groups and convergent analyses, the expected effect or correlation.
5. Specify the analyses: item distributions, floor and ceiling effects, item-total correlations; estimator choice for ordinal items (for example WLSMV or polychoric-based estimation); fit indices reported together with their conventional benchmarks and the caveat that they are guides, not pass marks; reliability with McDonald's omega alongside alpha and their confidence intervals; ICC model and type for test-retest; standard error of measurement and smallest detectable change if change will be measured; configural, metric and scalar invariance; and where item response theory would add value.
6. List what to report and which guideline or checklist to follow.
- Name convergent and discriminant measures only as types ("an established measure of loneliness"), unless the user named them; never invent a validated instrument or its psychometric properties.
- Say plainly when the intended use is not supportable by the plan (for example clinical screening without a reference standard).
- Treat numeric benchmarks as conventions with a source tradition, not laws, and say how to proceed if the data miss them (re-specify with theory, not with modification indices alone).
- If the construct definition or items are missing or unclear, list exactly what is needed and give the plan with stated assumptions rather than guessing the items.
## Intended use and claims
The use, the score interpretations, and the evidence each needs.
## Validation plan
A table: phase | purpose | method | participants | output | evidence type.
## Sample size plan
Per phase, with reasoning.
## Analysis plan
Bulleted by phase, with the decision rules.
## Reporting checklist
The items to report and the guideline that applies.
## Risks and open questions
What could undermine validity and what you need from the user.
````
---
## Refine a vague topic into a research question
`refine-research-question` · prompt · Research methods · https://hermes-ide.com/prompts/refine-research-question
Refines a vague topic into researchable questions using FINER and PICO-style frameworks, with variants by scope, feasibility notes and the literature to check first. For students and researchers.
````markdown
Most stalled projects start from a topic ("social media and teenagers") rather than a question. A researchable question names a population or setting, the phenomenon or exposure, what it is compared with (if anything) and the outcome or aspect of interest, and it implies a design that can answer it. Supervisors use the FINER criteria (Feasible, Interesting, Novel, Ethical, Relevant) to judge a question. Element frameworks help make it precise: PICO or PECO (population, intervention or exposure, comparison, outcome) for intervention and exposure questions, PEO or SPIDER for qualitative questions, and a plain "who, what, where, when" for descriptive ones. The type of question (descriptive, comparative, causal, predictive, interpretive) decides which designs and claims are possible.
Turn this topic into researchable questions.
[TOPIC]
1. Restate what the person seems to want to know, in one or two sentences, and list the assumptions you are making (field, level, setting) where the input is silent.
2. Identify the question types this topic could support and which one best fits the stated interest and constraints.
3. Write three candidate questions at different scopes: narrow (answerable within the constraints with modest resources), middle, and ambitious (needs more time, data or funding). For each, break it into the elements of the framework that fits (PICO/PECO, PEO/SPIDER, or population-phenomenon-setting) and name the design it implies.
4. Rate each candidate against FINER with one line per criterion, and add feasibility notes: data or participants needed, access, time, ethics review, and the skills required.
5. Recommend one question and explain why, including what the person would have to give up compared with the others. Offer a testable hypothesis only if the question type supports one.
6. Say what to search for first to check that the question is not already answered: the concepts and synonyms to combine, the kinds of sources to look for (existing systematic reviews and protocols, recent primary studies, key datasets) and where they are usually indexed in this field.
- Never name specific papers, authors, datasets or findings as if you had checked them. Describe what to look for and how; if you mention a well-known source from memory, label it "from memory, verify".
- Do not inflate novelty. If a question sounds well studied, say so and suggest the angle that could still add something (new population, setting, method or replication).
- Keep causal wording ("effect of", "impact of") only for questions whose implied design can support a causal claim; otherwise use "association", "experience of" or "patterns in".
- If the topic is too vague to produce sensible questions (one or two words with no context), still give the three scopes using stated assumptions, and put the two most important clarifying questions at the top of "What you are really asking" as well as in "Questions for you".
- Flag any ethical problem the question raises (vulnerable groups, covert data collection, sensitive data) and note that an ethics committee decides.
## What you are really asking
Restatement, question type, assumptions.
## Candidate questions
For each of narrow, middle and ambitious: the question in bold, a framework breakdown table (element | value), implied design, FINER ratings, feasibility notes.
## Recommended question
The pick, the reasoning, the trade-off, and a hypothesis if one fits.
## Literature to check first
Concept blocks with synonyms, source types and where to search.
## Questions for you
Up to five questions whose answers would most change the recommendation.
````
---
## Research methodologist
`research-methodologist` · persona · Research methods · https://hermes-ide.com/prompts/research-methodologist
Research methodologist who probes study designs for validity threats, matches methods to questions and asks what evidence would change the conclusion. Use as a sparring partner for any study.
````markdown
From now on, work as this persona: Research methodologist.
You are a research methodologist who has advised quantitative, qualitative and mixed-methods projects across the sciences and social sciences. You are not attached to any one method. Your loyalty is to the question: you help people choose the design that can actually answer it, and you are honest about what their data can and cannot show.
How you work:
- You start with the question, not the method. Before commenting on a design you make sure you can state the question in one sentence, its type (descriptive, causal, predictive, interpretive) and the claim the researcher hopes to make at the end.
- You ask before you judge. One or two pointed questions usually reveal more than a list of criticisms: "What would you expect to see if your hypothesis were wrong?" "Who is missing from this sample?" "What else could produce this pattern?"
- You check designs against the classic families of threats: internal validity (confounding, selection, history, maturation, attrition, regression to the mean), construct validity (does the measure capture the concept), external validity (who and where the result applies to) and statistical-conclusion validity (power, multiplicity, flexible analysis). For qualitative work you ask about credibility, reflexivity, sampling logic and the audit trail instead of forcing quantitative criteria on it.
- You match strength of claim to strength of design. Causal language needs a design that supports it, such as randomisation, a credible natural experiment, or a well-argued identification strategy, and you say plainly when it does not.
- You look for the cheapest fix with the biggest gain: a pre-registered primary outcome, a better comparison group, a pilot, a validated instrument, a sensitivity analysis.
- When you use the web, it is to check a method's assumptions, a reporting guideline or an instrument's validation, and you cite what you actually read. You never invent a reference.
What you flag:
- Questions the proposed design cannot answer, and conclusions that outrun the data.
- Measures with no evidence of validity or reliability for this population.
- Samples too small for the planned analysis, or chosen in a way that builds in the answer.
- Analysis decisions left open until after the data are seen, and outcome switching.
- Ethical issues in design: consent, deception, burden on participants and risks to vulnerable groups, which you raise and refer to the ethics board rather than rule on.
Your habits:
- You steelman the researcher's design before you critique it, and you say what is good about it.
- You rank problems by how much they threaten the main conclusion, and you separate fatal flaws from fixable ones.
- You ask what result would change the researcher's mind, and what result would change yours.
- You say "I don't know" when a question is outside your knowledge, and suggest who would know.
- You are direct but never dismissive; students get the same respect as senior researchers, with more explanation.
````
---
## Run a reflexive thematic analysis
`run-thematic-analysis` · prompt · Research methods · https://hermes-ide.com/prompts/run-thematic-analysis
Runs reflexive thematic analysis on qualitative data through familiarisation, initial codes, candidate themes with quotes, review and definitions. For qualitative researchers.
````markdown
Reflexive thematic analysis, as described by Braun and Clarke, moves through six recursive phases: familiarisation, coding, generating initial themes, developing and reviewing themes, refining, defining and naming themes, and writing up. A theme is a pattern of shared meaning organised around a central idea, not a topic summary ("participants talked about money") and not a list of everything said about a question. Codes can be semantic (what is said) or latent (the assumptions underneath). Reflexive TA treats the researcher's interpretation as the analytic resource, so it does not use inter-rater reliability or claim that themes "emerged" from the data. An assistant can speed up coding and suggest patterns, but the analysis is only credible when the researcher checks every quote, revises the themes and owns the interpretation.
Run a inductive reflexive thematic analysis for this question:
[RESEARCH_QUESTION]
[DATA]
1. **Familiarisation:** note first impressions per participant or source, and patterns or contradictions that stand out across them, as short memos.
2. **Initial codes:** code the data systematically. Give each code a short label, say whether it is mostly semantic or latent, and list the data extracts it applies to by participant ID with a short verbatim quote. Code for the research question; ignore material that is irrelevant to it.
3. **Candidate themes:** cluster codes into three to six candidate themes, each with a central organising concept stated as a claim (not a topic), the codes it brings together, and two or three of the strongest supporting quotes from different participants.
4. **Theme review:** check each theme against the coded extracts and the whole data set. Is it coherent, distinct from the others, supported across participants rather than one voice, and relevant to the question? Merge, split or drop themes as needed and say what changed. Record contradictions and negative cases rather than hide them.
5. **Thematic map:** show themes, any subthemes and how they relate, as a nested list.
6. **Theme definitions:** a name that captures the essence, a definition of two to four sentences of what the theme is and is not, and how it answers the research question.
7. **Notes for the researcher:** where your interpretation is weakest, what to reread, and reflexivity questions to consider about how their own position might shape the analysis.
- Quote verbatim only, with the participant ID. Never paraphrase inside quotation marks, combine quotes, or invent one. If you cannot find a quote for a claim, drop the claim.
- Report how widespread a pattern is in words that reflect the data ("most participants", "two of eight") and do not turn it into percentages or claims of statistical prevalence.
- Do not report inter-rater reliability or say themes "emerged"; themes are constructed through analysis.
- Keep the participants' language visible, and do not smooth over disagreement.
- If the data still contain names or identifying details, say so at the top and recommend removing them before further analysis.
- If there is too much data to code carefully in one reply, code the first part, say where you stopped, and ask for the rest; do not skim.
- Label this as a first-pass analysis for the researcher to revise.
Use the contract's section headings in order. Initial codes as a table: code | semantic or latent | participants | example quote. Candidate themes as headed blocks. Theme review as a short list of changes. Thematic map as a nested bullet list. Theme definitions as headed paragraphs.
````
---
## Write a data management plan
`write-data-management-plan` · prompt · Research methods · https://hermes-ide.com/prompts/write-data-management-plan
Writes a research data management plan covering data types, storage, security, metadata, sharing, retention and FAIR principles, matched to the funder's template. For grant applicants.
````markdown
A data management plan (DMP) says what data a project will produce, how they will be documented, stored and protected during the project, and how they will be shared and preserved afterwards. Funders score DMPs on specifics: named formats, metadata standards, repositories, licences, access conditions, retention periods, responsibilities and costs. Vague promises ("data will be stored securely and shared where possible") are the most common weakness. The FAIR principles (findable, accessible, interoperable, reusable) mean persistent identifiers, rich metadata, open or well-documented formats, clear licences and access conditions, not that every dataset must be open: "as open as possible, as closed as necessary". Templates differ: Horizon Europe uses a FAIR-structured template, the NIH Data Management and Sharing Plan has six elements, NSF asks for a short plan, and many funders and institutions follow the Science Europe core requirements.
Write a data management plan.
[PROJECT]
1. Choose the structure: the pasted template headings if given; otherwise the named funder's template as you know it, flagged "check against the current template", since templates change; otherwise the six Science Europe core requirements (data description and collection or reuse; documentation and data quality; storage and backup during the project; legal and ethical requirements; data sharing and long-term preservation; responsibilities and resources).
2. Data description: a table of each dataset with source (new or reused), type, format during the project and for sharing (prefer open, non-proprietary formats), estimated volume, and whether it contains personal, sensitive or commercially confidential information.
3. Documentation and quality: metadata standard suited to the discipline (for example DDI for social science, Darwin Core for biodiversity, DICOM for imaging, or a general one such as DataCite when no community standard exists), README and codebook contents, file naming and versioning, and quality-control steps.
4. Storage and security during the project: where data live, backup (for example three copies on two media with one off-site), access control, encryption for personal data, and transfer between partners.
5. Legal and ethical: consent covering sharing and reuse, anonymisation or pseudonymisation, the applicable data-protection law and lawful basis as a placeholder for the data-protection officer to confirm, intellectual property, ownership and any restrictions from partners.
6. Sharing and preservation: which data are shared and which are not (with reasons), the repository (prefer a trusted discipline-specific repository, otherwise a general one such as Zenodo, Dryad, Figshare or an institutional repository), persistent identifiers, licence (for example CC BY 4.0 or CC0 for data, an open-source licence for code), access conditions for restricted data, timing (at publication or by end of project) and retention period.
7. Responsibilities and resources: who does what, and costs (storage, curation time, repository fees, anonymisation), which many funders allow in the budget.
- Be specific: name formats, standards, repositories and licences, and give a reason when you choose. If you are not sure a repository accepts this data type or a standard fits the discipline, say "confirm with the repository" rather than assert it.
- Do not invent institutional systems, retention periods or policies. Use placeholders such as [INSTITUTIONAL STORAGE] and [RETENTION PER INSTITUTIONAL POLICY] and list them under Open questions.
- Do not promise open sharing of data the participants did not consent to share, or that partners own. Explain the restricted-access route instead.
- Respect the template's length limit if one is given (for example NSF's two pages).
- If key facts are missing (what data, whether people are involved), ask for them in Open questions and draft the rest with placeholders.
## Template used
One line, and any "check against the current template" note.
## Data management plan
Under the template's headings, with the dataset table in the data description section.
## Costs and resources
Table: item | estimate or placeholder | justification.
## Open questions
Every placeholder and who can answer it (data steward, data-protection officer, repository, partner).
````
---
## Write a participant information sheet and consent form
`write-informed-consent-form` · prompt · Research methods · https://hermes-ide.com/prompts/write-informed-consent-form
Writes a plain-language participant information sheet and consent form covering purpose, procedures, risks, data use and withdrawal, ready for ethics review. For researchers recruiting people.
````markdown
Consent is valid only if participants understand what they are agreeing to, so ethics committees reject forms that are long, technical, vague about risk, or inconsistent with the protocol. Good forms answer the questions a participant actually has, in the order they have them: why am I being asked, what will happen to me, what could go wrong, what is in it for me, what happens to my data, and can I change my mind. They use short sentences, the second person, common words, and headings phrased as questions, and they aim for a reading age of about 11 to 13 years unless the audience needs simpler still. Many institutions have mandatory templates and wording, and those take precedence over this draft.
Write the participant documents for this study.
[STUDY_SUMMARY]
Readers: [PARTICIPANTS]
1. Work out the consent mode from the study summary and state it in one line: written (signed form), online (a consent screen before the first question), verbal (read aloud and recorded or logged), or anonymous (completion implies consent, no names collected). If the summary does not make it clear, pick the mode that fits the procedures and say so.
2. Write a participant information sheet with question headings: what the study is about and who runs it; why you have been asked; do you have to take part; what will happen (each step, time, place, recordings); possible disadvantages and risks; possible benefits; payment or reimbursement; what happens to your information (collected, stored, who sees it, how long, shared, published, future use); what happens if you stop; what if something goes wrong or you want to complain; who has reviewed the study; contacts. When a data protection law such as the GDPR applies, also cover the items it requires: who the data controller is, the legal basis, participants' rights and their research limits, and the data protection officer's contact, all as placeholders.
3. If the topic could cause distress (abuse, harassment, health, grief, self-harm, discrimination), say so plainly in the risks section, explain that participants can skip questions or stop, and add a "Where to get support" box with placeholders for support services suited to the population and country.
4. Write the consent form for the chosen mode as separate statements, one idea each (read the information, had a chance to ask questions, voluntary and can withdraw without giving a reason and without penalty, until when data can be withdrawn, recording, use of quotes, data sharing, future contact), with optional items clearly marked as optional. Written mode ends with signature and date lines for participant and researcher; online mode ends with an "I agree" and an "I do not agree" option and no signature; verbal mode gives the script and a researcher log line; anonymous mode collects no name or signature and states that submitted answers cannot be withdrawn because they cannot be identified.
5. If the readers are children or adults who may lack capacity, add an assent version in simpler language with pictures suggested where useful, and adapt the main sheet for the parent, guardian or consultee.
6. Check readability and consistency: flag sentences over about 20 words, jargon, and anything in the documents that contradicts the study summary or data handling.
- Describe risks honestly and specifically, including discomfort, time burden and privacy risks. Never write "there are no risks"; if they are minimal, say what they are and why they are small.
- Do not overstate benefits. If there is no direct benefit, say so. Payment is not a benefit and must not be large enough to pressure people.
- No exculpatory wording: nothing that asks participants to waive rights or releases the researchers from liability.
- Be precise about withdrawal: say when data can no longer be removed (for example after anonymisation or publication) instead of promising unlimited withdrawal.
- If participants are in a dependent relationship with the researcher (students, employees, patients), state that taking part or not will not affect their grades, job or care.
- Do not invent names, phone numbers, emails, approval numbers, retention periods, storage systems or legal bases. Use placeholders such as [ETHICS REFERENCE NUMBER] and [RETENTION PERIOD PER POLICY], and list every one at the end.
- If the study involves deception, write the sheet so it is truthful about everything it can be, and add a debrief text.
- If the user asks for wording that breaks these rules (no risks, no withdrawal, waived rights), do not use it. Say in one or two sentences why a committee would reject it, and write the honest version that protects what they are worried about, for example a clear point after which data cannot be withdrawn.
- Remind the user once that their committee's template and required wording override this draft.
## Participant information sheet
The consent mode in one line, then headings phrased as questions, plain language.
## Consent form
Separate statements with tick or initial boxes, ending in the form the consent mode needs (signature lines, an agree button, a verbal script or no identifiers).
## Assent version
Only when needed; otherwise one line saying why it is not needed.
## Readability and consistency check
Bulleted issues and fixes, plus an estimate of reading level.
## Placeholders to fill
Each placeholder and who can supply it.
````
---
## Write a reproducible lab or field protocol
`write-lab-protocol` · prompt · Research methods · https://hermes-ide.com/prompts/write-lab-protocol
Turns rough procedure notes into a reproducible lab or field protocol with materials, numbered steps, timings, safety notes, controls and troubleshooting. For scientists and technicians.
````markdown
Protocols fail to reproduce because of what the author takes for granted: an unstated temperature, "spin briefly", a reagent with no supplier or grade, a pause point nobody mentioned, or a step that only works if done within ten minutes of the previous one. A reproducible protocol states every quantity with units, every condition, every critical timing, the controls that show a run worked, and what to do when it does not. It is written so a competent colleague who has never done this procedure could follow it the first time, and it follows conventions used by protocol journals and repositories such as protocols.io and Bio-protocol.
Turn these notes into a protocol.
[PROCEDURE_NOTES]
1. Write a short overview: purpose, principle in one or two sentences, what the protocol produces, total hands-on and elapsed time.
2. Write the safety section: hazards from the chemicals, biological materials, equipment and field conditions mentioned, the protective equipment and containment level the notes imply, and waste disposal, with a reminder to check the safety data sheets and the local risk assessment.
3. List materials and equipment in tables: item, specification (concentration, grade, size), quantity per run, and supplier or catalogue number only where the notes give one. Include recipes for solutions with how to prepare and store them.
4. List what to prepare before starting (thawing, pre-warming, calibration, booking equipment, permits for fieldwork).
5. Write the procedure as numbered steps, one action per step, with quantities, units, temperatures, speeds (with g-force rather than rpm when centrifuging, if the notes allow conversion), durations, and the reason for any step whose purpose is not obvious. Mark critical steps with CRITICAL, safe stopping points with PAUSE POINT, and timing-sensitive steps with TIMING.
6. Describe controls (positive, negative, blanks, replicates) and the quality checks that show the run worked.
7. Describe expected results, with how a good and a failed result look.
8. Write a troubleshooting table from the problems the notes mention and the usual failure points of this kind of procedure.
9. List every gap: anything ambiguous or missing in the notes.
- Never invent quantities, concentrations, temperatures, times, catalogue numbers or safety limits. Where the notes are silent or vague ("a bit", "briefly", "until it looks right"), write [GAP: specify …] and list it under Gaps to resolve. You may suggest a typical value from general practice only if it is labelled "typical value, verify".
- Use SI units and consistent notation, and keep the user's units where converting would lose meaning.
- Do not remove safety steps from the notes. Add missing safety considerations rather than leave them out.
- Do not complete or optimise procedures involving dangerous pathogens, toxins, explosives or controlled substances beyond the notes. Format what is given, and refer the user to their biosafety or safety officer for the missing parts.
- If the notes describe something unsafe (for example mixing incompatible chemicals, or working outside required containment), say so at the top.
Use the contract's section headings in order. Materials and the troubleshooting section as tables (Problem | Likely cause | Fix). Procedure as a numbered list with sub-steps where needed and the CRITICAL, PAUSE POINT and TIMING labels in bold. Gaps to resolve as a numbered list with the step each gap affects.
````
---
## Write a research interview protocol
`write-research-interview-protocol` · prompt · Research methods · https://hermes-ide.com/prompts/write-research-interview-protocol
Writes a semi-structured research interview protocol with a consent script, question themes, probes, timing and reflexivity notes, tied to the research question. For qualitative researchers.
````markdown
A semi-structured interview protocol keeps interviews comparable without turning them into a spoken questionnaire. Good guides translate the research question into a few broad themes, ask open, non-leading questions that invite stories about concrete experiences ("Tell me about the last time…"), and rely on probes to go deeper. They start easy and move to sensitive topics once rapport exists, leave room for what the participant raises, and fit the time. The research question itself is never asked directly. Ethics is part of the protocol: consent is an ongoing conversation, participants can skip questions or stop, and the interviewer knows what to do if someone becomes distressed or discloses risk. Reflexivity notes record how the interviewer's own position may shape what is said and heard.
Write an interview protocol for a 60-minute video interview.
[RESEARCH_QUESTION]
1. Turn the research question into three to five interview themes, and show which part of the question each theme serves.
2. For each theme, write one or two main open questions and three to five probes: detail ("Can you walk me through that?"), example ("What happened the last time?"), meaning ("What did that mean for you?"), contrast, and clarification. Avoid leading, double-barrelled and yes or no questions, and jargon the participants would not use.
3. Order the themes from easy and descriptive to reflective and sensitive, and give each a time allocation that adds up to 60 minutes with five to ten minutes for opening and closing.
4. Write the opening script: thanks, purpose in plain language, recording and how data will be stored and anonymised, voluntary participation, the right to skip questions, pause or withdraw, and confirming consent on the recording. Mark where study-specific details from the approved ethics documents must be inserted.
5. Write the closing: an open "anything we have not covered?" question, a short debrief, next steps, and where to get support if the topic is sensitive.
6. Add practical notes for video interviews (connection or recording checks, privacy of the participant's location, a backup plan).
7. Write a distress and disclosure procedure the interviewer can use mid-interview: signs to watch for, the words to offer a pause, skip or stop, when to end the interview and not resume, what to do if a participant discloses a risk of harm to themselves or others (follow the study's approved safeguarding and referral procedures, within the limits of confidentiality stated at consent), and placeholders for local support contacts.
8. Write reflexivity prompts for the interviewer to answer before and after each interview.
9. List what to check in a pilot interview.
- Questions must be open and neutral. Rewrite any that presume an answer.
- Do not invent ethics approval numbers, data-protection details or support-service contacts. Use placeholders such as [ETHICS REF] and [LOCAL SUPPORT CONTACT].
- Keep the number of main questions realistic for the time: roughly one main question per five to eight minutes of interview.
- If the participants are a vulnerable group (children, people in crisis, patients, people in a dependent relationship with the researcher), add the extra safeguards this needs and flag that the ethics committee must approve the protocol.
- If the research question is not suited to interviews (for example it asks for prevalence or effect sizes), say so and suggest a better method before writing the guide.
## Protocol overview
Research question, approach, participants, mode, duration, themes with the part of the question each serves.
## Before the interview
Checklist.
## Opening and consent
Script, with placeholders in square brackets.
## Interview guide
For each theme: a heading with minutes, main question(s) in bold, probes as bullets.
## Distress and disclosure procedure
Numbered steps the interviewer can follow during the interview, with example wording and placeholders for contacts.
## Closing
Script.
## After the interview
Field notes template and data-handling steps.
## Reflexivity notes
Prompts before and after.
## Pilot checklist
Bullets.
````
---
## Write a study preregistration
`write-preregistration` · prompt · Research methods · https://hermes-ide.com/prompts/write-preregistration
Writes a study preregistration with hypotheses, design, sampling plan, variables, exclusion rules and a pre-specified analysis plan, flagging open choices. For OSF or AsPredicted users.
````markdown
A preregistration is a time-stamped plan that separates confirmatory tests, decided before seeing the data, from exploratory analysis. It only protects against flexible analysis if it is specific enough that a stranger could run the analysis from it and reach the same decision: the exact variables and how they are computed, the statistical model, the inference criterion, the sample size and stopping rule, how outliers, missing data and exclusions are handled, and what result would count as support or as disconfirmation. Vague preregistrations ("we will use appropriate tests") give a false sense of rigour. The OSF Preregistration template covers study information, design, sampling, variables and the analysis plan; AsPredicted asks nine short questions; secondary-data templates add what the researchers already know about the dataset.
Write a osf preregistration for this study.
[STUDY]
[HYPOTHESES]
1. Rewrite each hypothesis so it is testable: name the variables, the direction, the population, and the specific statistical test that will evaluate it. Split compound hypotheses into separate ones and label each H1, H2, and so on.
2. Find every analysis choice the study description leaves open (for example the covariates, the outlier rule, the handling of missing data, one- or two-tailed tests, the correction for multiple comparisons, the smallest effect size of interest, manipulation checks) and list them first under Undecided choices with options and a recommended default. Draft the plan with your recommendation marked [CONFIRM].
3. Write the preregistration in the structure of the chosen template:
- osf: study information (title, research questions, hypotheses); design plan (study type, blinding, design, randomisation); sampling plan (existing data, data collection procedures, sample size, sample size rationale, stopping rule); variables (manipulated, measured, indices); analysis plan (statistical models, transformations, inference criteria, data exclusion, missing data, exploratory analyses).
- aspredicted: whether data have been collected, the main question or hypothesis, the key dependent variable and how it is measured, conditions, the analyses, outliers and exclusions, sample size, anything else, and the type of study.
- secondary-data: the osf sections plus the dataset's source, what the authors have already seen or analysed in it, and how prior knowledge of the data could bias the plan.
4. For each hypothesis, state the decision rule: what result supports it, what result counts against it, and what result is inconclusive (for example an equivalence test against the smallest effect size of interest).
5. Separate confirmatory from exploratory analyses explicitly.
6. Add a deviations log template for reporting any departures from the plan.
- Do not invent a sample size, power, effect size or prior result. If the sample size rationale is missing, explain the options (a power analysis with a justified effect size, a precision target, resource constraints) and leave [SAMPLE SIZE RATIONALE] for the user.
- Every variable must have an operational definition: the instrument, items, scoring and the transformation.
- If data already exist or have been looked at, say so honestly in the plan and recommend the secondary-data template; a preregistration written after seeing the results is not a preregistration.
- Keep statistical terms precise. If a planned test does not match the design or the data type, say so and propose an appropriate one.
- Keep AsPredicted answers short, as the format requires; put detail in the osf template only.
## Undecided choices
Table: choice | options | recommended default | why.
## Preregistration
The template's sections in order, with [CONFIRM] markers on recommended choices.
## Deviations log
Empty table: date | planned | actual | reason | effect on conclusions.
````
---
## Write a survey questionnaire
`write-survey-questionnaire` · prompt · Research methods · https://hermes-ide.com/prompts/write-survey-questionnaire
Writes an unbiased questionnaire for a stated research aim, with construct mapping, appropriate response scales, skip logic and a pilot checklist. Use before fielding any survey.
````markdown
Survey data is only as good as its questions. The usual failures are well documented in survey methodology: questions with no analysis behind them, double-barrelled or leading wording, unbalanced or unlabelled scales, overlapping answer options, sensitive questions too early, and surveys too long for the audience, which raises drop-out and straight-lining. A good questionnaire starts from the aim, maps every question to something it measures, and is piloted before launch.
Write a questionnaire for this aim:
[AIM]
Respondents: [AUDIENCE]. Target median completion time: 10 minutes.
1. Break the aim into the constructs to measure and, for each, the analysis it will feed. Drop anything that does not feed the aim.
2. Where an established, validated scale fits a construct, name it and say to check its licence and use its exact wording; do not reproduce or paraphrase it. Otherwise write new items.
3. Write each item in plain words for this audience: one idea per question, neutral wording, a clear time frame ("in the past 30 days"), and no jargon or double negatives.
4. Choose the response format per item: single or multiple choice with mutually exclusive, exhaustive options (with "Other (please specify)" or "Not applicable" where they are real answers); fully labelled 5- or 7-point balanced scales; numeric entry with units; or open text, used sparingly.
5. Order the survey: screening questions, then easy and engaging questions, then the core, then sensitive questions, then demographics (only those the analysis needs). Keep related items together and randomise option order where order could bias answers.
6. Add skip logic so nobody sees a question that does not apply to them.
7. Budget the length: roughly 3 to 4 simple closed items per minute and 1 to 2 minutes per open question. If the aim needs more, say which items to cut.
- Every item maps to a construct in the construct map. No "nice to know" questions.
- Avoid leading, loaded, double-barrelled and absolute ("always", "never") wording, and do not ask respondents to predict their own future behaviour unless intention is the construct.
- Collect the minimum personal data. Flag any item that is sensitive or identifying and suggest a less intrusive version.
- If the aim is too broad to answer with one survey, or a survey is the wrong method (for example the question is about actual behaviour that logs could measure), say so first and suggest the better method.
## Construct map
A table: construct | item IDs | analysis it feeds.
## Introduction text
A short invitation stating purpose, time, anonymity or confidentiality, and that participation is voluntary.
## Questionnaire
Numbered items (Q1, Q2…) grouped in sections. For each: the question text, the response type, the full list of options or scale labels, and any logic in brackets, for example "[Show if Q3 = Yes]".
## Pilot checklist
Checkboxes covering cognitive interviews with 5 to 10 people from the audience, timing, logic testing on every path, item non-response, straight-lining, and open-text quality.
## Analysis notes
Estimated completion time, and any item that needs special handling (reverse-scored, multi-select, open coding).
````