Update to getuserfeedback.com

{
  "description": "Read feedback conversations, send respondent follow-ups, or manage inbox state through getuserfeedback.com.",
  "included_files": [],
  "name": "follow-up-with-users",
  "skill_md_contents": "---\nname: follow-up-with-users\ndescription: Read feedback conversations, send respondent follow-ups, or manage inbox state through getuserfeedback.com.\n---\n\n# Follow up with users\n\nUse the Response and conversation context to identify what a follow-up would\nclarify. A useful question asks about the specific experience, its consequence,\nor the workaround the person used. Keep it short and neutral; avoid asking the\nrespondent to endorse a proposed solution or repeat something they already\nexplained. Do not promise a fix or delivery date without an explicit commitment\nfrom the user.\n\nWhen asked for drafts or suggestions, return drafts without sending them or\nchanging inbox state. When sending is requested, distinguish the message actually\nsent from any remaining drafts and report the returned delivery state accurately.\n\n`conversation_start` starts a thread from a Response. `conversation_continue`\nreplies to an existing thread. Both send an external message; their message\nreceipts expose delivery state, not proof that the recipient read the message.\nThe server resolves the recipient from the Response or conversation, without\nexposing their stored contact details to the model.\n\n`inboxItemId` identifies the current user's inbox row, separately from the\nResponse and conversation IDs. Inbox read, archive, and star operations affect\nthat row. `inbox_items_list` uses priority ordering; concurrent inbox changes\ncan shift records between pages.\n"
}