# Hodios paste pack: Research methods
Everything in Research methods from Hodios, the open prompt library by Hermes IDE: 10 entries, catalog 2026.1002.2.
Every entry is dedicated to the public domain under CC0 1.0. Copy, change and share them freely, no attribution needed.
Browse and search the library at https://hermes-ide.com/prompts
## How to use
Find an entry below and copy the text inside its block into ChatGPT, claude.ai or any chat. Replace each [PLACEHOLDER] with your own material. Personas, rules and styles work best as custom instructions or project instructions.
## Contents
- 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)
- [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 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.
````
---
## 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 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).
````