Update to Butter

{
  "name": "butter-product-launch",
  "description": "Launch a campaign for the newest product. Use when the user is launching a new product and needs a set of launch creative across surfaces.",
  "included_files": [],
  "skill_md_contents": "---\nname: butter-product-launch\ndescription: Launch a campaign for the newest product. Use when the user is launching a new product and needs a set of launch creative across surfaces.\n---\n\n# Product Launch\n\nLaunch a campaign for the newest product.\n\n## Before you start\n\nAnything the user has already told you, or that the sources under \"Gather first\" already cover, is known — do not ask for it again; if nothing is missing, go straight to \"Gather first\". Otherwise ask for what is still missing with `askQuestions`, once, before gathering. It runs inside a session, so call `startSession` first, as in step 1 of \"Building each video\", and pass its `sessionId`; then pass only the questions below that are still unknown, and add your own for anything else you cannot build without — give an option shaped { \"label\": \"…\", \"input\": \"url\" } when the answer is a link, { \"label\": \"…\", \"input\": \"upload\" } when the user should provide a file, and leave out options for free text. Then end your turn — the answers arrive as the user's next message, starting \"Answers:\". Do not ask them again in chat, with three exceptions, each at most once: when an answer says the user will upload a file in chat, ask them in plain chat to attach it; when a shared ad link cannot be read, ask for a screenshot; and when something you cannot build without was skipped, ask for it. Upload any attached file with `uploadSessionAsset` into that session. For any other skipped question, use your best judgment: its recommended answer if it has one, otherwise what you can infer from the sources you have.\n\n```json\n{\"questions\":[{\"title\":\"What should I use as a visual reference?\",\"options\":[{\"label\":\"Match my website's branding (recommended)\",\"input\":\"url\"},{\"label\":\"Match an ad I'll share\",\"input\":\"url\"},{\"label\":\"Upload an ad in chat\",\"input\":\"upload\"}]},{\"title\":\"Where should the assets, product details and copy come from?\",\"options\":[\"Use my website (recommended)\",{\"label\":\"Upload my images in chat\",\"input\":\"upload\"},\"Use a connected source\"]},{\"title\":\"How long should the video be?\",\"options\":[\"15 seconds (recommended)\",\"6 seconds\",\"30 seconds\"]}]}\n```\n\n## Gather first\n\nButter does not supply this data — it comes from the connectors already available to you, or from\nwhat the user provides.\n\n- The new product's details and images, from a store connector (Shopify…) or the product page\n- Brand assets\n\nIf a source is unavailable, say so and ask the user for it rather than inventing figures. Never\ninvent an offer, a price, a discount, or a performance claim the user did not give you.\n\n## Hold constant\n\nThe brand system established by existing creative\n\n## Vary\n\nFormat and message per surface — paid, social, launch\n\n## How many\n\n3\n\n## Format\n\nOne vertical, one square, one landscape\n\n## Building each video\n\nButter turns HTML + CSS into an editable Butter project.\n\n**Every Butter tool takes a `userPrompt`, and every call must carry one.** It is the user's latest\nmessage word for word — what they typed, never your summary of it and never your own reasoning. On\n`startSession` that is the message that asked for the video in the first place. Leave it out only\nwhen nothing the user said prompted the call.\n\nFor every video this workflow calls for:\n\n1. Call `startSession`, unless you already opened one for `askQuestions` that no video is built in\n   yet — build this video there instead. If this chat has already started a Butter session, ended or not, pass the\n   `sessionId` of the most recent one as `previousSessionId` so the sessions of one conversation\n   link up; leave it out only for the first. Pass `goal`: the outcome the user wants the video to\n   achieve, in one sentence, inferred from their request. It returns a `sessionId`, `userPreferences`\n   and the HTML contract. **The contract is authoritative** — follow it exactly, and re-read it rather\n   than relying on memory. `userPreferences` is what earlier sessions learned about how this user likes their videos made, one preference per entry. Treat them as already known: follow them, and do not ask about what they settle, unless the user now asks for something different. Keep track as you work: add a preference the user states or their reactions reveal, reword or remove one they contradict, and keep the rest. Record only how they like the work done (format, length, pacing, tone, style), never personal details about them. Pass only what changed as `userPreferenceChanges` on endSession, never the whole list: `added` for new preferences, `removed` for ones to drop, and `updated` as `{ old, new }` pairs for rewordings.\n2. Upload **every** image and video the video will use with `uploadSessionAsset` before it\n   goes in the page, including any you add while iterating. The page uses the urls it returns, never\n   the original links: the page runs on them, and `endSession` rejects any other url. Upload\n   each file **once**: an asset used more than once, such as the logo in every variant, keeps the url\n   from its first upload in every video and session that uses it. Each upload is a public https link, or a file under 2MB; for a larger local file, ask for a link instead.\n3. Write ONE self-contained HTML document that plays itself: a single timeline, elements positioned\n   in time with `animation-delay` measured from the start of the whole video, and\n   `animation-fill-mode: both` on every animation. CSS motion is unrestricted and read back\n   automatically. The video is silent: add no music, sound effects or voiceover. Anything visual a\n   script drives is invisible to the extractor, so its timing has to be declared by hand in the\n   manifest. Never show the user the HTML or anything rendered from it. Do not make it into an artifact, a canvas, a widget or a file, do not paste it into your reply, do not open it in a browser tab, window or side panel the user can see, and do not share a preview url. The user sees the video only as the Butter project link endSession returns.\n4. Call `submitSessionVersion` with the `sessionId` and the html. It returns lint findings.\n5. Fix every **blocking** finding and resubmit — a version with blocking findings cannot be built.\n   Warnings are safe to ship but cost editability, so prefer fixing them.\n6. Do not ask the user whether they are happy with the video. As soon as the version you are shipping has no blocking findings, call\n   `prepareEndSession` with the session id and its version id. It returns the instructions for\n   measuring that version into a manifest: follow them, then call `endSession` with the session id,\n   the version id, that manifest, `estimatedRating`: your 1 to 10\n   estimate of how successful the session was, judged from how the user reacted to the projects\n   already built in this chat and how many rounds of changes it took, and `userPreferenceChanges`:\n   the preferences you `added`, `removed` or `updated`. `endSession` cannot be called\n   until `prepareEndSession` has been. Neither waits for the user's approval.\n7. A successful `endSession` also ends the session for good: the build-session tools refuse it\n   from then on, and only `repairProject` and `askNextSteps` still take its ids. Whatever comes\n   next starts a session of its own — the asset urls already uploaded stay valid there.\n8. `endSession` answers with only the ids: call `repairProject` next with the same ids, before\n   telling the user anything. It checks what did not survive conversion. When nothing needs\n   repair it routes you to `askNextSteps`; when something does it lists the repairs — make\n   ONLY those by driving the editor, then finish on `askNextSteps` with the same ids and\n   `repaired`: a line on what was put back. Do not offer the repairs or ask permission.\n9. The build report lives in `askNextSteps`.\n   Never tell the user the project is open — the card gives them the link.\n   Say your one line about the build first, then call `askNextSteps` with those ids as your LAST action\n   and end the turn — no text after it: the card it renders carries the link, the report and\n   the suggested next steps (Edit this project, Make another version, or Adapt the format). They are suggestions, not\n   steps — the user may simply be done; wait for their answer rather than picking one. Edits to the built project go through `startEditSession`. A variant begins with\n   `describeProject` — the project as it is NOW, studio edits included, custom blocks named as\n   opaque references — then a fresh `startSession` to re-author it, or `cloneProject` +\n   `startEditSession` on the clone when the changes are small (a clone keeps custom blocks\n   verbatim; a rebuilt variant cannot). Some answers need detail the session cannot start without. Collect it with ONE askQuestions follow-up call — one question per missing detail — and only then start the session:\n  - \"Add an end card\": what the end card should include\n  - \"Add background music\": whether to upload a file, generate it, or choose from stock\n  - \"Add sound effects\": whether to upload a file, generate it, or choose from stock\n  - \"Add a voice over\": whether to upload a file, generate it, or choose from stock\n  - \"New layout\": which layout, with options tailored to this project\n  - \"Different visual style\": which style, with options tailored to this project\nAny other answer naming a direction without its detail gets the same treatment, its options tailored to this project.\n\n## Handoff\n\nOne session per surface\n"
}