Update to UserTold

{
  "description": "Plan participant recruitment for a UserTold Study and produce participant-readable recruitment copy plus canonical Invitation, Visibility, and neutral Intake inputs. Use when choosing whom to invite, comparing outreach channels, setting an honest reward, drafting an in-product launcher or direct-link invitation, screening without revealing qualifying answers, or translating an existing recruitment plan into UserTold configuration. Do not use to send outreach, source a participant panel, fulfill rewards, claim representative sampling, or provide legal advice.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 239
    },
    {
      "relative_path": "references/channel-selection.md",
      "size_in_bytes": 2345
    },
    {
      "relative_path": "references/invitation-examples.md",
      "size_in_bytes": 7315
    },
    {
      "relative_path": "references/rewards.md",
      "size_in_bytes": 1936
    }
  ],
  "name": "usertold-recruit-participants",
  "skill_md_contents": "---\nname: usertold-recruit-participants\ndescription: Plan participant recruitment for a UserTold Study and produce participant-readable recruitment copy plus canonical Invitation, Visibility, and neutral Intake inputs. Use when choosing whom to invite, comparing outreach channels, setting an honest reward, drafting an in-product launcher or direct-link invitation, screening without revealing qualifying answers, or translating an existing recruitment plan into UserTold configuration. Do not use to send outreach, source a participant panel, fulfill rewards, claim representative sampling, or provide legal advice.\n---\n\n# Recruit UserTold Participants\n\nTurn a research question into a small, truthful recruitment plan for people the team can already reach. Recruitment is distribution into a UserTold Study, not a marketing funnel.\n\n## Scale to the request\n\nFor a short in-product setup request, do not automatically expand into a full outreach campaign, reward plan, or Intake. If the user names audiences and routes, preserve those boundaries. If they name audiences but not routes, derive the public entry surface and primary authenticated workflow from the smallest authoritative product context, then state the coverage limitation. Produce only the Invitation, Visibility, and safeguards needed to create the Studies. Inspect the host application only when an exact route is required for installation. Ask only for information that blocks a truthful configuration.\n\nUse the full recruitment packet below when the user asks how to reach, qualify, reward, or invite participants beyond the in-product placement.\n\n## Establish the participant boundary\n\n1. State the behavior or recent experience that makes someone relevant. Prefer “attempted checkout in the last 30 days” over a persona label.\n2. State exclusions that protect the research question, participant safety, conflicts, and duplicate participation. Do not add demographic filters without a study-specific reason.\n3. Name the reachable population and the resulting coverage limit. Never call a convenience sample representative.\n4. Record whether recontact is needed as a separate, optional consent choice.\n\n## Choose distribution\n\nRead [references/channel-selection.md](references/channel-selection.md), choose one primary channel, and name one meaningfully contrasting channel. Explain why each reaches the target behavior and add one explicit sampling-bias sentence.\n\nEmail and CRM are distribution only: special URL → expanded Invitation → explicit **Start**. The participant must select Start before permissions or recording. A link is never consent. Do not claim UserTold sends email, operates a CRM, or personalizes the link to an identity.\n\nTrack source with channel-level `utm_source`, `utm_medium`, and `utm_campaign` values where the host flow preserves them. Use campaign labels, not personal data. Report response and completion by source without turning the result into a representative-sample claim.\n\n## Set the offer\n\nRead [references/rewards.md](references/rewards.md). State all four terms exactly:\n\n- duration;\n- reward or “No reward”;\n- eligibility, including gift restrictions or alternatives;\n- delivery timing and method, or “Not applicable.”\n\nAbout $80/hour is marketplace orientation for human-moderated consumer interviews, not a universal rate or a calculator. AI-moderated and short in-product interviews normally use a smaller fixed reward. Participant copy must show the actual promise, such as “20 minutes · $25 gift card.” UserTold records the promise; it does not fulfill payment.\n\n## Select presentation and timing\n\nChoose one `presentation_mode`:\n\n- `passive`: a compact launcher the participant opens; use for voluntary feedback or a standing bug-report route.\n- `contextual`: show an expanded panel on a relevant product route; use when current product context matters.\n- `direct_link`: distribute the generated `recruitment_url`; use for email, CRM, community posts, or a targeted new-feature test. It does not participate in automatic page placement.\n\nFor automatic placement, define Visibility v1 with the fewest include/exclude rules needed. State when recruitment opens and closes plus any maximum-participant or contact-cadence rule as an operational timing plan. Visibility does not encode dates or display frequency; do not invent fields for them or claim UserTold enforces an outreach cadence. Respect remembered **Minimize** and **Hide** choices. Never interrupt an intake, interview, or completion flow, and never convert observed frustration into an automatic interruption.\n\n## Draft neutral Intake\n\nAsk only questions needed to determine the behavioral boundary. Use balanced answer options and neutral wording that does not signal which answer qualifies. Put qualification logic in `qualification_rules`, not in participant copy. Do not ask for contact details unless the workflow requires them and the participant agrees.\n\nProvide:\n\n- `title`, `welcome_message`, and concise `consent_text`;\n- ordered `questions` using the existing Intake fields (`question_text`, `question_type`, `required`, optional `options`, numeric bounds, and `qualification_rules`);\n- participation/recording consent copy plus separate optional recontact copy and the point where the host flow will ask it;\n- a neutral disqualification message that does not reveal the rule.\n\nRecontact permission is consent, not qualification. Do not put it in `qualification_rules` or claim an ordinary Intake question writes UserTold's response-level `consent_followup` value. If the discovered participant flow cannot capture separate recontact consent, flag that limitation and leave recontact off.\n\nThe public UserTold MCP surface can create or update Studies with Invitation and Visibility. It does not expose a new recruitment or Intake tool. Produce Intake inputs for the dashboard or published CLI unless the live discovered surface explicitly supports more.\n\n## Produce full recruitment configuration\n\nReturn this compact packet:\n\n1. **Participant:** behavioral definition; exclusions; reachable population.\n2. **Channels:** primary; contrasting channel; sampling-bias note; source tags.\n3. **Offer:** exact duration, reward, eligibility, delivery.\n4. **Copy:** launcher label; optional panel eyebrow, headline, body, and CTA; outreach copy when relevant.\n5. **Presentation:** passive/contextual/direct-link rationale; Visibility and timing plan.\n6. **Intake:** neutral participant-facing questions and hidden qualification intent/rules.\n7. **Safeguards:** consent, optional recontact, Minimize/Hide, and non-interruption rules.\n8. **Canonical JSON:** exact `invitation`, `visibility`, `intake_create`, and optional `intake_update` objects directly usable with shipped UserTold fields. Put `title`, `welcome_message`, `consent_text`, `max_participants`, and `questions` in `intake_create`; put `disqualified_message` or other post-create copy in `intake_update`. Do not emit an invented combined `intake` schema.\n\nUse only Invitation fields and enums shown in [references/invitation-examples.md](references/invitation-examples.md). `contextual` and `direct_link` require a panel. Omit reward entirely when there is no reward. Keep one reward promise, and never add payment, email, CRM, participant-sourcing, identity, or sampling fields to the JSON.\n\nBefore writing through UserTold, discover the live MCP operations. Prefer `studies.get` to inspect an existing Study and `studies.create` or `studies.update` for supported fields. Show the packet and require explicit approval before activating a Study or Intake or changing a live Invitation/Visibility configuration.\n\n## Check the packet\n\nConfirm that participant copy and JSON agree on duration and reward, direct links require explicit Start, qualification answers are not telegraphed, recontact is not used as qualification, source tracking contains no identity, and the bias note names who the chosen channel misses. Read the relevant scenario in [references/invitation-examples.md](references/invitation-examples.md) when the offer is unusual or a direct link is involved.\n"
}