← UserflowCONTENT HISTORY

Update to Userflow

Snapshot Sep 30, 2026 · 22:56 UTC · version 4.0.0

Collection source: not recorded for this historical snapshot.

WHAT CHANGED · RULE-BASED ANALYSIS

First saved snapshot

No earlier snapshot is available to establish a change.

Compare saved observations

Download comparison JSON
Full technical diff · 0 changed fields
Full snapshot data
{
  "name": "userflow-announcement-creator",
  "description": "Create an in-app announcement in Userflow through a guided, conversational flow — gather context (a short summary, OR a linked doc/ticket via a connected MCP or Cowork, OR pasted content), draft and refine the copy with the user, set the notification level (silent / badge / boosted → pop-out, modal, or notification), optionally target specific users, show a confirmation card, create the unpublished draft via the Userflow MCP, hand back the Builder link, and offer to publish. Use this whenever a user with the Userflow MCP connected wants to \"create an announcement\", \"announce a feature / update / release / fix\", \"post an in-app announcement\", \"draft an announcement\", \"let users know about X in Userflow\", or turn a release note / changelog entry / Jira ticket / Notion doc into a Userflow announcement. Requires the Userflow MCP connector.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 232
    },
    {
      "relative_path": "references/mcp-reference.md",
      "size_in_bytes": 6229
    }
  ],
  "skill_md_contents": "---\nname: userflow-announcement-creator\ndescription: Create an in-app announcement in Userflow through a guided, conversational flow — gather context (a short summary, OR a linked doc/ticket via a connected MCP or Cowork, OR pasted content), draft and refine the copy with the user, set the notification level (silent / badge / boosted → pop-out, modal, or notification), optionally target specific users, show a confirmation card, create the unpublished draft via the Userflow MCP, hand back the Builder link, and offer to publish. Use this whenever a user with the Userflow MCP connected wants to \"create an announcement\", \"announce a feature / update / release / fix\", \"post an in-app announcement\", \"draft an announcement\", \"let users know about X in Userflow\", or turn a release note / changelog entry / Jira ticket / Notion doc into a Userflow announcement. Requires the Userflow MCP connector.\n---\n\n# Userflow Announcement Creator\n\nGuide the user from a rough idea (or a linked doc/ticket) to a finished, ready-to-publish\nUserflow announcement. This is a **conversational, step-by-step** skill: move through the phases\nbelow in order, and **pause for the user at each ✋ checkpoint** — never barrel ahead and create or\npublish anything without an explicit yes.\n\nThe single most important habit: **create is not publish**. `create_flow` only saves an unpublished\ndraft and returns a Builder link. Nothing is live until the user confirms and you call\n`set_flow_publication`. When in doubt, do less and ask.\n\n## Before you start\n\n1. Confirm the **Userflow MCP** is connected (its tools are available). If not, tell the user this\n   skill needs the Userflow connector and stop.\n2. Resolve the **environment**. Call `describe_session` to list environments. If there's exactly\n   one, use it. If there are several (e.g. production vs. a test env), ask which one this\n   announcement is for, and pass that `env_id` on every subsequent Userflow call that accepts it.\n   Default to the user's usual working environment if they've made it clear in conversation.\n\nDon't over-explain the plumbing — a brief \"Which environment — production?\" is enough.\n\n---\n\n## Phase 1 — Gather the context\n\nAsk the user for the source material, offering three ways to provide it:\n\n> \"What's this announcement about? You can give me a short summary, share a link to a doc or ticket\n> that has the context (Notion, Jira, a Google Doc, etc.), or just paste the content in.\"\n\n**If they share a link**, fetch it with the matching connected tool — Notion for a Notion page,\nthe Atlassian tools for a Jira issue or Confluence page, Google Drive for a Doc, Intercom, etc., or\n`web_fetch` for a public URL. In Cowork, read an attached/linked file directly. If you can't access\nit (no connector, permissioned, returns nothing), say so plainly and ask them to paste the relevant\npart instead — don't guess at the contents.\n\n**If they give a summary or paste text**, work from that.\n\nPull out what an announcement needs: what changed, who it's for, why it matters, and any link or\naction users should take. If something important is missing (e.g. there's no obvious user benefit),\nask one short follow-up rather than inventing it.\n\n---\n\n## Phase 2 — Draft and refine the copy\n\nWrite the announcement as a **title** plus a short **body**. Keep it clear, specific, and benefit-led\n— lead with what the user gets, not internal jargon. If the `userflow-brand-copy` skill is\navailable, follow its voice rules; otherwise default to concise, friendly, plain language.\n\n✋ **Show the draft and get a read on it.** Present the title and body in the chat (plain, readable —\nnot raw JSON) and ask:\n\n> \"Here's a first draft. Does this capture it? Want any changes to **tone**, **length**, or\n> **messaging**?\"\n\nIterate until the user is happy. Small, fast loops beat one giant rewrite. Only move on once they've\nconfirmed the copy is good.\n\n> Note: image handling is intentionally out of scope for this skill. If the user asks for an image,\n> tell them they can add it in the Builder after the draft is created, and continue.\n\n---\n\n## Phase 3 — Delivery settings\n\nOnly once the copy is finalized, gather the delivery details. Ask these as a short, natural\nsequence — one topic at a time, not a wall of questions.\n\n### 3a. Audience targeting\n\n> \"Should this go to **everyone**, or only a **specific set of users**?\"\n\nIf they want to target, ask them to describe the audience in plain language (\"paid plans only\",\n\"companies on the EU region\", \"users who haven't completed onboarding\"). Then translate it into a\n`filter_condition` using the predicate DSL:\n\n- Call `list_attribute_definitions` (and `list_event_definitions` / `list_segments` as needed) to\n  find the **real** attribute FQNs, event names, and segment IDs — never invent them.\n- Build predicates per `references/mcp-reference.md` → *Targeting*.\n- **Echo the interpreted audience back in plain English** and get a ✋ nod before treating it as\n  final. Data-type mismatches (string `\"true\"` vs boolean `true`) silently break targeting, so it's\n  worth confirming.\n\nIf they say everyone, leave `filter_condition` unset.\n\n### 3b. Notification level (post type)\n\n> \"How prominent should it be — **Silent**, **Badge**, or **Boosted**? If boosted: **Pop-out**,\n> **Modal**, or **Notification**?\"\n\nMap their answer to the `level` value (see the table in `references/mcp-reference.md`):\n\n| User says | `level` |\n|-----------|---------|\n| Silent | `silent` |\n| Badge (default) | `badge` |\n| Boosted → Pop-out | `popout` |\n| Boosted → Modal | `modal` |\n| Boosted → Notification / Toast | `toast` |\n\nBriefly explain any option the user seems unsure about (Badge = quiet unread counter; Boosted =\nproactively pops up).\n\n### 3c. Resource Center readiness (informational — never blocks)\n\nEvery announcement, **even Modal and Toast**, only actually displays if the account has a\n**published Resource Center that contains an Announcements block**. Do a quick check with\n`list_flows` (`types: \"resource_center\"`, `state: \"published\"`). If none is published, mention it as\na heads-up so the announcement doesn't quietly get zero views — but **do not block**; let the user\nproceed if they want:\n\n> \"Heads-up: I don't see a published Resource Center with an Announcements block, which is what\n> actually surfaces announcements to users. You can still create this now and sort that out\n> separately — just flagging it.\"\n\nKeep it to a single informational line. Don't nag or re-raise it.\n\n---\n\n## Phase 4 — Confirmation card\n\n✋ Before creating anything, show a **confirmation card** summarizing the whole announcement, and ask\nfor a clear go-ahead.\n\nRender it with the visualizer (`visualize:show_widget`) as a compact card if available — otherwise a\ntidy formatted summary in chat is fine. Include:\n\n- **Title** and a short **body preview**\n- **Notification level** (in the user's words, e.g. \"Boosted — Modal\")\n- **Audience** (plain-English, e.g. \"Paid plans only\" or \"Everyone\")\n- **Environment**\n- The Resource Center heads-up, if it applied\n\nThen ask:\n\n> \"Ready for me to create this as a draft in Userflow?\"\n\nWait for the yes.\n\n---\n\n## Phase 5 — Create the draft\n\nOn confirmation, create the announcement with `create_flow`:\n\n- `name`: the announcement's internal name (usually the title)\n- `type`: `\"announcement\"`\n- `draft.announcement`: `{ title, content (rich2), level }`\n- `filter_condition`: only if the user targeted an audience\n- `env_id`: the resolved environment\n\nSee `references/mcp-reference.md` → *Creating the announcement* for the exact JSON shape and a\ncopy-ready template. The body must be a **rich2** document, not an HTML string.\n\n`create_flow` returns a **Builder URL**. Give it to the user:\n\n> \"Done — here's your announcement draft: [link]. It's saved but not live yet.\"\n\n---\n\n## Phase 6 — Offer to publish\n\n✋ Publishing is a live, user-facing action — always ask, never auto-publish.\n\n> \"Want me to publish it now, or would you rather review it in the Builder first?\"\n\nIf they say publish, call `set_flow_publication` with `action: \"publish\"`. It uses a **two-step\nconfirm**: the first call (without `confirm: true`) returns a confirmation payload; call again with\n`confirm: true` to apply. Pass the same `env_id`. See `references/mcp-reference.md` → *Publishing*.\n\nIf a Resource Center wasn't published (from Phase 3c), gently remind them once here that the\nannouncement may not display until that's set up.\n\nIf they'd rather review first, leave it as a draft and point them to the Builder link. Done.\n\n---\n\n## Guardrails\n\n- **Never publish without an explicit yes.** Creating a draft is safe and reversible; publishing is\n  live. Keep them as two separate, confirmed steps.\n- **Never invent** attribute FQNs, event names, segment IDs, or plan names — look them up.\n- **Don't skip checkpoints.** The value of this skill is the pause-and-confirm rhythm; a great draft\n  published to the wrong audience is worse than a slightly slower flow.\n- **Stay in scope.** Copy + level + audience + create + publish. Changelog/distribution and image\n  uploads are intentionally out of scope; if asked, note they can be handled in the Builder and move on.\n- Keep the conversation light and human — you're a helpful teammate walking them through it, not a form.\n"
}

SHA-256: 30178eae853946f6ec8a10af9f4818eaf9669bfd13d563f18f78e43fa7765511