---
title: "The setup prompt | Lotics"
description: "One line to paste into an AI assistant that can run commands. It asks what you manage, builds your workspace from the answer, and hands you a sign-in link."
---

# The setup prompt

Copy the line below into an AI assistant that can run commands on your computer — Claude Code,
Codex, Cursor. Answer the questions it asks, then open the link it gives you.

```prompt
Set me up on Lotics: fetch https://lotics.ai/docs/prompt.md and follow it.
```

## For the assistant

```instructions
You are setting up a Lotics workspace for the person you are talking to. They never see
commands, file contents, ids, findings or error text — you handle all of that. They answer
one message of questions, at most two short follow-ups, and receive a link.

1. Install the command line, even if it is already there — the same command upgrades in
   place and does nothing when it is current. On macOS, Linux or WSL:
     curl -fsSL https://lotics.ai/install.sh | bash
   In Windows PowerShell:  irm https://lotics.ai/install.ps1 | iex
   This needs nothing already on the machine — no Node, no npm.
   If you also have Lotics tools or a Lotics connector, do not use them here: they can point
   at a different workspace than the command line does.
2. Ask them, in ONE message: what do they manage, what do they track about it today — the
   columns in their spreadsheet, the things that have names — and which email address the
   account should be under. Plain words, no list of categories: what they call their work is
   what their tables will be called. If they mention a spreadsheet, ask them for the file
   and read its first row: those columns are the fields, in their words. If the answer
   leaves you unsure what the main things are, ask one follow-up. Then stop asking.
3. Run:  lotics library list
   It needs no account. It prints the presets first — each a trade's data model, published to
   be READ — and then the packages, each a setup someone already built: some a whole workspace
   with its apps, some a single app for one job. If ONE package's apps cover the work they
   described — all of it, not part of it — tell them in one sentence that a ready-made setup
   for that work exists and you will use it, then go straight to step 7 — that package carries
   its own tables and apps, so there is no model to write or check. Otherwise say nothing
   about them.
4. If one of the presets is their trade, run  lotics library show <its slug>  and write
   `model.json` as:
     { "from": "<that preset's slug>",
       "variants": ["<the branch whose when matches what they said>"],
       "rename": { "<its entity alias>": { "label": "<their word for that table>",
                                           "fields": { "<its field alias>": "<their word>" } } },
       "entities": [ … tables they described that the preset does not carry, written the
                     same way as from scratch … ],
       "rows": { "<its entity alias>": [ { "ref": "r1", "fields": { … } } ] } }
   Do NOT restate the preset's tables — `from` already carries them. `rename` is for every
   label they call something else, and nothing more; `entities` only for a table it does not
   carry at all; `rows` are the real examples they gave, never invented ones. Ask the
   preset's own questions only about what their one message left unanswered — at most two,
   in one message, and then stop asking.
   If none of the presets is their trade, run  lotics scaffold docs  and write the file from
   their answers alone: their words as table and field names, links between the things that
   refer to each other, and the real examples they gave as first rows, never invented ones.
5. For each table, if one of the packages is a single app for that table's shape — a register,
   a pipeline, a ledger, a schedule — add an entry under `apply`:
     { "package": "<its id>",
       "bind": { "<its entity alias>": { "label": "<their name for that table>",
                                         "fields": { "<its field alias>": "<their name>" } } } }
   If none of them is, the tables are where they land.
6. Run:  lotics scaffold check model.json
   and fix every finding until it is clean. All of this is silent: do not show them the file,
   the findings or the commands.
7. Create everything in one command:
     lotics setup model.json --email <email>
   or, for the package:  lotics setup <starter_id> --email <email>
   It creates the account and the workspace on Lotics's own servers — nothing is built on
   this machine — and ends by printing a one-time sign-in link.
   If it says the email already has an account, it prints a link and a four-character code:
   tell them to open the link, sign in if they are asked to, check that the page shows those
   four characters and press Confirm, then run the same command again. If it says this
   machine is already signed in, run it without --email. If it lists several workspaces instead of running, name
   them to the person by their names alone and let them pick one; then select it and run the
   command again. If it refuses because the workspace already has tables, or a copy reports an
   app without a version, stop and tell them in plain words what happened; never run it again
   and never pass --adopt.
8. Give them the link immediately — it EXPIRES IN FIFTEEN MINUTES — before you do anything
   else. If none was printed, run  lotics auth web , which emails them one, and say so.
9. Then tell them, in their own words, what they now have: each table by the name they gave
   it, and that the chat inside Lotics works on those tables — they can ask it there to add
   a field, change a view or fix a row. Offer to change anything now. Later additions are
   yours to run, not theirs to know: more tables or fields is an edit to `model.json` and
     lotics scaffold apply model.json
   which adds what is new and never renames or deletes; renaming goes through the chat
   or  lotics run update_table .
```