Agent instructions

This server edits the Vizitka sites owned by the person who authorized the connection.

Start with get_site. Every tool defaults to the account’s original site; use one of the friendly ids in available_sites as tenant_id to select another.

Before authoring, start with the vizitka://docs/vzk/authoring resource: how a site is laid out, the editing loop, and the index of focused guides (vzk/<topic>: pages, tables, languages, styling, javascript). describe_vocabulary topic=language is the whole language on one card, with its examples. Read it before the first write, and write only what it shows.

Building a new site, or rebuilding most of one? Read building first, then playbooks/<trade> if the owner’s trade has one, then the focused guides. Topic sites holds whole worked sites to start from.

Use the generated fields, meta, behaviors, layout and looks topics for exact vocabulary. Do not guess names or load every guide for a small edit.

A page is a .vzk file: HTML with values in braces, control written as attributes, and a small script before the markup. There are no section types. Shared headers and footers are layouts and components. Translated words live in locales/ (after set_site_languages); visual rules live in the site’s stylesheet.

The site’s code is a set of files on branches. Work on a branch of your own (create_branch), read files before replacing them, and write with write_files, edit_file, write_block or edit_block. Return the branch’s preview URL and merge it with merge_branch only after the owner approves, unless they explicitly asked for the change to go live at once. Edits to rows, table definitions, site meta, and site languages are live at once; tell the owner first.

Link to pages by address; name a table’s page by its file. Use disk asset keys in pages instead of copying absolute URLs. Use record slugs for public rows. Never invent database ids. When the customer attached a picture to the conversation, pass the attachment as file; use prepare_file_upload for a local file instead of putting base64 into context.

A visitor form is supported: create a table with writable_by: public and write the site’s own input markup in a form that names it. A blog is a public posts table, one [slug] page that draws a row, rows written with create_record, and an ordinary listing page; a portfolio of case studies or projects is the same on the reserved portfolio table. Read vzk/tables for both.

list_notifications reads form alerts, and pages a visitor could not be shown with their code, without marking them read. Asked what is wrong with a site, inspect them and read the current object before changing it.

When the focused guide and generated vocabulary confirm that a request cannot be represented, check list_feature_requests, file the missing capability with request_feature without asking first, build the closest supported result, and explain the gap. A form that stores a submission is not a missing capability.