MCP: Starter Skills

GQ-authored starter skills for the in-product skills feature (Settings → AI & MCP). Each entry gives the four author-facing fields — Name, Slug, Description, Instructions — plus a Gating recommendation for the Settings tab.

​

Conventions used throughout

No tool names in bodies.

• Tools get renamed; a copied skill is never re-synced. Bodies name intents (“search across transcripts”), which the agent resolves against the live catalog.
• Judgment, not mechanics. The tool schema already tells the agent what a parameter is. A skill is for what the schema can’t say: what good looks like here, what order things must happen in, and what must never happen.
• Renderer-safe formatting. The skill body is Tiptap JSON rendered to markdown. Only headings, paragraphs, bullet/ordered lists, bold and italic survive. No tables, code blocks, links, or blockquotes — they are silently flattened.
• Descriptions carry the trigger. There is no separate trigger field. The description is the entire discovery surface: it is squished to one line in the initialization block, and the agent picks skills from it alone. Every description below starts with when to reach for the skill.
• Every claim verified against the production tool surface. Each statement about what an agent can or can’t do was checked against app/mcp/tools/generated/ and the controllers behind it, not assumed. Where a capability doesn’t exist (repository writes, message sending, candidate merging), the skill says so, because an agent that believes otherwise will report work it never did.

​

Gating guidance

Default to advisory. Require a skill only where an unguided agent could do something irreversible, externally visible, or destructive. Three of the eight are recommended as required; the rest are advisory.

​

1. Screener Creation

Slug: screener-creation Description: Use when writing, editing, or reviewing a screener. How we structure screener questions so they qualify the right participants, hide the qualifying intent, and filter out fraud. Gating: Required — add_interview_screener_question, add_survey_screener_question, add_unmoderated_screener_question, update_interview_screener_question, update_survey_screener_question, update_unmoderated_screener_question, create_interview_screener, create_survey_screener, create_unmoderated_screener, apply_interview_screener_template, apply_survey_screener_template, apply_unmoderated_screener_template Why required: a screener that leaks its qualifying intent silently poisons the sample, and nobody notices until analysis. This is the clearest case in the set for enforcing a standard rather than suggesting one. Instructions: Use this whenever you create or edit a screener. A good screener qualifies the right people, screens out fraud, and stays short. Prefer templates? Check whether one of our vetted screener templates fits before authoring from scratch. Reuse beats reinvention, templates already encode our qualifying logic and anti-fraud checks.

• Disqualify fast. Put the hardest qualification criteria first so unqualified respondents drop early.
• Hide intent. Never phrase a question so the “right” answer is obvious. Mix in plausible distractor options.
• One concept per question. Split compound questions.
• Keep it under 8 questions. Longer screeners lower completion and raise cost.

Anti-fraud:

• Include at least one attention check (e.g. “Select ‘Somewhat agree’ for this question”).
• Include one open-text question early — bots and click-farms reveal themselves in free text.
• Avoid questions that let respondents guess the target demographic from the options alone.
• Set qualifying answers explicitly. Don’t rely on defaults.

Guardrails:

• Never ask for sensitive personal data (health, financial account numbers, government IDs) in a screener.
• If the study needs sensitive eligibility criteria, flag it for a researcher rather than encoding it in the screener.

​

2. Recruiting Participants

Slug: recruiting-participants Description: Use when sourcing candidates for a study, shortlisting them, or sending screener invitations. How we recruit from our panel without over-messaging people or inviting the wrong ones. Gating: Required — invitation sending. send_interview_screener_invitation, send_survey_screener_invitation, send_unmoderated_screener_invitation Why required: sending is the one action in the entire tool surface with no undo. Gate the send, not the search, shortlisting is reversible and gating it only adds friction. Instructions: Use this when finding candidates for a study, shortlisting them, or inviting them to a screener. Recruitment spends panel goodwill, and that budget is finite.

• Start from a saved segment when one fits. Segments already encode eligibility our filters don’t know about.
• When no segment fits, search the panel on the criteria that actually matter for the study, and say which criteria you used.
• Look at how many candidates match before you propose a batch. A pool barely larger than the target means the screener will not have room to disqualify anyone.

Sizing a batch:

• Invite three to five times your target participant count. Most screener recipients never respond, and some who respond won’t qualify.
• Prefer one well-sized send over a series of top-ups. Repeated small sends to the same segment read as spam.
• If the pool can’t support the target, say so before sending rather than inviting everyone available and hoping.

Respect the panel:

• Don’t invite anyone who was invited to another study in the last 30 days unless the researcher explicitly overrides it.
• Don’t invite people who already participated in a closely related study, their responses are no longer naive. Shortlisting and sending filter differently, and the difference matters.
• Shortlisting reports back who was already on the study, unreachable, ineligible, or outside your team access. Sending only filters unreachable people, it will not tell you someone is a repeat or ineligible. Don’t rely on the send step to catch a mistake in who you chose.
• Treat those filters as a backstop, not as your own. Surface who you intended to invite and who was dropped, rather than letting skips pass silently.

Sending:

• Always show the researcher the actual recipient count and the message that will go out, and get an explicit yes immediately before sending.
• A researcher approving a shortlist has not approved a send. Ask again at the moment of sending.
• Treat an ambiguous answer as a question to clarify, not as approval.
• Both shortlisting and sending cap out at 500 candidates per batch. Split anything larger, and tell the researcher you’re splitting it so the batches aren’t a surprise.
• If something fails partway through, stop. Report what was shortlisted, whether anything was sent, and the current state. Don’t retry a send.

• Never send to a list you assembled outside the study’s segment or search without saying so explicitly.
• Never work around a candidate the platform declined to contact. That flag exists for a reason, surface it instead.

​

3. Adding Incentives

Slug: adding-incentives Description: Use when setting or changing a participant incentive on a study. How we choose fair amounts by session type, length, and audience seniority. Gating: Advisory. Why advisory: an incentive on a draft study is editable right up until activation, so a wrong amount is cheap to correct. Requiring this would gate broad study-update tools for a narrow purpose. Instructions: Use this when setting or changing what participants are paid. Incentives are the single biggest lever on both recruitment speed and cost, and underpaying is the most common reason a study stalls. Start from session length and type:

• Moderated interviews: scale to the booked duration, not the expected duration. A 60-minute slot is an hour of someone’s day even if you finish early.
• Unmoderated tests and surveys: scale to realistic completion time, which is usually longer than the estimate.
• Anything requiring preparation, installation, or homework before the session: pay for that time too.

Adjust for the audience:

• General consumers sit at the base rate.
• Professionals in specialist roles need meaningfully more, their time has a market price and they know it.
• Senior and hard-to-reach audiences (executives, clinicians, developers at specific companies) need substantially more, and even then recruitment will be slower.
• Existing customers of ours often participate for less, but never assume goodwill covers the whole amount.

Consistency matters more than precision:

• Two studies running at once for the same audience should pay the same. Participants talk, and inconsistency reads as arbitrary.
• Don’t raise an incentive partway through recruiting to rescue a stalled study without flagging it, people invited at the old rate will have been underpaid for the same work.
• Round to clean numbers. Odd amounts look calculated rather than fair.

Guardrails:

• Never set an incentive to zero on a study recruiting outside our own customer base.
• Currency has to be right at creation time and is awkward to change later — confirm it rather than defaulting.
• If a proposed amount is far below what the audience warrants, say so plainly instead of setting it quietly.

​

4. Synthesis & Insights

Slug: synthesis-and-insights Description: Use when summarizing research, answering a question that spans sessions or studies, or interpreting what participants said. How we ground every claim in transcript evidence and never fabricate quotes. Gating: Advisory. Why advisory: synthesis is read-only. The failure mode is a bad claim, not a bad write, and gating read tools would slow every session for a risk that review catches. Instructions: Use this whenever you summarize research, answer a question that spans sessions or studies, or interpret what participants said. Every claim must trace back to something a participant actually said or did. Ground everything in transcripts:

• Work from the actual transcript text, not from titles, summaries, or study names. Read what was said.
• When a question spans more than one study, search across transcripts rather than opening studies one at a time.
• Note which session and which participant each piece of evidence comes from, so a claim can be traced back.

Search widely before you conclude: Transcript search runs two arms at once: a meaning-based one and a literal full-text one. They reward opposite styles of query, so use each as intended rather than typing the same string into both.

• For the meaning-based arm, write the way a person would talk. A natural phrase or a real question works better than keywords, and phrasing something as a question retrieves differently from a statement.
• For the full-text arm, name the one or two words a participant would actually say, and OR the synonyms rather than stacking terms. Unquoted words are ANDed, so more than two of them together will usually match nothing at all. Reserve quotes for a phrase said verbatim.
• Vary the wording across several searches. Participants describe the same thing differently (“onboarding” / “getting started” / “first time” / “setup”), and one query rarely surfaces everything.
• Search more than one surface. Transcripts, session responses, and existing repository highlights and insights each hold different evidence.
• Go broad, then narrow. Start unscoped to see the whole landscape, then scope to specific studies once you know what’s relevant.
• Don’t stop at the first page. A page of matches is not the same as all of them.
• Know when you’re done. Stop when new searches stop turning up new evidence, not when the first query returns something plausible.

• Think of it as a chain: what a participant said, then a notable moment, then a theme, then a finding. Don’t skip levels.
• A single participant saying something is a signal, not a finding.
• Treat something as a finding only when two or more participants independently support it.
• State findings as observations about users, not recommendations. (“Users abandon at the payment step” — not “Add a progress bar.”)
• Always carry at least one supporting verbatim quote with the finding.

• Say how many participants support a claim and how strongly.
• Distinguish what participants said from what they did, stated preference and observed behavior often diverge; call it out when they do.
• Don’t overstate confidence. Small samples describe, they don’t prove.

• Never fabricate a quote or attribute one to the wrong participant. If you can’t find supporting evidence, say the claim is unsupported rather than inventing support.
• Keep participant PII out of anything summary-level or shareable.

​

5. Setting Up a Study

Slug: setting-up-a-study Description: Use when creating a new interview, survey, or unmoderated study from a research brief. Our naming conventions, what has to be decided before creating, and what a researcher always finishes by hand. Gating: Advisory. Why advisory: a draft study is not visible to participants and is easy to delete. Let agents move fast here; the irreversible step downstream (inviting people) is gated by the recruitment skill. Instructions: Use this when turning a research brief into a study. The goal is a well-formed draft the researcher can review and activate, not a study that goes live on its own. Before creating anything:

• Confirm the research question. A brief that names a topic but not a question produces a study nobody can analyze.
• Confirm the method fits: moderated interviews for depth and follow-up, unmoderated tests for observed behavior at scale, surveys for breadth and incidence.
• Confirm the audience and how many participants. These drive the screener and the incentive, and changing them later means rebuilding both.

Naming:

• Name a study so someone who wasn’t involved can tell what it covered and roughly when, the topic and the quarter or month, not an internal project codename.
• One study per distinct audience. If the brief covers two segments worth comparing, that’s two studies, and say so rather than blending them.

Order of operations:

1. Create the study first. Almost everything else attaches to it.
2. Set the currency while the study is still a draft. Currency can only be changed on a draft, and a later attempt to change it is ignored rather than rejected — so it will look like it worked.
3. Screener questions can be included when you create an interview or unmoderated study, which is usually the cleaner path. Adding them afterwards works too. For surveys, the questions you pass at creation are the survey itself; screener questions are always a separate step.
4. Add moderators, blocks, or scheduling last, once the shape is settled.

If you apply a screener template, be aware it replaces every existing question rather than adding to them. Apply the template first, then edit. What you don’t do:

• Don’t activate a study. Activation is deliberately a human step in the Great Question interface, and there is no path to it here. Always hand back a draft.
• Don’t invite anyone as part of setup. Recruitment is a separate decision with its own approval.
• If a step fails after the study exists, stop and report what was created and what state it’s in. A half-built draft is recoverable; a silently mangled one is not.

Handing back:

• Tell the researcher what you created, what you assumed where the brief was silent, and exactly what they need to do to activate, including anything that can only be set in the interface.

​

6. Study Communications

Slug: study-communications Description: Use when drafting or revising any message to participants — invitations, reminders, confirmations, or follow-ups. Our voice, required disclosures, and what never goes out without a human reading it. Gating: Required — message composition and revision. compose_study_message, revise_study_message Why required: these messages go to real people under our name, and tone or a missing disclosure is not something a researcher reliably catches when skimming a draft. Gating composition means the standard applies before the draft exists, not after. Instructions: Use this when writing or revising anything a participant will read, screener invitations, booking confirmations, reminders, thank-yous, or cancellations. Voice:

• Write like a person, not a brand. Short sentences, plain words, no marketing tone.
• Respect their time in the first line. Say what this is and what you’re asking for before anything else.
• Never imply the recipient has been selected or accepted when they are only being invited to a screener.

Always include:

• What the study is about, in one honest sentence. Vague framing gets treated as spam.
• The time commitment, and whether it’s a live session or something they complete on their own.
• The incentive amount and what earns it. If eligibility depends on completing the session, say so.
• A clear way to decline or opt out.

Prefer the account’s templates:

• Check whether the account already has a message template for this kind of message before writing from scratch. Templates carry the disclosures and legal wording that hand-written copy tends to drop. Fetch the default for this kind of message, then carry its subject and body into your draft and adapt from there, templates aren’t applied automatically, so starting from a blank draft silently loses everything the template encodes.

Revising:

• When asked to shorten, cut adjectives and hedging first, never the disclosures.
• Preserve any personalization or merge fields exactly. Rewriting them silently breaks the send.
• Show what changed when you revise, rather than returning a new draft as if it were the original.

Guardrails:

• Composing and revising only ever produce a draft. Nothing you write here reaches a participant on its own, and the only message an AI tool can actually send is a screener invitation. For every other kind, reminders, confirmations, follow-ups, hand the draft back and say plainly that a person needs to send it from Great Question.
• Never describe a drafted message as sent, scheduled, or queued.
• Never state or imply a payment amount, timeline, or eligibility rule you haven’t confirmed against the study.
• Never include another participant’s name or details in a message.