Update to Userflow

{
  "name": "userflow-banner-creator",
  "description": "Create an in-app banner in Userflow through a guided, conversational flow — gather context from a short summary, pasted content, attached file, public page, or linked document/ticket in a connected app; draft and refine short banner copy; add an optional CTA; configure placement and behavior; optionally target users; show a confirmation card; create an unpublished draft through Userflow MCP; return the Builder link; and offer to publish. Use whenever a user with Userflow MCP connected asks to create or add an in-app banner, announce maintenance, a promotion, or an update in a page-top or page-bottom bar, or turn a note, ticket, or document into a Userflow banner. Requires the Userflow MCP connector.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 490
    },
    {
      "relative_path": "references/mcp-reference.md",
      "size_in_bytes": 5571
    }
  ],
  "skill_md_contents": "---\nname: userflow-banner-creator\ndescription: Create an in-app banner in Userflow through a guided, conversational flow — gather context from a short summary, pasted content, attached file, public page, or linked document/ticket in a connected app; draft and refine short banner copy; add an optional CTA; configure placement and behavior; optionally target users; show a confirmation card; create an unpublished draft through Userflow MCP; return the Builder link; and offer to publish. Use whenever a user with Userflow MCP connected asks to create or add an in-app banner, announce maintenance, a promotion, or an update in a page-top or page-bottom bar, or turn a note, ticket, or document into a Userflow banner. Requires the Userflow MCP connector.\n---\n\n# Userflow Banner Creator\n\nGuide the user from a rough idea (or a linked doc/ticket) to a finished, ready-to-publish Userflow\n**banner** — a bar embedded directly into their app's page. This is a **conversational, step-by-step**\nskill: move through the phases in order and **pause at each ✋ checkpoint**. Never create or publish\nwithout an explicit yes.\n\nThe core habit, same as any content-creation flow: **create is not publish**. `create_flow` saves an\nunpublished draft and returns a Builder link; nothing is live until the user confirms and you call\n`set_flow_publication`.\n\n## How banners differ from announcements\n\nBanners embed **directly into the page DOM**, so — unlike announcements — there is **no notification\nlevel** (silent/badge/boosted) and **no Resource Center dependency**. The banner-specific choices are\n**placement** (where it sits) and **behavior** (sticky / overlay / animate). Copy should be **short —\none line is ideal**.\n\n## Before you start\n\n1. Confirm the **Userflow MCP** is connected. If not, say so and stop.\n2. Resolve the **environment** via `describe_session` (e.g. Production vs. Staging). One env → use it;\n   several → ask which. The banner *draft* is account-level, but you'll need the env for the\n   live-banner priority check and for publishing.\n\n---\n\n## Phase 1 — Gather the context\n\nAsk for the source material, offering three ways:\n\n> \"What's the banner for? Give me a short summary, share a link to a doc or ticket with the context\n> (Notion, Jira, a Google Doc, etc.), or paste the content in.\"\n\nIf they share a **link**, use the matching connected app for private content (for example Notion,\nAtlassian for Jira/Confluence, or Google Drive), use browser or web access for a public page, and read\nfiles attached to the current task directly. If the required app is unavailable or access fails, say\nso and ask them to paste the relevant text. If they give a summary or pasted text, work from that.\n\nBanners carry one short message and maybe one action — pull out the single thing users need to know\nand any link/action they should take.\n\n---\n\n## Phase 2 — Draft and refine the copy\n\nWrite **short** banner copy — ideally one line. Lead with the point; cut everything else. If a\nbundled Userflow brand-copy skill is available, follow its voice rules; otherwise use concise,\ndirect, friendly product copy and preserve any tone requirements the user provides.\n\n✋ Show the draft (plain, readable — not JSON) and ask:\n\n> \"Here's the banner text. Good? Want changes to tone, length, or wording? And should it have a\n> **button** — e.g. 'Learn more' linking somewhere, or a 'Dismiss' button?\"\n\nIf they want a CTA, capture the button text and its action — most commonly **navigate** to a URL, but\nalso **start a flow**, **dismiss** the banner, track an event, or set an attribute. See\n`references/mcp-reference.md` → *Buttons*. Iterate until the copy and button are right.\n\n---\n\n## Phase 3 — Placement and behavior\n\nBanners always need a placement. **Always ask** (offer it as a dropdown of choices):\n\n- **Top of page** → `embed_mode: \"body_first\"`\n- **Bottom of page** → `embed_mode: \"body_last\"`\n- **Anchor to a specific element** → hand off to the Builder (see below)\n\n**Element-anchored placement is finished in the Builder, not here.** The MCP can't click to pick an\nelement on a live page, so if the user chooses element-anchored, create the draft with the copy and\nsettings you have and tell them to open the Builder link to position it against the element. Don't ask\nfor CSS selectors. Top/Bottom of page need no selector and work fully via MCP.\n\nThen a couple of quick behavior questions (offer sensible defaults):\n\n- **Sticky?** Stick to the top/bottom of the viewport while scrolling, or scroll away with the page\n  (`sticky`, default false).\n- **Overlay or push?** Float over app content, or push the app's content down (`overlay`, default\n  false = push).\n- Optional: animate on appear (`animate`, default true); allow users to dismiss with an X.\n\n---\n\n## Phase 4 — Audience targeting\n\n> \"Should this show to **everyone**, or only a **specific set of users**?\"\n\nIf targeted, ask them to describe the audience in plain language, then build a `filter_condition` from\nthe predicate DSL — **resolve real attribute FQNs / event names first via `list_attribute_definitions`\n/ `list_event_definitions`; never invent them** — and **echo the interpreted audience back in plain\nEnglish** for a ✋ nod. See `references/mcp-reference.md` → *Targeting*. If everyone, leave\n`filter_condition` unset.\n\n**Priority — only if other live banners exist.** Check `list_flows` (`types: \"banner\"`,\n`state: \"published\"`, the chosen `env_id`). Only if that returns one or more, raise priority: at any\nmoment a user sees just one banner, and the highest-priority eligible one wins. Ask whether this banner\nshould take precedence over the existing one(s), set `priority` (1–5) accordingly, and note the final\nordering is visible in the Builder. If there are no other live banners, don't bring priority up at all.\n\n---\n\n## Phase 5 — Confirmation card\n\n✋ Show a **readable confirmation card** (never raw predicate/draft JSON) and get a clear go-ahead.\nUse an interactive confirmation card if that capability is available; otherwise use a clean text\ntable. Include:\n\n- **Copy** and the **button** (label + what it does), if any\n- **Placement** in plain words (\"Top of page\", or \"Anchored — finish in Builder\")\n- **Behavior** — sticky / overlay / animate as on or off\n- **Audience** — plain-English (\"Everyone\" or \"Active EU companies\")\n- **Priority**, only if it came up\n- **Environment**\n\nThen: \"Ready for me to create this banner as a draft?\" — wait for the yes.\n\n---\n\n## Phase 6 — Create the draft\n\nOn confirmation, call `create_flow` with `type: \"banner\"` and the `draft.banner` payload (content as a\n**rich2** document, buttons, `embed_mode`, `sticky`, `overlay`, `animate`, layout), plus\n`filter_condition` if targeted and `priority` if it came up. See `references/mcp-reference.md` →\n*Creating the banner* for the exact shape.\n\n`create_flow` returns a **Builder URL**. Give it to the user:\n\n> \"Done — here's your banner draft: [link]. Saved, not live yet.\"\n\nIf placement was element-anchored, remind them to set the anchor position in the Builder before\npublishing.\n\n---\n\n## Phase 7 — Offer to publish\n\n✋ Never auto-publish.\n\n> \"Want me to publish it now, or review in the Builder first?\"\n\nIf publish, call `set_flow_publication` (`action: \"publish\"`) — a **two-step confirm**: first call\nwithout `confirm`, then again with `confirm: true`, passing the chosen `env_id`. See\n`references/mcp-reference.md` → *Publishing*.\n\n---\n\n## Guardrails\n\n- **Never publish without an explicit yes.** Create (draft) and publish (live) are separate confirmed\n  steps.\n- **Never invent** attribute FQNs, event names, or values — look them up and echo the audience back.\n- **Keep copy short.** A banner is one line, not a paragraph. Push back gently on wall-of-text copy.\n- **Element-anchored → Builder.** Don't fabricate CSS selectors; hand off placement.\n- **No raw JSON in the confirmation** — a readable card is what catches mistakes.\n- Keep it conversational — a helpful teammate, not a form.\n"
}