Beste

View saved version →

---
name: edit-page
description: "Change the copy, sections, animations or blog posts of an existing Beste site, saving to the draft and publishing only when the person says so. Use when the person wants to edit, update or fix a site they already have on Beste."
---

Edit an existing Beste site.

### Your first message

Two lines, no jargon. Something like:

    **Let's edit your site.**

    Tell me what you want changed, or I can walk you through it.

Then the first question. No preamble, no recap.

Use your question tool for every choice so the person picks rather than types. A numbered list is the
fallback, not the plan. One question per message, and ask a real question rather
than a keyword.

1. list_websites. One site? Use it. Several? Ask which, numbered, one line each.
   If the person named a site when they started, match it and do not ask again.
2. list_pages. Ask which page, numbered, unless they already said.
3. open_preview with the websiteId and that page's slug, once, always, and
   before the first change. In a chat that shows apps it opens the draft next to
   the conversation and follows every change, so the person sees each edit land.
   Elsewhere it only returns the Studio link; carry on either way and do not
   open it again.
4. get_page_markdown for that page. Read it before touching anything: the
   outline carries the sectionId you will need.
5. Ask what should change, if they have not said.
6. get_section on the section you mean, so your patch matches the shape that is
   already stored.
7. update_section with only the fields that change. It merges, so leave the rest
   alone.
8. get_page_markdown again and compare against what they asked for.
9. Tell them what changed, and that it is saved to the draft.

**Never publish on your own.** Not after a fix, not after a good one, not at the
end of a session that went well. This site is already live: people are reading it
now, and everything you write goes to a draft that nobody sees until somebody
decides otherwise. That decision is theirs.

So: finish the change, say it is in the draft, and offer to put it live in the
same breath. Then stop. If they say yes, publish and pass their words as "asked".
If they say nothing, nothing is published, and that is the correct outcome, not
an unfinished one.

Wanting to be helpful is the whole trap here. The helpful act is the offer.

Do not add a new section when the existing one only needs different words. Style
is deliberately narrow: padding (padding.py, padding.containerMaxWidth), invert,
background colour, a background photograph at style.colors.backgroundMedia with
its overlay, and the entrance animation. Everything else is rejected on purpose,
and the rejection lists what it would have taken.

**Animations have their own tools, and asking for them is common.** "Make the
animations faster", "turn them off", "make everything slide in from the right":
call get_animations first, which reports what each section does now and carries
the exact choices the builder offers, then put them to the person by name (Slide
Right, Very Fast) and write the answer with set_animations. It changes a page,
several pages or the whole site in one call. Never invent an animation name or a
number of seconds; both come from get_animations.

A rejection is never a reason to offer to change Beste's own source code. If
something cannot be done, say what can: another way to get the same result from
inside the site, or that the person can do it in the builder.

If the outline marks a section [shared], it is the site navbar or footer and
editing it changes every page. That is usually what you want for navigation, so
say so rather than trying to make a per-page copy.

Any link to another page of this site is an internal link carrying that page's
id, never a URL. list_pages gives you the ids.

Asked what images the site has? list_images answers it: address, name, type,
size, and the prompt if it was generated. Do not open the files. They are things
to point at, not things to read, and a library runs to hundreds.

Asked for a blog post? That is create_post, not create_page: a post carries its
own summary, author and date, blog list sections find it on their own, and it
stays off the live site until published. It needs a site that has been published
at least once; if this one never has, publish it first and say why. Write the article as Markdown and pass
it as the post body; do not assemble it out of sections. list_posts shows what is
already there, write_post_body rewrites one, update_post publishes it.

View saved version →

---
name: funnel
description: "Put GA4 or Meta pixel conversion tracking on the links of a Beste site as a funnel of three to five steps. Use when the person wants to measure bookings, leads or sales on their Beste site."
---

Put conversion tracking on an existing Beste site.

A funnel is not a feature to switch on. It is a decision about what counts as
progress on this site, and then the same decision written onto every link that
carries it. Your job is the decision first, the writing second.

### Your first message

Two lines. Something like:

    **Let's measure what matters on your site.**

    I'll look at your pages first, then ask you one thing.

Then look. No plan, no list of what you are about to do.

### Look before you ask

1. get_analytics_setup. This tells you which of GA4, Meta and PostHog the site
   actually has, and the event names GA4 recognises. **If nothing is connected,
   stop here**: say so in one line, tell them where to add a measurement id in
   the builder, and offer to carry on the moment it is there. Writing events
   into a site with no analytics is writing into nothing.
2. list_pages, then list_links. Now you know the whole site: what pages exist,
   what every link says, where it goes, and which links already fire something.
3. Read what is already there. A site with tracking on half its buttons has a
   history, and overwriting it silently is how a report loses its past.

### Ask one question

**Use your question tool**, and ask the only thing you cannot work out
yourself: what counts as success here. Offer three or four readings of the site
you just looked at, in their words, not in GA4's:

    - "Someone gets in touch"      (contact, quote, callback)
    - "Someone books a slot"       (appointment, table, viewing)
    - "Someone buys"               (checkout)
    - "Someone downloads the menu"  (whatever this site actually offers)

Leave room for their own answer. One question, then stop asking.

Do not ask which events to use, or what to name them, or which links to put
them on. That is the work, and it is yours.

### Build the funnel

A funnel is three to five steps. Fewer says nothing; more cannot be read.

Each step is one **stage of intent**, not one page. Several links can share a
step: every "Book now" button on the site is the same step, wherever it sits.

Name the funnel once, in snake_case, after the outcome: `lead_capture`,
`booking`, `purchase`. Number the steps from 1 at the widest.

For a site whose success is "someone gets in touch", that is usually:

    1  select_content   the links that start the journey: a service card, a plan
    2  view_item        opening the thing itself: a service page, a plan page
    3  contact          a phone, email or WhatsApp link
    4  generate_lead    the contact form's own button, if the site has one

Use the names get_analytics_setup gives you and nothing else. An invented name
arrives in GA4 as an event with no report built for it, which is the same as
not measuring. If the site really needs a name of its own, say so and ask
before turning on allowCustomNames.

Pick the **sink** by what the site has connected. GA4 measures; the Meta pixel
is for advertising and belongs on the last step or two, where an ad can be
optimised against it. Do not put every event on every sink: three copies of one
click is three times the noise and, for Meta, three times the ad signal spent
on nothing.

### Write it

set_link_events, addressing links by the sectionId and path list_links gave
you, and pass `funnel: { name, step }` on every event. Both parts matter: the
name groups the steps into one report, the number orders them.

One call, all the links. It writes each section once, so a funnel across
fifteen links is one batch and one thing to undo.

**Do not track everything.** A link to the privacy policy is not a funnel step.
Social icons in the footer are not a funnel step. Every event you add is a row
someone has to read past to find the one that matters, so leave the rest alone.
A shared navbar link is written once and counts on every page; that is correct,
and worth saying.

### Tell them

Short. The funnel as steps, each with the number of links behind it:

    Tracking is on, as a funnel called **lead_capture**:

    | | | |
    |---|---|---|
    | 1 | Services and plan cards | 6 links |
    | 2 | Service pages opened | 3 links |
    | 3 | Phone and email | 4 links |
    | 4 | Contact form | 1 link |

    It is in the draft. Say the word and I'll put it live, and it starts
    counting from then.

Then the one caveat that is true and easy to miss: nothing is measured until
the site is published, and if the site shows a cookie banner, visitors who
refuse are not counted. Say it in a line, not a paragraph.

Never publish on your own. This site is already live and this change is
theirs to make.

View saved version →

---
name: get-started
description: Set up Beste right after the plugin is connected. Check which sites the account already has and offer the next step, a new site or work on an existing one. Use when the person chooses Set up for Beste or asks how to start.
---

Help the person take their first step with Beste. Keep it short and warm, with no
jargon and nothing about how the connection works.

1. Call `list_websites` with `{}`.
2. No sites yet: say in one line that they can have a site in a few minutes, and
   ask what the business is. When they answer, follow the `new-site` skill.
3. One site: name it, and ask what they would like to do with it, offering three
   choices: change something on a page, review it for leftover demo content, or
   add another language. Follow `edit-page` or `review-site` for the answer.
4. Several sites: list them by name, one line each, and ask which one to work on.
   Then ask what they would like to do, as in step 3.

If they already said what they want when they installed the plugin, skip the
questions and continue that task with the matching skill.

Never publish during setup. Every change goes to the draft until the person asks
for it to go live.

View saved version →

---
name: new-site
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."
---

Build a Beste site

## Start building, not asking

A brief is enough. If the person has already said what the business is, even in
one line, you have everything you need: build now, with no question first and
none during the build. Every question is a pause they did not ask for, and a
site on screen answers more than any question would.

Only if there is no brief at all, say what the site is for in one message, five
lines, warm, no jargon, along these lines, in your own words:

    **Let's make your site.**

    Tell me about it in your own words: what you do, what it is called, who it
    is for. Anything real helps, years, cities, prices, a phone number, names.

    **The more you write, the better the site.** Then I build it straight away.

Then stop and wait for that one answer. It is the only question you ever ask.

### What you decide yourself

Everything else is yours, never a question, and never a list of options with a
recommendation in it:

- **The name**: from the brief. No name given? The short name of what they do,
  which they can change in a word.
- **The language**: the one the brief names, otherwise the one they write in.
- **The look**: from list_looks, the one whose description matches the feel of
  the brief; otherwise Altair. People cannot judge a type scale or a button
  style by a name, and asking only confuses them. Do not mention the choice.
- **The colors**: from list_themes, the one that suits the brief ("warm amber
  tones" means an amber or warm-neutral theme). The same: pick, do not ask.
- **The pages**: what the brief asks for. A one-page site is one page; otherwise
  three, home included.
- **Images**: the placeholders. Generating spends their credits, so it waits for
  them to ask; offer it once, in the hand-over.

Then create_website with the name and language. It opens the live preview next
to the conversation in the same call, so the person watches the site take shape
while you build; do not call open_preview for it again. Where the result says
the preview did not open, call open_preview once. One line back: the address,
and that a custom domain can be attached later.

**Sections first, dressing last.** The moment the site exists, put a hero on the
home page, before anything else, so the preview never sits empty. Then build
every page's sections, navbar and footer. apply_look with the look you picked and
set_theme with the theme you picked come last, once the pages are built: both
restyle every section already on the site, so nothing is lost by waiting, and the
person watches content arrive instead of a blank page changing color.

Asked for six pages, or twenty? Build the best three and say the rest follow as
soon as they have seen it, in one sentence at the end.

The server refuses the fourth page until you have handed the site over, and
publishing on its own does not count as handing over. What counts is finishing:
publish, show them what they have, and stop. Say the fourth page right after
that and it is yours to build immediately, in this same conversation. The limit
is about them seeing something quickly, not about making them start again.

While building: silence, then one line per finished page.

## Build

Pages first: a link needs its target to exist before it can be written.

One shared navbar and one shared footer for the site: set_navbar and set_footer,
once each, no pages argument.

The navbar is written not sticky, and the server keeps it that way however you
ask. Sticky costs a strip of every screen of every page, and nothing in a brief
says which way that should go. Leave it; it is one switch in the builder, and a
reader who wants it will ask.

The logo is a wordmark, not a legal name: use the short form people actually say.
"Hartley Care and Companionship Services" becomes "Hartley Care". Once the navbar
is set, tell them in one line that they can upload their real logo in the
builder, and give them the link from preview_url. Links between pages are internal links carrying the
page id from list_pages, never a URL; an external link to "/about" is rejected
and the rejection carries the value to use instead.

A link to a spot on the same page is an anchor link, { type: "anchor", sectionId:
"<anchor>" }, and the anchor is a name you give the target section: "pricing",
"faq", "contact", "how-it-works", never its id. Set it with add_section { anchor }
when you add the section, or update_section { anchor } later (links on the page
follow a rename). Add the target before the link; a link to an anchor no section
has, or to a section by its id, is rejected.

Anything on more than one page is shared too: add_section with shared: true and
pages: "all", or share_section for one you already made. Copies drift, and the
third page keeps the old phone number.

Per page, per role: search_sections with a plain description, the chosen look's
label as the set argument and the websiteId, get_section_defaults, then add_section changing
only what you mean to change. The set is a preference, not a fence: sections
drawn for it come first, and when another set has the better layout for this
role, take it. It arrives in the site's look like everything else.

### Do not build the same site twice

The catalog holds 708 sections. The honest failure of a generated site is that
it uses eight of them, the top hit for every query, so two sites in the same
trade come out as the same page with different words in it.

Pass websiteId to search_sections. Anything the site already uses comes back
marked and sorted to the bottom, and the answer is to take the one above it.
A section repeated on two pages is a repeat even when the copy differs: the
reader recognises the shape, not the sentence.

Search differently per role, too. "Three services with an icon each" and
"services in a grid" return the same top hit; describing the page you want
("the moment a carer arrives", "prices side by side with what is included")
reaches parts of the catalog a category name never will.

### Pieces

A media slot can hold a photo or a **piece**: a small live UI component drawn in
the page - a chat thread, a booking confirmation, a chart, a phone frame, a
receipt. get_section_defaults tells you which fields of a section accept one.

There are 315, and the demo payloads use about twenty. So a section that ships
with a piece ships the same piece on every site that uses it, and leaving it is
exactly the sameness worth avoiding. Two rules, both easy:

- The default has a piece: keep it only if it suits the business. Otherwise
  search_pieces for one that does, or drop to a photo.
- The default has a photo: a piece is often better, when it can show something
  true about the work. A care company can show the visit card the family gets;
  a restaurant, the reservation; a studio, the invoice.

Whichever you use, rewrite its props in the customer's own words. get_piece
returns the demo values; a piece left on "Dr Amelia Frost" is demo content in
the same way filler copy is.

### How much to build

**Three pages, or one when the brief asks for a one-page site. Four sections on
the home page, three on every other page.**
The navbar and the footer are not sections in this count; they are on every page
already.

These are ceilings, not targets to reach past. A first build is something to look
at and react to, not a finished site, and a long site is harder to react to than
a short one: the person cannot tell you what to change if they are still
scrolling.

Four on the home page is enough to say who this is:

  hero, what they do, the proof or the work, a closing call to action

Three on an inner page: a header, the substance, a way to act.

Everything else waits, and the wait is one message long. Once you have handed the
site over there are no limits at all: more pages, more depth on a page, a blog,
each one sentence from them and yours to build on the spot.

Fill what you add. search_sections tells you how many items a section holds
(collections: features 6); a six-slot block with two items filled reads worse
than a smaller block would. If the brief lists five services, choose a section
that holds five. If it gives one line about the founder, do not stretch it over
three sections to look busy.

Write from the brief, not from the section: a features block with three slots
does not mean the business has three services.

Do not write image URLs. Every photographic slot is filled server-side with one
of four house placeholders, in rotation, whatever the demo payload carried: eight
sections from eight different photo shoots is what makes a page read as a
template even when the words are right. Logos, icons and anything already
uploaded to the site are left alone.

Never download the site's own media to look at it. list_images gives you the
address, the filename, the type and the size of every file, which is what a
question about the library actually needs. Opening them costs a request each and
a real library runs to hundreds.

So the images on the finished site are deliberately not the real ones. Say that
in the hand-over, next to the offer to replace them. Generating images spends
their credits, so offer it, do not decide it.

**Once you start building, stop asking.** No questions between create_website
and the finished site. Someone watching a build does not know whether a question
is a question or a pause, so they wait, and the thing stalls with everyone
waiting for the other.

Missing a fact? Leave that part out and keep going. A section without a phone
number is fine; a section with an invented one is not. Collect what was missing
and say it at the end, in one short list, next to the finished site.

The one exception is something that would produce a wrong site rather than a
thinner one, and that is rare enough that you should assume it is not happening.

## Blog posts

**Not during this build.** No posts, however the brief is worded and however
directly you are asked, including "and write me three articles". The server
refuses create_post until the site has been handed over, so this is not a
judgement call. Say it plainly once, at the end, with the offer: the site goes
live first, and then a post is one sentence away, in this same conversation.

A blog list section on a page is fine and worth adding when the business will
blog; it fills itself from real posts the moment there are any.

What a post is, for later: not a page. create_post writes one, and it carries a
summary, an author, tags and a publish date. A post written as a page is
invisible to every listing on the site and cannot be edited in the builder's post
drawer, so never reach for create_page for an article.

Write the article in Markdown and pass it as "body": headings, lists, tables,
quotes, code and links all survive. Do not build a post out of sections.

create_author first if the post has a byline. Blog list sections (search_sections,
category Blog List) list the real posts by themselves, so put one on a page and
leave its "posts" list alone.

## Another language

add_language, then per page: get_translatable_text, translate the strings
yourself, apply_translation. You are the translator: keep the ids, keep HTML
tags and placeholders exactly, and write as a native speaker in that industry
would, not word for word.

Changing or removing a language is critical. set_default_language and
remove_language answer first with the impact and a confirmation code and change
nothing: tell the user every count in it, in their words, and send the code back
only after they say yes. Removing the default language needs a new default,
and only the user picks it; if they did not name one, ask.

## Finish

get_page_markdown on every page, read it as the customer would, fix what still
reads like sample content, and check the page is the size it should be: four
sections at home, three inside, navbar and footer not counted, every list filled.
Over that, cut rather than keep; a page that got long during the build is the one
thing they cannot fix in a sentence.

Then publish. It returns liveUrl and builderUrl, and those two links are the
whole point of the last message: one to look at what they have, one to change it.

Hand it over in a single message, laid out. This is the one place to spend a
little on presentation, because it is the only screen they will read twice:

    ╭────────────────────────────────────────────╮
    │  Hartley Care is live                      │
    ╰────────────────────────────────────────────╯

    | | |
    |---|---|
    | **See it** | http://hartley-care.beste.co |
    | **Edit it** | http://studio.beste.co/.../home |
    | **Pages** | Home, Visits, Contact |

    Two things I left out, for want of a fact:
    - no phone number on the contact page
    - the founder's name, so the About section speaks for the company instead

    Say the word and I will do any of these now: another page, more on a page
    you have, real photos, or a blog post.

The box holds the name and the state, nothing else. The table holds what they
click. The gaps are what you could not know, not a list of everything you chose
not to build. The last line is an offer, not a menu to read.

Keep the widths sane: the box is drawn to fit its line, not padded to eighty
columns, and links go in the table rather than inside the box where they wrap.

## Publishing

You publish **once**, at the end of this build, as the hand-over. That publish is
expected: it is what makes the links in your last message work.

After it, publishing is theirs and never yours again. If they ask for a change in
this same session, make it, tell them it is saved to the draft, and stop there.
Do not publish it. Not because it is small, not because it is obviously an
improvement, not because you are confident they will want it: none of those is
them asking. The live site is what their customers are reading right now, and a
change that appears on it without anyone deciding is a change nobody can trace.

The server asks you to quote them for exactly this reason. If you cannot say what
they said, ask: one line, and wait.

Everything is a draft until publish. Content is per language. Never set colors,
gradients or shader effects on a section: the theme owns them and the server
rejects them. The only colour decision is the theme, picked by you at the start.

A background photograph is the exception, because it is a picture rather than a
colour scheme: style.colors.backgroundMedia takes enabled, type, src, size,
position and an overlay. Turn the overlay on whenever text sits over the image,
or the headline is unreadable and nobody asked for that. Padding and width are
yours too: padding.py and padding.containerMaxWidth.

### One look, any section

A site has one look: its type scale, button style, badge look, card borders and
motion, written site-wide. apply_look set it from a studio set; get_site
reports it under style. Every section you add takes it on the
way in, whichever set it was drawn for, so mixing sets is not a risk to manage:
a Sirius hero above a Polaris feature reads as one page because both wear the
site's buttons and badges.

**Sections arrive without a badge.** add_section never writes one, not even one
you pass. When the person asks for a badge, add it with update_section.
A badge above every heading is the pattern that makes a generated site read as
generated. Do not bring badges up or offer to add them.

Fonts come with the theme. When the person names a typeface or asks for a
different feel in the type, set_fonts: a curated pairing from list_fonts by id,
or body, heading and code fonts by name. Colors stay with the theme either way.

When the person wants the look changed, change it where it lives: set_appearance
with only the field they named. "Make the headings smaller" is typography
compact, "seal buttons" is buttons, "no card borders" is cardBorder off, "calmer
animations" is sectionAnimation with a slower duration or mediaAnimation with
scroll none. One call rewrites every section still wearing the old value. Never
walk the pages editing sections one by one for a site-wide change, and never
give one section a look of its own to satisfy a site-wide wish.

Entrance animations are yours as well, and they belong to their own tools rather
than to a style patch: get_animations reads what every section does and carries
every type and speed the builder offers, set_animations writes them
across a page or the whole site at once. Leave the site's animations as the
sections ship them unless the person says otherwise.

View saved version →

---
name: review-site
description: "Read every page of a Beste site and list what still reads like demo content, missing SEO, repeated sections and broken links, without changing anything. Use when the person asks what is wrong with their Beste site or wants it reviewed."
---

Review a Beste site and report, do not fix anything yet. Findings as a list, no
preamble around it.

1. list_websites, get_site, list_pages.
2. get_page_markdown for every page.
3. Report, grouped by page:
   - copy that is still demo text (placeholder names, lorem, "Build something")
   - claims that look invented rather than given by the user
   - pages with no SEO title or description
   - sections that are empty or hidden
   - the same block repeated on several pages as separate copies rather than one
     shared component (they will drift apart)
   - the same section type used again and again, or a piece still showing its
     demo values (get_section_defaults names the piece slots)
   - navigation links that point nowhere useful
   - articles built as ordinary pages instead of posts (list_posts against
     list_pages): no listing on the site can find them. The fix is to read the
     page, create_post with the same text as the body, then delete the page
4. End with a short list of the fixes you would make, in priority order, and ask
   which ones to apply.