tofu72.8 KB
View saved version →
---
name: tofu
description: Take an existing app live and keep it running through Tofu — upload it from chat or from a public GitHub repository, run Tofu's safety check, deploy it, read its status, versions and logs, restore an earlier version, connect a domain the user already owns, check whether it is answering, read its traffic, rename it or remove it, using the same projects, safety checks and deployments as the Tofu dashboard. Use it when the user wants an app online, an update shipped, a domain connected or a failed deploy explained. Nobody pastes a provider key, token or password into chat.
---
# Tofu
**This skill works through the Tofu connection this host already holds.** Tofu serves these tools live, from one address, so they are current the moment Tofu changes them: there is nothing to install or register, no version to compare and no document to fetch before you start. The human approved this connection on Tofu's own page. When a Tofu tool answers that the connection is missing or has expired, say so and let the human approve it again through the host's own connection settings — never ask for a token, a password or a key instead. A step this connection does not offer is named as missing, with the dashboard page that does it, never described as impossible.
Use this skill when the user asks to deploy, update, inspect, repair or remove an app hosted by Tofu. Use the Tofu tools this connection provides. Tofu hosts the app; the agent remains responsible for understanding the user's intended changes and explaining failures. A human's request to update and deploy is their agreement to that flow — the upload, the check and the deploy it names — taken once for the whole flow. Connecting Tofu alone is not authorization to deploy, an authorization to deploy is not an authorization to change the user's DNS records, and none of them is an authorization to delete an app. Never confuse a passing scan with a completed deployment, or with a statement that the code is safe — see *What the safety check is — and what it is not*. On the first run through this flow — a human who asks in their own words for their app to go live — read *First run: take the app live* before step 1: it is the opening, and every rule in it holds for the rest of the session.
## First run: take the app live
When the human first asks for their app to go live, this is the opening, before the numbered flow below. It is short on purpose: the first run is where agents have stalled, and length is what buries it.
1. **Check the connection before anything else.** Call `projects`: an answer means the host's connection to Tofu works, and it lists the apps this account already has, so an update goes to the app the human means rather than to a new one. When it answers that the connection is missing or has expired, that goes to the human on its own — the approval is theirs, on Tofu's page — and nothing else happens until it is done.
2. **Read the code you have.** Where the app's files are in front of you, identify the app root and read it — the manifest, the framework config, the README. Tofu reads the rest itself: never ask the human for the framework, the entrypoint, the package manager or a variable's name, and never for a value.
3. **Then ask at most two questions, in one message, each with a default.** One is usually enough. Phrase every question so "I don't know" is a fine answer, and say so in the message: Tofu detects the framework, sets the regions and reads the rest, so an answer is a preference rather than a requirement. A question the code or the request already answered is not a question, and a request that names everything needs none.
4. **Say what is happening before each step.** One line before each action: what is being done, what it needs from the human, what happens next. "Checking the app and putting it online" — not "we should deploy now". The human approves each step, so each one is named before it runs.
5. **End with a recap.** What Tofu set up
Preview of the first 4,000 characters. Read full instructions →
