Update to Beste

{
  "description": "Build a new website on Beste straight from a brief, without asking about looks, colors or images: create it, open the live preview, fill the sections, then dress and publish it. Use when the person wants a new site, landing page or homepage made with Beste.",
  "included_files": [],
  "name": "new-site",
  "skill_md_contents": "---\nname: new-site\ndescription: \"Build a new website on Beste straight from a brief, without asking about looks, colors or images: create it, open the live preview, fill the sections, then dress and publish it. Use when the person wants a new site, landing page or homepage made with Beste.\"\n---\n\nBuild a Beste site\n\n## Start building, not asking\n\nA brief is enough. If the person has already said what the business is, even in\none line, you have everything you need: build now, with no question first and\nnone during the build. Every question is a pause they did not ask for, and a\nsite on screen answers more than any question would.\n\nOnly if there is no brief at all, say what the site is for in one message, five\nlines, warm, no jargon, along these lines, in your own words:\n\n    **Let's make your site.**\n\n    Tell me about it in your own words: what you do, what it is called, who it\n    is for. Anything real helps, years, cities, prices, a phone number, names.\n\n    **The more you write, the better the site.** Then I build it straight away.\n\nThen stop and wait for that one answer. It is the only question you ever ask.\n\n### What you decide yourself\n\nEverything else is yours, never a question, and never a list of options with a\nrecommendation in it:\n\n- **The name**: from the brief. No name given? The short name of what they do,\n  which they can change in a word.\n- **The language**: the one the brief names, otherwise the one they write in.\n- **The look**: from list_looks, the one whose description matches the feel of\n  the brief; otherwise Altair. People cannot judge a type scale or a button\n  style by a name, and asking only confuses them. Do not mention the choice.\n- **The colors**: from list_themes, the one that suits the brief (\"warm amber\n  tones\" means an amber or warm-neutral theme). The same: pick, do not ask.\n- **The pages**: what the brief asks for. A one-page site is one page; otherwise\n  three, home included.\n- **Images**: the placeholders. Generating spends their credits, so it waits for\n  them to ask; offer it once, in the hand-over.\n\nThen create_website with the name and language. It opens the live preview next\nto the conversation in the same call, so the person watches the site take shape\nwhile you build; do not call open_preview for it again. Where the result says\nthe preview did not open, call open_preview once. One line back: the address,\nand that a custom domain can be attached later.\n\n**Sections first, dressing last.** The moment the site exists, put a hero on the\nhome page, before anything else, so the preview never sits empty. Then build\nevery page's sections, navbar and footer. apply_look with the look you picked and\nset_theme with the theme you picked come last, once the pages are built: both\nrestyle every section already on the site, so nothing is lost by waiting, and the\nperson watches content arrive instead of a blank page changing color.\n\nAsked for six pages, or twenty? Build the best three and say the rest follow as\nsoon as they have seen it, in one sentence at the end.\n\nThe server refuses the fourth page until you have handed the site over, and\npublishing on its own does not count as handing over. What counts is finishing:\npublish, show them what they have, and stop. Say the fourth page right after\nthat and it is yours to build immediately, in this same conversation. The limit\nis about them seeing something quickly, not about making them start again.\n\nWhile building: silence, then one line per finished page.\n\n## Build\n\nPages first: a link needs its target to exist before it can be written.\n\nOne shared navbar and one shared footer for the site: set_navbar and set_footer,\nonce each, no pages argument.\n\nThe navbar is written not sticky, and the server keeps it that way however you\nask. Sticky costs a strip of every screen of every page, and nothing in a brief\nsays which way that should go. Leave it; it is one switch in the builder, and a\nreader who wants it will ask.\n\nThe logo is a wordmark, not a legal name: use the short form people actually say.\n\"Hartley Care and Companionship Services\" becomes \"Hartley Care\". Once the navbar\nis set, tell them in one line that they can upload their real logo in the\nbuilder, and give them the link from preview_url. Links between pages are internal links carrying the\npage id from list_pages, never a URL; an external link to \"/about\" is rejected\nand the rejection carries the value to use instead.\n\nA link to a spot on the same page is an anchor link, { type: \"anchor\", sectionId:\n\"<anchor>\" }, and the anchor is a name you give the target section: \"pricing\",\n\"faq\", \"contact\", \"how-it-works\", never its id. Set it with add_section { anchor }\nwhen you add the section, or update_section { anchor } later (links on the page\nfollow a rename). Add the target before the link; a link to an anchor no section\nhas, or to a section by its id, is rejected.\n\nAnything on more than one page is shared too: add_section with shared: true and\npages: \"all\", or share_section for one you already made. Copies drift, and the\nthird page keeps the old phone number.\n\nPer page, per role: search_sections with a plain description, the chosen look's\nlabel as the set argument and the websiteId, get_section_defaults, then add_section changing\nonly what you mean to change. The set is a preference, not a fence: sections\ndrawn for it come first, and when another set has the better layout for this\nrole, take it. It arrives in the site's look like everything else.\n\n### Do not build the same site twice\n\nThe catalog holds 708 sections. The honest failure of a generated site is that\nit uses eight of them, the top hit for every query, so two sites in the same\ntrade come out as the same page with different words in it.\n\nPass websiteId to search_sections. Anything the site already uses comes back\nmarked and sorted to the bottom, and the answer is to take the one above it.\nA section repeated on two pages is a repeat even when the copy differs: the\nreader recognises the shape, not the sentence.\n\nSearch differently per role, too. \"Three services with an icon each\" and\n\"services in a grid\" return the same top hit; describing the page you want\n(\"the moment a carer arrives\", \"prices side by side with what is included\")\nreaches parts of the catalog a category name never will.\n\n### Pieces\n\nA media slot can hold a photo or a **piece**: a small live UI component drawn in\nthe page - a chat thread, a booking confirmation, a chart, a phone frame, a\nreceipt. get_section_defaults tells you which fields of a section accept one.\n\nThere are 315, and the demo payloads use about twenty. So a section that ships\nwith a piece ships the same piece on every site that uses it, and leaving it is\nexactly the sameness worth avoiding. Two rules, both easy:\n\n- The default has a piece: keep it only if it suits the business. Otherwise\n  search_pieces for one that does, or drop to a photo.\n- The default has a photo: a piece is often better, when it can show something\n  true about the work. A care company can show the visit card the family gets;\n  a restaurant, the reservation; a studio, the invoice.\n\nWhichever you use, rewrite its props in the customer's own words. get_piece\nreturns the demo values; a piece left on \"Dr Amelia Frost\" is demo content in\nthe same way filler copy is.\n\n### How much to build\n\n**Three pages, or one when the brief asks for a one-page site. Four sections on\nthe home page, three on every other page.**\nThe navbar and the footer are not sections in this count; they are on every page\nalready.\n\nThese are ceilings, not targets to reach past. A first build is something to look\nat and react to, not a finished site, and a long site is harder to react to than\na short one: the person cannot tell you what to change if they are still\nscrolling.\n\nFour on the home page is enough to say who this is:\n\n  hero, what they do, the proof or the work, a closing call to action\n\nThree on an inner page: a header, the substance, a way to act.\n\nEverything else waits, and the wait is one message long. Once you have handed the\nsite over there are no limits at all: more pages, more depth on a page, a blog,\neach one sentence from them and yours to build on the spot.\n\nFill what you add. search_sections tells you how many items a section holds\n(collections: features 6); a six-slot block with two items filled reads worse\nthan a smaller block would. If the brief lists five services, choose a section\nthat holds five. If it gives one line about the founder, do not stretch it over\nthree sections to look busy.\n\nWrite from the brief, not from the section: a features block with three slots\ndoes not mean the business has three services.\n\nDo not write image URLs. Every photographic slot is filled server-side with one\nof four house placeholders, in rotation, whatever the demo payload carried: eight\nsections from eight different photo shoots is what makes a page read as a\ntemplate even when the words are right. Logos, icons and anything already\nuploaded to the site are left alone.\n\nNever download the site's own media to look at it. list_images gives you the\naddress, the filename, the type and the size of every file, which is what a\nquestion about the library actually needs. Opening them costs a request each and\na real library runs to hundreds.\n\nSo the images on the finished site are deliberately not the real ones. Say that\nin the hand-over, next to the offer to replace them. Generating images spends\ntheir credits, so offer it, do not decide it.\n\n**Once you start building, stop asking.** No questions between create_website\nand the finished site. Someone watching a build does not know whether a question\nis a question or a pause, so they wait, and the thing stalls with everyone\nwaiting for the other.\n\nMissing a fact? Leave that part out and keep going. A section without a phone\nnumber is fine; a section with an invented one is not. Collect what was missing\nand say it at the end, in one short list, next to the finished site.\n\nThe one exception is something that would produce a wrong site rather than a\nthinner one, and that is rare enough that you should assume it is not happening.\n\n## Blog posts\n\n**Not during this build.** No posts, however the brief is worded and however\ndirectly you are asked, including \"and write me three articles\". The server\nrefuses create_post until the site has been handed over, so this is not a\njudgement call. Say it plainly once, at the end, with the offer: the site goes\nlive first, and then a post is one sentence away, in this same conversation.\n\nA blog list section on a page is fine and worth adding when the business will\nblog; it fills itself from real posts the moment there are any.\n\nWhat a post is, for later: not a page. create_post writes one, and it carries a\nsummary, an author, tags and a publish date. A post written as a page is\ninvisible to every listing on the site and cannot be edited in the builder's post\ndrawer, so never reach for create_page for an article.\n\nWrite the article in Markdown and pass it as \"body\": headings, lists, tables,\nquotes, code and links all survive. Do not build a post out of sections.\n\ncreate_author first if the post has a byline. Blog list sections (search_sections,\ncategory Blog List) list the real posts by themselves, so put one on a page and\nleave its \"posts\" list alone.\n\n## Another language\n\nadd_language, then per page: get_translatable_text, translate the strings\nyourself, apply_translation. You are the translator: keep the ids, keep HTML\ntags and placeholders exactly, and write as a native speaker in that industry\nwould, not word for word.\n\nChanging or removing a language is critical. set_default_language and\nremove_language answer first with the impact and a confirmation code and change\nnothing: tell the user every count in it, in their words, and send the code back\nonly after they say yes. Removing the default language needs a new default,\nand only the user picks it; if they did not name one, ask.\n\n## Finish\n\nget_page_markdown on every page, read it as the customer would, fix what still\nreads like sample content, and check the page is the size it should be: four\nsections at home, three inside, navbar and footer not counted, every list filled.\nOver that, cut rather than keep; a page that got long during the build is the one\nthing they cannot fix in a sentence.\n\nThen publish. It returns liveUrl and builderUrl, and those two links are the\nwhole point of the last message: one to look at what they have, one to change it.\n\nHand it over in a single message, laid out. This is the one place to spend a\nlittle on presentation, because it is the only screen they will read twice:\n\n    ╭────────────────────────────────────────────╮\n    │  Hartley Care is live                      │\n    ╰────────────────────────────────────────────╯\n\n    | | |\n    |---|---|\n    | **See it** | http://hartley-care.beste.co |\n    | **Edit it** | http://studio.beste.co/.../home |\n    | **Pages** | Home, Visits, Contact |\n\n    Two things I left out, for want of a fact:\n    - no phone number on the contact page\n    - the founder's name, so the About section speaks for the company instead\n\n    Say the word and I will do any of these now: another page, more on a page\n    you have, real photos, or a blog post.\n\nThe box holds the name and the state, nothing else. The table holds what they\nclick. The gaps are what you could not know, not a list of everything you chose\nnot to build. The last line is an offer, not a menu to read.\n\nKeep the widths sane: the box is drawn to fit its line, not padded to eighty\ncolumns, and links go in the table rather than inside the box where they wrap.\n\n## Publishing\n\nYou publish **once**, at the end of this build, as the hand-over. That publish is\nexpected: it is what makes the links in your last message work.\n\nAfter it, publishing is theirs and never yours again. If they ask for a change in\nthis same session, make it, tell them it is saved to the draft, and stop there.\nDo not publish it. Not because it is small, not because it is obviously an\nimprovement, not because you are confident they will want it: none of those is\nthem asking. The live site is what their customers are reading right now, and a\nchange that appears on it without anyone deciding is a change nobody can trace.\n\nThe server asks you to quote them for exactly this reason. If you cannot say what\nthey said, ask: one line, and wait.\n\nEverything is a draft until publish. Content is per language. Never set colors,\ngradients or shader effects on a section: the theme owns them and the server\nrejects them. The only colour decision is the theme, picked by you at the start.\n\nA background photograph is the exception, because it is a picture rather than a\ncolour scheme: style.colors.backgroundMedia takes enabled, type, src, size,\nposition and an overlay. Turn the overlay on whenever text sits over the image,\nor the headline is unreadable and nobody asked for that. Padding and width are\nyours too: padding.py and padding.containerMaxWidth.\n\n### One look, any section\n\nA site has one look: its type scale, button style, badge look, card borders and\nmotion, written site-wide. apply_look set it from a studio set; get_site\nreports it under style. Every section you add takes it on the\nway in, whichever set it was drawn for, so mixing sets is not a risk to manage:\na Sirius hero above a Polaris feature reads as one page because both wear the\nsite's buttons and badges.\n\n**Sections arrive without a badge.** add_section never writes one, not even one\nyou pass. When the person asks for a badge, add it with update_section.\nA badge above every heading is the pattern that makes a generated site read as\ngenerated. Do not bring badges up or offer to add them.\n\nFonts come with the theme. When the person names a typeface or asks for a\ndifferent feel in the type, set_fonts: a curated pairing from list_fonts by id,\nor body, heading and code fonts by name. Colors stay with the theme either way.\n\nWhen the person wants the look changed, change it where it lives: set_appearance\nwith only the field they named. \"Make the headings smaller\" is typography\ncompact, \"seal buttons\" is buttons, \"no card borders\" is cardBorder off, \"calmer\nanimations\" is sectionAnimation with a slower duration or mediaAnimation with\nscroll none. One call rewrites every section still wearing the old value. Never\nwalk the pages editing sections one by one for a site-wide change, and never\ngive one section a look of its own to satisfy a site-wide wish.\n\nEntrance animations are yours as well, and they belong to their own tools rather\nthan to a style patch: get_animations reads what every section does and carries\nevery type and speed the builder offers, set_animations writes them\nacross a page or the whole site at once. Leave the site's animations as the\nsections ship them unless the person says otherwise.\n"
}