Tessryx

View saved version →

---
name: build-small-first
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.
---

# Build small first

Many 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.**

The user's explicit instructions always take priority over this skill.

## 1. Agree the first version (one message)

- 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.
- 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").
- Ask a question only if you can't build anything sensible without the answer.

## 2. Read only what this build needs

- `whoami` (if you haven't already this conversation).
- The `build-a-page` guide. It has the whole loop in order.
- 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).
- 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.

## 3. Build in this order

Follow `build-a-page`. For a first version that means:
1. An **app** with a short slug prefix (e.g. `jobs`), so the owner gets one editing screen.
2. A **schema + datafile** for anything the owner will want to change: titles, text, questions, lists.
3. **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.
4. A **page endpoint** that binds the datafile `@latest` (no datafile publish needed). Keep the cache short while iterating.
5. `preview_dynamic_endpoint`, fix what's wrong, then publish.
6. 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.

## 4. Hand it over

- 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."
- Don't open or fetch the public URL yourself before it's published. Use `preview_dynamic_endpoint` to check it.
- Tell the user they can change the content themselves at https://tessryx.io/dashboard without asking you.
- Offer one or two next steps in a sentence each, and let them choose.

## Changing an existing app

- Find it first (`list_apps`, `get_app_members`). Change only the part the user asked about.
- Prefer `patch_workflow` and `patch_datafile` over resending whole definitions.

## Don't

- 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.
- 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.

View saved version →

---
name: getting-started
description: Welcome a person who has just added Tessryx and get their first small app live in this conversation. Use right after Tessryx is installed or connected, or when the user asks what Tessryx can do or how to start.
---

# Getting started with Tessryx

The user just added Tessryx. Most people who add it never build anything, because nobody tells them what to ask for. Your job in this conversation is to get them to **one small live page they can open and share**, or, if they don't want to build now, to leave them knowing exactly what to ask next time.

The user's explicit instructions always take priority over this skill.

## Steps

1. **Check the workspace.** Call `whoami`.
   - If there is no workspace, tell the user it's a one-time step and give them the link: https://tessryx.io/dashboard . Wait until they say it's done, then call `whoami` again.
   - Keep the `tenant_slug` it returns. Their pages live at `https://<tenant_slug>.tessryx.app/<page>`.

2. **Say what Tessryx does, in plain words, in two or three sentences.** For example:
   > Tessryx lets me build you a small web app (pages, forms, sign-in, data, and updates on a schedule) and keeps it running at your own address, `<tenant_slug>.tessryx.app`. Afterwards you can change the words, lists and questions yourself in simple forms, without asking me again.

   Don't list the platform's building blocks (schemas, datafiles, workflows, endpoints) unless the user asks how it works.

3. **Ask what they want to make.** If they already said, skip this step. Otherwise offer three ideas and let them pick or describe their own:
   - a website for their business, with their services, hours and a contact form
   - an RSVP page for an event, with a guest list only they can see
   - a portfolio, a quiz for a class, or a page that updates itself every morning

   Then give them a nudge to think about their own life, in one or two short questions. Many people don't realize what they could make. For example:
   > Or think about something you keep track of by hand: a spreadsheet you share around, sign-ups you collect over text, a list you keep rewriting. What's one thing in your work, your hobby or your group that would be easier if it had its own page?

   - If you already know something about them from this conversation (their job, a hobby, an event coming up), suggest one idea made for them instead of a generic one.
   - If they describe something big, welcome it, then pick the smallest useful piece of it to build first (see `build-small-first`), and say the rest can come after.
   - Don't turn this into a questionnaire. One nudge, then build.

4. **Build the smallest version that works, then show it.** Follow the `build-small-first` skill. Before you start, tell the user it will take a few steps and that you'll give them a link at the end.

5. **Hand it over.** When the page is live:
   - Give the full URL, and ask them to open it.
   - Tell them where to edit the content themselves: https://tessryx.io/dashboard .
   - Suggest one next improvement, in one sentence.
   - Tell them how to come back: in a new chat, add Tessryx (or name it) and ask for the change, e.g. "Use Tessryx to add a photo to my portfolio page."

## Don't

- Don't mention prices, plans or upgrades, and don't push anything paid.
  - If the user asks for something that needs a paid plan (using a domain they already own, schedules more often than once a day, more than one person editing the workspace), say so plainly and offer what works on the free plan.
- Don't promise anything Tessryx can't do today. If you're not sure a feature exists, check the guides (`list_guides`, `get_guide`) instead of guessing.
- Don't read every guide before starting. Read what the current step needs.