{"id":73353,"plugin_id":"plugin_asdk_app_6ad08697e96481918db6f5c5271915f3","kind":"skill","collection_source":"plugin_package","comparison_source":null,"observed_at":"2026-10-31T01:21:28.346Z","digest":"49cd39b2b80599ca2ec6193a9566bf14149bedebad1c0ee755b3f468942ed377","against":null,"payload":{"description":"Immediately acknowledge requests for Marble widget ideas, then show four personalized sample previews and build the one the user chooses.","included_files":[],"name":"onboarding","skill_md_contents":"---\nname: onboarding\ndescription: Immediately acknowledge requests for Marble widget ideas, then show four personalized sample previews and build the one the user chooses.\n---\n\n# Set up Marble\n\nAs soon as the user asks for onboarding or widget recommendations, send one\nshort, visible acknowledgment before doing any other work. For example:\n\"I'm putting together some widget ideas for you now.\"\nThe user needs to know their request was received while the previews are being\nprepared. Send this acknowledgment before reviewing conversation context,\nsearching memory, choosing ideas, reading references or schemas, or calling\nany tools. Do not wait for tool results or finished previews to send your first\nvisible response. This is required even when routine progress narration is\notherwise unnecessary. It says work is starting, not that previews are ready.\n\nAfter the initial acknowledgment, read the installed `marble-widgets` skill\nbefore preparing recommendations or calling tools. Follow its guidance\nthroughout onboarding and the selected widget build.\n\nGive the user a useful first glimpse of their dashboard. Use the connected Marble tools and the existing widget\nformats. Do not launch website research, ask for a company website, or turn\nthis into a questionnaire.\n\n1. Use what is actually available in this ChatGPT conversation and memory.\n   If the host offers memory or past-conversation search, consult recent work\n   when useful. Do not invent access to memory or assert personal facts you\n   cannot see. Put one or two ideas about the user's immediate work from the\n   last week first. Use the remaining ideas for important ongoing needs or\n   interests. If little context is available, offer broadly useful starting\n   ideas and invite the user to adjust them, without blocking the previews.\n2. Read `get_widget_formats`. The formats response\n   includes the website's complete `recommendationSchema`, including each\n   supported fictional `sampleResult` shape. Use that schema for the previews;\n   do not retrieve individual canonical format schemas just to show ideas.\n   Choose a presentation supported by `recommendationSchema`, including charts\n   when the sample schema supports them.\n   Give each idea a source with `source: {kind: \"external\", name, domain?}`.\n   Marble uses that domain to look up the logo displayed on the sample widget.\n   Label the platform or service whose data the card displays, following\n   `marble-widgets`'s source-name and logo guidance. For Instagram content,\n   use `name: \"Instagram\", domain: \"instagram.com\"`, even when Apify retrieves it.\n   Choose sources the user's available authorized tools can retrieve, and omit\n   unknown domains. Do not run data tools or call `list_connections` to generate\n   ideas.\n3. Call `show_widget_recommendations` with exactly four distinct `kind=custom`\n   recommendations matching `recommendationSchema`. Include a clear name,\n   a short explanation of its usefulness, self-contained refresh instructions,\n   a named source, and a small fictional `sampleResult`. Use one feed item\n   or calendar event, one or two standalone measurements, or a short chart\n   with at most four points. Keep previews compact. Use example.com for\n   fictional links. Never present sample data as actual account data or as\n   research findings. Do not open drafts, fetch live data or save four widgets.\n   Correct rejected arguments and retry rather than claiming a carousel was\n   shown when the tool failed.\n4. The inline carousel reuses Marble's existing widget previews. Its\n   **Make this widget** button sends the chosen idea back into this chat.\n   Explicitly say they can request anything else they can think of, not just\n   these four ideas. If they share a vague idea, ask focused clarifying\n   questions to work out the widget before building. On selection, immediately\n   acknowledge the build before tool calls, following `marble-widgets`'s\n   acknowledgment guidance. Then use the authorized source tools,\n   read the chosen format's full canonical schema, fetch real data, validate\n   and save that one widget. The fictional sample schema does not replace the\n   live widget format schema. Never save fictional sample data as a live widget.\n5. Stop after the ideas and invitation until the user chooses a widget or\n   describes what they want. After saving, follow the short saved-widget reply\n   below. Keep the existing inline widget visible; it follows the draft through\n   save. Do not call `open_chat_dashboard` automatically or capture a second\n   preview. Open the full dashboard only when the user asks.\n\n## Keep attention on the widgets\n\nThe cards are the explanation. Do not repeat their names, descriptions, sample\nvalues or contents in a numbered list or paragraph beneath them. Do not narrate\nroutine tool calls or say that you started onboarding or loaded four ideas.\nAlways give the initial recommendation acknowledgment above, and the build\nacknowledgment when the user chooses a widget. After that,\ngive progress only when a delay, error or required choice needs explanation.\n\nAfter a successful carousel call, use at most two short sentences:\n\"These previews use example data. Pick **Make this widget**, or tell me another\nwidget you'd like.\"\nThat is the invitation to request anything else they can think of; do not add\na second invitation or explain the build/save process again. If the carousel\nfails, explain the problem instead of claiming previews are visible.\n\nWhen real data is passed to Marble's widget tools, the widget shows a preview\nof that data inline in the chat. For previewing data for a Marble widget, that\ninline widget preview is usually enough. Let it show the data and its saved\npresentation while keeping the accompanying explanation brief.\n\nAfter a successful save, use at most three short sentences:\n- Confirm the widget name was saved, once. Follow `marble-widgets`'s board-only\n  saved-widget wording. Never claim a save succeeded before the tool does.\n- Add one useful detail only if it is not already clear from the card, such as\n  \"Links open the Hacker News discussions.\" Do not list articles, links,\n  measurements, engagement counts or other contents already in the widget.\n- For the first saved widget, explain the control in plain language:\n  \"To update its data, open the widget's **⋮** menu and choose **Refresh now**.\"\n  Do not call it a \"snapshot\" or imply its data updates on its own.\n  Do not mention automatic refresh, disabled schedules or internal refresh\n  policy unless the user asks about them. The menu icon is vertical **⋮**.\n- Follow `marble-widgets`'s dashboard-navigation guidance: retain the inline\n  card's **View in dashboard** control. Keep it as the dashboard entry point\n  without adding a dashboard link to the assistant's reply.\n\nAn optional next step can be one short suggestion, such as \"Want to focus it on\nShow HN launches?\" Omit it if the reply already needs the refresh explanation.\nDo not add a general feature tour, a repeated saved badge, or a second summary.\n\n## Source names and logos\n\nFollow the **Source names and logos** guidance in `marble-widgets` for both\nrecommendation cards and drafts. Source names and domains describe the content\nplatform; retrieval requirements belong in the widget instructions. Omit unknown\ndomains. Do not fetch image files or call `list_connections` just for a logo.\n"},"changes":[],"summary":"First saved snapshot. No earlier version is available for comparison.","summary_kind":"deterministic","summary_metadata":{}}