Update to Tessryx

{
  "description": "Build a web page, form, dashboard, portal, quiz or small app on Tessryx in as few steps as possible, so the user sees a live link in one sitting. Use whenever the user asks Tessryx to build or start a site, page or app.",
  "included_files": [],
  "name": "build-small-first",
  "skill_md_contents": "---\nname: build-small-first\ndescription: Build a web page, form, dashboard, portal, quiz or small app on Tessryx in as few steps as possible, so the user sees a live link in one sitting. Use whenever the user asks Tessryx to build or start a site, page or app.\n---\n\n# Build small first\n\nMany Tessryx users are on plans with a limited daily allowance. A build that spends the whole conversation reading and planning ends with no page, and that user rarely comes back. So: **get one working page live first, then improve it.**\n\nThe user's explicit instructions always take priority over this skill.\n\n## 1. Agree the first version (one message)\n\n- Restate what you'll build first in one or two sentences: one page, the few fields or sections it needs, and sample content where you need it.\n- Leave extras for after it's live: more pages, styling passes, sign-in, schedules, outside APIs. **Unless** the user's request is about exactly that (e.g. \"a page that updates every morning\").\n- Ask a question only if you can't build anything sensible without the answer.\n\n## 2. Read only what this build needs\n\n- `whoami` (if you haven't already this conversation).\n- The `build-a-page` guide. It has the whole loop in order.\n- The definition format for each kind of resource you're about to write, right before you write it (e.g. `get_workflow_definition_schema` before the first workflow).\n- Other guides **only** when the build needs that feature: `endpoints` for sign-in or members-only pages and form posts, `schedules` for timed updates, `api-templates` for outside services.\n\n## 3. Build in this order\n\nFollow `build-a-page`. For a first version that means:\n1. An **app** with a short slug prefix (e.g. `jobs`), so the owner gets one editing screen.\n2. A **schema + datafile** for anything the owner will want to change: titles, text, questions, lists.\n3. **One workflow** that renders the page from `$datafile`, built from small named literal variables (css, body, js). Later changes are then a small `patch_workflow`, not a full resend.\n4. A **page endpoint** that binds the datafile `@latest` (no datafile publish needed). Keep the cache short while iterating.\n5. `preview_dynamic_endpoint`, fix what's wrong, then publish.\n6. Only if the page needs to save something (a form, an application): a JSON workflow and an API route endpoint, called from the page's script.\n\n## Make the first version look like theirs\n\nThe first link is the user's first impression of Tessryx. A page that looks designed for their business, not a template, is worth a little extra effort, as long as it still goes live in one sitting.\n\n- **Find the art direction in this business, not in a category.** Before you build, pick one or two specific things from what the user told you (the business name, the town or street, what they make and what it's made of, the era or style of their place, their customers, a word they keep using) and let them drive the look. A bakery called \"Rise\" in an old brick building gets flour-dust cream, brick red and a bread-score line motif. A beach volleyball league gets sand, net-line borders and scoreboard numerals. A tax preparer who works with farmers gets field-map greens and ledger rules. If you know only the category, ask one quick question (\"Anything about the place or the people you'd like it to feel like?\") or make a specific guess and say what it is.\n- **Say the direction in one line,** then build: the idea, a palette of 3-5 colors taken from that idea, and a font pairing that fits it. Don't make them choose unless they want to.\n- **One signature element** that only makes sense for this business: a divider shaped like their product, a hero laid out like their menu board, a background pattern from their materials, a hover effect that echoes what they do. One, done well.\n- **Avoid the template look:** no generic purple-to-blue gradients, no default system fonts, no centered hero over three identical feature cards unless the content truly is three equal things, no stock \"Lorem\" or \"Welcome to our website\". If you'd make the same page for a different business by changing the name, change the page.\n- **Fonts:** one display font and one text font from Google Fonts, or Bunny Fonts (fonts.bunny.net, the same families, no visitor tracking) when the user mentions privacy or the EU.\n- **Libraries only where they add something,** loaded from a CDN with a pinned version (jsDelivr, cdnjs or unpkg): an icon set such as Lucide, a small animation or chart library when the page needs it. No large CSS frameworks, and never Tailwind's Play CDN, which isn't meant for production.\n- **Hand-written CSS with design tokens:** colors, spacing and radius as CSS variables in the `css` variable, so a later restyle is one small `patch_workflow`. Mobile first, readable contrast, real hover and focus states.\n- **Their words, not filler:** use what the user gave you; where you need sample text, write it for their business and mark it as sample so they replace it in the editor.\n- **Images:** the user's own photos (they upload them at https://tessryx.io/dashboard/media, then you embed them by their asset URL), or CSS and inline SVG shapes. Don't hotlink stock photos.\n- **Keep it in budget:** a distinctive page is a few hundred lines of CSS at most. If the conversation is getting long, ship the first version and offer the polish as a next step.\n\n## 4. Hand it over\n\n- Give the live URL: `https://<tenant_slug>.tessryx.app/<endpoint-slug>`. Add: \"A brand-new page can take up to a minute to appear. If you see 'Not Found', wait a moment and reload.\"\n- Don't open or fetch the public URL yourself before it's published. Use `preview_dynamic_endpoint` to check it.\n- Tell the user they can change the content themselves at https://tessryx.io/dashboard without asking you.\n- Offer one or two next steps in a sentence each, and let them choose.\n\n## Changing an existing app\n\n- Find it first (`list_apps`, `get_app_members`). Change only the part the user asked about.\n- Prefer `patch_workflow` and `patch_datafile` over resending whole definitions.\n\n## Don't\n\n- Don't mention prices, plans or upgrades. If a request needs a paid plan (a domain they already own, schedules more often than hourly, teammates editing the workspace), say so plainly and offer what works on the free plan.\n- Don't build several pages, a design system or an admin area before the first page is live, unless the user asked for exactly that first.\n"
}