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## 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 daily, 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"
}