Update to Userflow

{
  "name": "userflow-segment-creator",
  "description": "Create a condition (filter-based) segment in Userflow through a guided, conversational flow — pick user vs. company, describe the audience in plain language, translate it into real attribute/event predicates (looked up, never invented), show the conditions in a simple inline card for confirmation, name it, and create it via the Userflow MCP. Use this whenever a user with the Userflow MCP connected wants to \"create a segment\", \"build an audience\", \"make a user/company segment\", \"segment users who…\", \"define a group of users/companies by conditions\", or filter their audience by attributes or behavior. Requires the Userflow MCP connector. Note — the MCP only creates condition segments; manual/list (CSV-uploaded) segments are not supported and must be imported from the Userflow dashboard.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 528
    },
    {
      "relative_path": "references/mcp-reference.md",
      "size_in_bytes": 4575
    }
  ],
  "skill_md_contents": "---\nname: userflow-segment-creator\ndescription: Create a condition (filter-based) segment in Userflow through a guided, conversational flow — pick user vs. company, describe the audience in plain language, translate it into real attribute/event predicates (looked up, never invented), show the conditions in a simple inline card for confirmation, name it, and create it via the Userflow MCP. Use this whenever a user with the Userflow MCP connected wants to \"create a segment\", \"build an audience\", \"make a user/company segment\", \"segment users who…\", \"define a group of users/companies by conditions\", or filter their audience by attributes or behavior. Requires the Userflow MCP connector. Note — the MCP only creates condition segments; manual/list (CSV-uploaded) segments are not supported and must be imported from the Userflow dashboard.\n---\n\n# Userflow Segment Creator\n\nGuide the user from a plain-language audience description to a live **condition segment** in Userflow.\nThis is a **conversational, step-by-step** skill: move through the phases in order and **pause at each\n✋ checkpoint**. Never create the segment until the user has seen the conditions and said yes.\n\n## Scope (read first)\n\nThe Userflow MCP's `create_or_update_segment` creates **condition (filter) segments only** — segments\ndefined by attribute/event rules that evaluate membership automatically. It **cannot** create\n**manual/list segments** (a fixed set of users uploaded from a file); there is no MCP tool to import\nmembers or set attributes. If the user wants a manual/CSV-based segment, say so plainly and point them\nto the Userflow dashboard's CSV import (or the REST Identify API) — then offer to help with a condition\nsegment instead. Don't try to fake it with a giant list of OR'd equals; that hits the nesting budget\nand isn't what they want.\n\n## Before you start\n\nConfirm the **Userflow MCP** is connected (its tools are available). If not, tell the user this skill\nneeds the Userflow connector and stop. Segments are account-level, so no environment needs to be\nchosen to create one (an optional match-count preview later is per-environment — handle that then).\n\n---\n\n## Phase 1 — User or company segment?\n\nAsk up front, because it decides which attributes are even valid:\n\n> \"Is this a **user** segment or a **company** segment?\"\n\nThis sets `subject_type` (`\"user\"` or `\"company\"`) and constrains predicates — see\n`references/mcp-reference.md` → *Subject-type scoping*. In short: a **company** segment can only use\ncompany attributes (`group/…`); a **user** segment can use user attributes, company attributes, and\ncompany-membership attributes.\n\n---\n\n## Phase 2 — Describe the conditions\n\nAsk the user to describe the audience in plain language:\n\n> \"Describe who should be in it — e.g. 'companies on an active subscription in the EU', or 'users who\n> haven't completed onboarding and were last seen over 30 days ago'.\"\n\nThen translate it into predicates. **Resolve real identifiers first — never invent them:**\n\n- `list_attribute_definitions` (scope matching the subject type) → exact attribute FQNs and their\n  `data_type`. Company attributes use the `group/` prefix.\n- `list_event_definitions` → valid `event_name` values, if the description involves behavior.\n- Build the predicate array per `references/mcp-reference.md` → *Building the conditions*.\n\nTwo things that silently break segments, so get them right:\n- **Data types.** String `\"true\"` ≠ boolean `true`; a number stored as text won't match a numeric\n  comparison. Match the attribute's real `data_type`.\n- **No nested segment references.** `create_or_update_segment` rejects `type: \"segment\"` predicates\n  anywhere in the tree. If the user says \"everyone in segment X plus …\", you can't nest X — expand the\n  intent into attribute/event rules, or tell them that part can't be combined this way.\n\nIf the description is ambiguous (\"active\" = subscribed, or recently seen?), ask one short clarifying\nquestion rather than guessing.\n\n---\n\n## Phase 3 — Show the conditions and confirm\n\n✋ Render the conditions as a **simple, human-readable card** so the user can eyeball them before\nanything is created. Use an interactive card if that capability is available; otherwise use a clean\ntext table. The card should show:\n\n- **Subject type** (User segment / Company segment)\n- A **plain-English restatement** (\"Companies with an active subscription AND region = EU\")\n- The **conditions in readable form** — one row per rule as **Field · Operator · Value**, using the\n  attribute's friendly **display name** (e.g. \"Subscription State\", \"Page Viewed\"), a plain operator\n  (\"is\", \"is not\", \"fewer than\", \"more than\", \"in the last 30 days\"), and the actual value — grouped\n  by AND / OR. For event rules, spell out the count, window, and actor in words (e.g. \"fewer than 10\n  times, across all team members, in the last 30 days\").\n\n**Do not show raw predicate JSON to the user.** The JSON is what you send to the tool, not what the\nuser reviews — a table of Field / Operator / Value is far easier to sanity-check and is what catches\nwrong data types or values. Keep the JSON to yourself.\n\nThen ask:\n\n> \"Does this match who you have in mind? I can adjust any rule.\"\n\nIterate until they're happy. Small edits are cheap — re-render the card each time.\n\n**Optional match preview.** Offering a rough count helps them trust the filter. If they want it, run a\nread-only `list_users` (or `list_companies`) with the same predicates in their chosen environment\n(default Production) and report the approximate number of matches. Keep it optional and non-blocking —\nskip it if they'd rather just proceed.\n\n---\n\n## Phase 4 — Name it\n\nOnce the conditions are confirmed:\n\n> \"What should I name this segment?\"\n\nSuggest a descriptive default from the conditions if they're unsure (e.g. \"Active EU companies\").\n\n---\n\n## Phase 5 — Confirm and create\n\n✋ One final check before writing:\n\n> \"Ready for me to create the **[User/Company] segment '[name]'** with these conditions?\"\n\nOn yes, call `create_or_update_segment` with `subject_type`, `name`, and `predicates` (omit\n`segment_id` to create new). See `references/mcp-reference.md` → *Creating the segment*.\n\nReport back the created segment (name + id) and that it's now live in their segment list, evaluating\nmembership automatically. Because it's condition-based, membership updates on its own as users/companies\nchange — no manual upkeep.\n\n---\n\n## Guardrails\n\n- **Never invent** attribute FQNs, event names, or values — look them up, and echo the audience back in\n  plain English before creating.\n- **Respect subject-type scoping** — don't put user-scoped attributes on a company segment.\n- **No nested segment predicates** — attribute / event / not_event / clauses only.\n- **Condition segments only** — if they need a manual/list segment, point them to the dashboard importer\n  rather than forcing it.\n- **Don't skip the confirmation card.** A segment with a subtly wrong data type matches the wrong people\n  (or no one); the eyeball step is the whole point.\n- Keep it conversational — you're walking a teammate through it, not making them fill in a form.\n"
}