Update to Windsor.ai

{
  "description": "Guide a new Windsor.ai user through setup, choosing a data source, connecting an account, and getting a first useful report. Use when the user runs plugin setup, asks to get started, or needs help completing their initial connection. Regular reporting and campaign-management requests should use the Windsor skill directly.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 497
    }
  ],
  "name": "get-started",
  "skill_md_contents": "---\nname: get-started\ndescription: Guide a new Windsor.ai user through setup, choosing a data source, connecting an account, and getting a first useful report. Use when the user runs plugin setup, asks to get started, or needs help completing their initial connection. Regular reporting and campaign-management requests should use the Windsor skill directly.\n---\n\n# Get started with Windsor.ai\n\nHelp the user reach their first useful result with their own data. Use the\nWindsor.ai MCP tools already available in the conversation. Follow the user's\nstated goal and language; skip questions they have already answered. Keep each\nmessage short and ask only for the next choice that blocks progress.\n\n## Start from the current connection\n\nCall `get_connectors(include_actions=False, include_options=False)` to discover\nconnected sources and account names. If these optional flags are absent from\nthe live tool schema, omit them. Use returned connector and account IDs, never\ninvent them. An authentication or service error is not an empty account list.\n\n- **Windsor is not authenticated:** use the host's Connect/sign-in action or\n  the connection prompt returned by the tool. Ask the user to finish it and\n  resume afterwards. Do not invent a sign-in URL or keep retrying a 401.\n- **Relevant accounts already exist:** reuse them. With one matching account,\n  continue to the first report. With several, ask which account to use unless\n  the user already selected one or explicitly requested all of them. Show\n  account names, with a shortened ID only when names are missing or duplicated.\n- **No relevant account is connected:** help connect the chosen source below.\n  Do not make a returning user reconnect a working account.\n\nIf the goal or platform is still unknown, ask one short question: what would\nthey like to understand, and on which platform? Offer a few relevant examples,\nsuch as Instagram engagement, Facebook/Meta Ads results, Google Search Console\nSEO, Google Analytics 4 website traffic or Google Ads performance. Accept any\nother supported source; do not present a 350-source catalog or require a form.\nWhen connected sources provide useful choices, offer those first.\n\n## Connect the selected source\n\nBefore requesting a connection link, call\n`get_connectors(include_not_yet_connected=True, include_actions=False,\ninclude_options=False)` to obtain the connector ID from the complete catalog.\nOmit unsupported optional flags. Distinguish organic Instagram from Instagram\nPublic and Meta Ads, Facebook Pages from Facebook Ads, and LinkedIn Pages from\nLinkedIn Ads. Ask a focused question if the user's wording leaves that choice\nunclear; never substitute another connector silently.\n\nCall `get_connector_connect_info` for the discovered ID. Give the returned\n`connect_url` as a labeled link and repeat provider-specific `notes` verbatim\nwhen present. For OAuth, explain that the user authorizes and selects their\naccount in the browser. For manual connections, name the required fields and\nsend the user to that form to enter them. Never ask for passwords, API keys,\ntokens or other secrets in chat. If connect-info is unavailable but\n`get_connector_authorization_url` exists, use its returned URL and notes.\n\nAsk the user to return when finished, then pause. Do not poll while they are\nauthorizing. On their return, call `get_connectors` again to verify the expected\naccount appears. Opening a link or completing provider sign-in alone does not\nprove the connection is ready. If it is still absent, explain the remaining\naccount-selection or save step using the returned guidance. After one recovery\nattempt with no progress, summarize the blocker and offer support; do not loop\nthrough authorization. Cancellation should leave setup paused, without a claim\nof completion. Do not submit a support request unless the user asks.\n\n## Deliver the first report\n\nHonor any report the user already requested, including their account and date\nrange. For an open-ended setup request, start with a small overview for one\nselected account over the last seven complete days (`date_preset=\"last_7d\"`).\nState the chosen range. For a source that only provides current snapshots,\ndescribe the snapshot rather than implying a seven-day trend. If the user only\nwants to connect an account, stop after verifying that connection.\n\n1. Call `get_fields` for the chosen connector before selecting field IDs. Call\n   `get_options` with the selected account to discover valid options and date\n   columns when needed. Match fields and tables to the user's question; do not\n   reuse another connector's IDs or invent unsupported metrics.\n2. Choose a small set of available metrics and a useful dimension. Examples\n   are campaign spend/clicks/conversions for ads; reach/engagement for organic\n   social; clicks/impressions/CTR for Search Console; users/sessions/key events\n   for GA4; and views/watch time for YouTube. These are human descriptions, not\n   literal field IDs. Other sources should use equivalent discovered metrics.\n3. Call `get_data` for the selected account and fields. Supply required\n   per-table date filters from metadata. Keep `force_refresh` off unless the\n   user explicitly needs fresher data. Avoid pulling unrelated accounts or\n   large cross-platform reports during setup.\n4. Return the source, account and period, a compact table of useful results,\n   one factual takeaway and one relevant follow-up the user can ask next.\n   Keep currency and units visible. Use source-defined aggregation; do not\n   sum rates, overlapping unique counts or follower snapshots, mix currencies,\n   or claim trends or causes that the returned data cannot establish.\n\n## Recover without losing the user's goal\n\n- **Pending report:** follow the tool's pending-job guidance, including its\n  poll interval. Continue the same query with unchanged parameters so it does\n  not start another pull. Say the report is being prepared; do not describe a\n  pending or timed-out request as empty data or a failed connection. If the\n  tool directs the user to return later, preserve the query and explain that.\n- **Empty completed report:** distinguish an empty result from zero activity.\n  Check the selected account, field/table and available date range. For the\n  default setup period, try one supported wider window and clearly state it;\n  ask before changing an explicitly requested period. If still empty, report\n  the limitation and suggest the next check. Never fill gaps with sample data.\n- **Permission, quota or provider error:** explain the actual returned blocker\n  and a relevant next step. A status, upgrade or error row is not a metric.\n  Do not present a pricing pitch or label an unavailable report successful.\n- **Existing conversation:** continue its selected platform and account. Setup\n  must not reset the task, override a refusal, or require steps already done.\n\nSetup is for connection and an initial read. It does not itself authorize\ncampaign changes, posting, uploads, recurring exports or outbound messages. If\nthe user explicitly asks for one of those tasks, use the Windsor workflow and\nits existing confirmation requirements; do not execute it merely to demonstrate\na feature. Never claim the first report is ready before real data is returned.\n"
}