---
title: Agent instructions
description: This server edits the Vizitka sites owned by the person who authorized
  the connection.
sidebar:
  order: 4
---

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.