Update to Unbounce - Classic Builder

{
  "name": "mcp-feedback",
  "description": "Record a user's feedback about the Unbounce MCP tools — a bug, praise, a feature request, confusion, or anything else — straight to the team via the submit_feedback tool, with no copy/paste. Use when the user wants to report a bug, share feedback, praise something, request a feature, or flag that a tool was confusing. Also covers login/connection issues — the user can't connect the MCP in their client, sees an OAuth error (\"access denied\", \"invalid_grant\", a failed redirect), or keeps getting asked to log in again. You may also offer it after a hard MCP tool failure. It confirms the exact content with the user and redacts secrets before anything is stored.",
  "included_files": [],
  "skill_md_contents": "---\nname: mcp-feedback\ndescription: Record a user's feedback about the Unbounce MCP tools — a bug, praise, a feature request, confusion, or anything else — straight to the team via the submit_feedback tool, with no copy/paste. Use when the user wants to report a bug, share feedback, praise something, request a feature, or flag that a tool was confusing. Also covers login/connection issues — the user can't connect the MCP in their client, sees an OAuth error (\"access denied\", \"invalid_grant\", a failed redirect), or keeps getting asked to log in again. You may also offer it after a hard MCP tool failure. It confirms the exact content with the user and redacts secrets before anything is stored.\nrequires:\n  mcpServers:\n    - unbounce-mcp\n---\n\n# Submit Unbounce MCP feedback\n\nRecord the user's feedback about the **Unbounce MCP tools** to the team's store by\ncalling the **`submit_feedback`** tool. The tool persists the record server-side, so\nnothing has to be copied out of the conversation into Slack or anywhere else.\n\n> The `mcp-` prefix here means \"pertains to Unbounce MCP,\" not \"about a page.\" This\n> skill is about capturing feedback on the MCP tools themselves — whether they broke,\n> delighted, confused, or fell short.\n\n## Hard rule: report, don't repair\n\n**Do NOT try to fix, retry, or work around the thing being reported.** This skill\nrecords feedback on what already happened. Never invent tool-call arguments or error\ntext — anything not actually present is `unknown`. (Fixing the underlying task, if the\nuser wants that, is separate work done after the feedback is recorded.)\n\n## 1. Gather the feedback\n\nSettle two things — from the conversation where possible, asking only what you can't\ninfer:\n\n- **`type`** — one of `bug` · `praise` · `feature_request` · `confusion` · `other`.\n- **`message`** — the feedback in the user's own words. Keep it faithful; don't\n  editorialize.\n\nFor a **`bug`**, also assemble the **`context`**: the verbatim failing tool call(s)\nfrom the transcript — exact tool name, exact arguments JSON, and the raw result/error\ntext (call out any `code`/`reason`/`remedy` fields). Include the relevant one(s),\nespecially the failing call. If the failure happened in another session and isn't in\nthe transcript, ask a couple of targeted questions and mark transcript-only fields\n(exact arguments, exact raw error) as `unknown`. For non-bug types, `context` is\nusually unnecessary — include a light pointer (the tool or page in question) only if\nit genuinely helps.\n\n**Login / connection problems** are a `bug`: capture what the user was doing, the\nclient they're in, and the exact error text (e.g. `access denied`, `invalid_grant`, a\nfailed redirect, repeated re-login prompts). Note that if the MCP can't connect _at\nall_, `submit_feedback` itself won't be reachable — that's expected, and step 4's\ninline fallback is how the feedback still gets out.\n\n## 2. Redact secrets\n\nReplace any access token, API key, password, or bearer token in the `message` or\n`context` with `«REDACTED»`. Count how many you redacted. (The server re-scrubs as a\nbackstop, but do your pass first — the user is about to review this content.)\n\n## 3. Confirm the exact content, then submit\n\nShow the user the **exact record** you're about to store — the `type`, the `message`,\nand the `context` if any (post-redaction) — and get an **explicit yes** before\ncalling the tool. This is the consent step; do not skip it and do not submit\nsilently. (Same ask-first bar the page tools hold for Dynamic Text Replacement.)\n\nOn yes, call **`submit_feedback`** with `type`, `message`, and `context` (if any). The\nserver stamps identity, timestamp, and build itself — you don't pass those.\n\n## 4. On failure, don't lose the feedback\n\nIf `submit_feedback` fails (an error result, the tool isn't available, or an older\ndeploy predates it): **retry once.** If it still fails, **print the composed,\nalready-redacted record inline** in the conversation and tell the user to pass it to\nthe team directly. There is no file to write — the goal is simply that the feedback is\nnever silently lost.\n\n## 5. Report back\n\nOn success, print to the conversation — nothing more:\n\n1. **Recorded.** A one-line plain-language summary of what was captured, with the\n   `type`.\n2. The returned **`feedback_id`**.\n3. **Only if the server redacted something you missed:** `Server redacted N\nadditional secret(s).` (compare the tool's `redacted_secrets` to your own count).\n\nExample:\n\n> Recorded your **bug** report: `set_page_url` returned `DOMAIN_NOT_FOUND` for a domain\n> `list_client_domains` had just listed. (feedback_id `a1b2c3d4`)\n"
}