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.

## Make the first version look like theirs

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

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

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: client-portal
description: Build a client portal, customer portal or members area on Tessryx, where invited clients sign in to private pages and each sees only their own records, files and status updates. Use when the user asks for a client portal, customer portal, private page per client, or a place to share work with clients.
---

# Client portal

A client portal on Tessryx is a set of members-only pages. The owner invites each client by email as a **visitor**: visitors sign in, open the pages that admit them, and take no seat. Follow `build-small-first` for the build order; this skill adds the portal-specific parts.

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

## Read first (only these)

- `whoami`, then the `build-a-page` guide.
- The `endpoints` guide, sections "Gated endpoints" and "Private pages for invited people (visitors)".
- `get_dynamic_endpoint_definition_schema` before the first endpoint, for the exact `auth` shape.

## First version (one sitting)

1. An **app** with a short prefix (e.g. `portal`), and a **schema + datafile** per client for what the owner updates: project name, status, next steps, links.
2. **One page workflow** that shows the signed-in client their own record. Gate its endpoint with `auth.required: true`, `allow.tenant_roles` set to `["ROLE_VISITOR", "ROLE_OWNER", "ROLE_ADMIN"]` (the match is exact, so list the owner's role too), `expose_identity: true` and `on_unauthenticated.mode: "prompt"`.
3. Key each client's record on `auth.viewer_id`, or keep a small owner-edited mapping from the invited email to the client's record.
4. `preview_dynamic_endpoint`, publish, then `invite_visitor` for the first client. Tessryx sends no email, so give the owner the link to send.

## After it's live (offer, don't build unprompted)

- A status form the owner fills in, so updates don't need the AI.
- One folder or app per client with `invite_visitor` `sites`, so one client never opens another's pages (`set_visitor_sites` to change).
- Transactional email to a visitor when their status changes (`workflows` guide, "Email to a visitor").

## Keep in mind

- **Look:** calm and trustworthy, in the owner's brand colors if they give them: the client's name and project status first, clear next steps, generous spacing.
- Visitors see only pages that admit them: no dashboard, no workspace data, and they take no seat.
- Everything above works on the free plan at the workspace's tessryx.app address.

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 an hour, 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.

View saved version →

---
name: internal-tool
description: Build an internal tool, admin page or team dashboard on Tessryx, such as an inventory list, a request tracker, a CRM-style list or a scheduled report, that only the owner's team can open. Use when the user asks for an internal tool, admin panel, back-office page, team dashboard or a tool to replace a spreadsheet.
---

# Internal tool

An internal tool on Tessryx is a page gated to the workspace's own team, backed by datafiles the team edits in generated forms, with optional scheduled jobs. Follow `build-small-first` for the build order; this skill adds the parts specific to internal tools.

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

## Read first (only these)

- `whoami`, then the `build-a-page` guide.
- The `endpoints` guide, section "Gated endpoints", for `auth.allow.tenant_roles`.
- The `datafiles` guide if the tool lists many records ("Listing at scale") or counts things.

## First version (one sitting)

1. An **app** with a short prefix (e.g. `ops`), and a **schema** for one record type (an item, a request, a customer). Datafiles under the prefix hold the records; the schema also gives the owner an editing form at https://tessryx.io/dashboard.
2. **One page workflow** that lists the records, and an endpoint gated with `auth.required: true`, `allow.tenant_roles: ["ROLE_OWNER", "ROLE_ADMIN", "ROLE_VISITOR"]`, `expose_identity: true` and `on_unauthenticated.mode: "prompt"`. List every role that should get in; the match is exact.
3. **Teammates use the tool as invited visitors** (`invite_visitor`): they sign in and use the pages, and take no seat. So people add and change records **on the page**: a JSON **route** (POST) that validates and writes them, called from the page's script, gated the same way with `on_unauthenticated.mode: "refuse"`.
4. Preview, publish, give the link.

## After it's live (offer, don't build unprompted)

- A scheduled job that refreshes a summary or pulls data from another service (`schedules` and `api-templates` guides).
- An email to the team when something needs attention (`workflows` guide, "Email").

## Keep in mind

- **Look:** dense and fast to scan: a clear table or cards, filters at the top, status colors that mean something, and big touch targets for people on phones.
- Build it so the team works in the tool's own pages, not in the workspace dashboard: the owner builds, everyone else is an invited visitor. That works on the free plan.
- Use one scheduled job at most, running no more than hourly, unless the user asks for more.

View saved version →

---
name: orders-and-bookings
description: Build an order form, booking page, appointment or reservation form, waitlist or RSVP on Tessryx, with Stripe Payment Links for payment, one booking per slot, spam protection and an email to the owner for each new order. Use when the user asks for bookings, appointments, reservations, an order form, taking payments or selling something on their site.
---

# Orders and bookings

A booking or order page on Tessryx is a form page plus a POST route that saves each submission as a record. Payments go through the owner's own Stripe Payment Links, confirmed by a verified Stripe webhook. Follow `build-small-first` for the build order; this skill adds the order-specific parts.

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

## Read first (only these)

- `whoami`, then the `build-a-page` guide.
- The `workflows` guide, sections "Claiming a unique key: `create`" (one booking per slot) and "Email".
- The `endpoints` guide, section "Webhooks from another service" (the Stripe part, "Taking payments"), and "Stop form spam with Turnstile" if the form is public.

## First version (one sitting)

1. A **schema** for an order or booking, and a datafile the owner edits for what's offered (services, times, products).
2. The **form page**, and a **POST route** that validates and saves each submission. For a slot that only one person may take, write it with `operation: "create"` keyed on the slot, so two people can't both get it.
3. An **email** to the owner's team for each new order or booking.
4. Preview, publish, give the link.

## Taking payment (when asked)

- There's no checkout built in. The owner makes a Stripe Payment Link per product in their Stripe dashboard; the page links to it with `?client_reference_id=<order id>`.
- A POST route with `verify: { "provider": "stripe", "secret": "<slug>" }` receives `checkout.session.completed` and marks the order paid. The user stores the Stripe signing secret at https://tessryx.io/dashboard/secrets.
- Skip an event id already handled.

## Keep in mind

- **Look:** match the business (a salon, a food truck, a tutor) and keep the form short and obvious: what's offered, pick a time, pay, done. Show a clear confirmation.
- The owner's own Stripe account takes the money; Tessryx doesn't.

View saved version →

---
name: realtime-multiplayer
description: Build a real-time page on Tessryx, such as a multiplayer browser game, a live chat room, a collaborative whiteboard with live cursors, a live poll or live scores, with presence and instant updates and no WebSocket server to run. Use when the user asks for multiplayer, real-time, live updates, a chat room, live cursors or a page several people use at once.
---

# Real-time and multiplayer pages

A live endpoint keeps a page connected. Workflows `publish` events to a stream and every open page updates within a second. Relay channels pass each viewer's messages (cursors, strokes, chat) to everyone else at the edge, and presence shows who's here. Follow `build-small-first` for the build order; this skill adds the real-time parts.

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

## Read first (only these)

- `whoami`, then the `build-a-page` guide.
- The `endpoints` guide, section "Live pages" (live block, `initial`, `join`, presence, relay and screened channels, room state, costs).
- The `workflows` guide, section "Publish", if a route or schedule sends events.
- The `live-handlers` guide only if relay messages must be checked before they're passed on.

## First version (one sitting)

1. The **page** (a normal endpoint) loads the site runtime, `<script src="/_tessryx/site-1.js"></script>`, and calls `tessryx.live('<live-endpoint-slug>', { onEvent, onRelay, onPresence, onStatus })`.
2. A **live endpoint** with a `live` block. For cursors, strokes or chat, add a relay channel and `presence: true`. Use an `initial` workflow so a new viewer sees the current state.
3. For things that must be checked or stored (a move, a score, a message that's kept), a POST route that validates, saves and `publish`es.
4. Preview, publish, and open the page in two browser windows to show it working.

## Keep in mind

- **Look:** playful and alive: colors per person for cursors and names, a visible "who's here" list, small motion when something arrives, and a clear state when the connection drops.
- Design for up to 100 people on one page at once.
- Show the `onStatus` reason to the visitor (for example, the page is full or paused).

View saved version →

---
name: slack-discord-bots
description: Build a Slack bot, Slack slash command, Discord slash command bot or a webhook receiver for Stripe, GitHub, GitLab or Shopify on Tessryx, hosted as a route with no server to run. Use when the user asks for a Slack bot, Discord bot, slash command, buttons in Slack or Discord, or to react to a webhook.
---

# Slack and Discord bots, and webhooks

On Tessryx a bot is a POST route whose endpoint has `verify: { provider, secret }`. Tessryx checks the sender's signature before the workflow runs, answers Slack's URL check and Discord's PING by itself, and the workflow decides the reply. Follow `build-small-first` for the build order; this skill adds the bot-specific parts.

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

## Read first (only these)

- `whoami`.
- The `endpoints` guide, sections "Methods", "Webhooks from another service (`verify`)" and "Answer now, finish in the background".
- The `api-templates` guide if the bot calls back into Slack or Discord (posting a message, for example).

## First version (one sitting)

1. Ask the user to create the bot in Slack or Discord and store the signing secret at https://tessryx.io/dashboard/secrets (Slack: Signing Secret; Discord: Public Key). Tell them the secret's name to use. You never see its value.
2. A **workflow** that reads the command (Slack: `body.command` and `body.text`; Discord: the interaction in the body) and returns the reply. Discord's reply is the JSON output, `{"type":4,"data":{"content":"…"}}`.
3. A **POST endpoint** with `methods: ["POST"]` and `verify: { "provider": "slack" | "discord", "secret": "<slug>" }`. Publish, and give the user the URL to paste into Slack's Request URL or Discord's Interactions Endpoint URL.
4. Test with one command.

## Rules that matter

- Slack and Discord want an answer within 3 seconds. Reply at once and do slow work (an `llm` call, an outside API) in a background link with `continue_with`.
- Skip an event already handled, by its id (Slack retries carry `x-slack-retry-num`).
- A Discord bot here answers slash commands and buttons. It doesn't stay online reading every message.

## After it's live (offer, don't build unprompted)

- Posts on a schedule (`schedules` guide), records the team can edit, an AI reply with the `llm` block on the user's own model key (`agents` guide).

View saved version →

---
name: small-business-website
description: Build a small business website, landing page, portfolio, restaurant menu, league or club site, or a links page on Tessryx, with content the owner edits in simple forms and a contact form, live at a tessryx.app address. Use when the user asks for a website, homepage, landing page, portfolio, menu, club or league site, or a page for their business.
---

# Small business website

A website on Tessryx is pages rendered from datafiles the owner can edit in generated forms, so text, hours, prices and photos change without asking the AI again. Follow `build-small-first` for the build order; this skill adds what a business site usually needs.

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

## Read first (only these)

- `whoami`, then the `build-a-page` guide.
- The `workflows` guide, sections "Assets & media" (photos) and "Email" (the contact form).

## First version (one sitting)

1. A **schema + datafile** for the content: business name, tagline, services or menu items, hours, contact details, photos.
2. **One page workflow** that renders the home page from it, with a clear layout that works on a phone.
3. A **contact form** posting to a route that emails the owner's team. Add Turnstile (`endpoints` guide) if spam is a worry.
4. Preview, publish, give the link and point the owner to https://tessryx.io/dashboard to edit the content.

## After it's live (offer, don't build unprompted)

- More pages (about, services, gallery) from the same datafile.
- For a league or club: results entered in a form and standings that update live (`realtime-multiplayer` skill).
- For a portfolio: a page per project from a list in the datafile.

## Keep in mind

- **Look:** this is the page where design matters most. Base it on something specific to this business (its name, place, product or customers), as `build-small-first` describes, not on its category. A strong hero with their name and one line on what they do, then services, hours and contact.