Customize
What a user can extend for themselves, and where the owner's settings show through.
/dashboard/customize is a single screen with five tabs. It is the part of the product where a user adds
capability rather than using it, and it is the screen an owner is most often asked about.
The five tabs
| Tab | What it is |
|---|---|
| Skills | The skills available to this account: the installation's, and their own |
| Templates | Starter projects, filtered by what the plan unlocks |
| Deploy | Where this account is allowed to publish, and what has been published |
| Connectors | GitHub, Vercel, Supabase, MCP servers and anything else the installation offers |
| Backend | The services a project can be given, such as a managed database |
A skill has its own page, /dashboard/customize/skills/<id>, listing its files: the ones that came with the
installation, and the ones this account added.
What the owner controls, and what the user controls
| Thing | Owner's screen | User's screen |
|---|---|---|
| Which skills exist | Intelligence → Skills | Customize, Skills |
| Which plans may use a skill | Intelligence → Skills | Effect only, in what they can see |
| Starter templates | Content → Templates | Customize, Templates |
| Which integrations are offered | Platform → Integrations | Customize, Connectors |
| Which targets can be deployed to | Platform → Deployments | Customize, Deploy |
| Which databases can be given | Platform → Databases | Customize, Backend |
The pattern is worth stating plainly, because it is the shape of the whole product: the panel decides what exists, and the user decides what to use. A card whose integration the owner has not registered is disabled with the reason, rather than a button that fails.
Connecting something
Open Connectors
Each card is either offered or disabled, and a disabled one says why. GitHub is the card that needs the installation's own connect application to exist first: see the GitHub connect application.
Authorise
The provider's own screen asks, and the answer comes back to the installation. A token that comes back is sealed with the installation's key and stored against that account alone.
Use it
A connected provider shows up where it is useful: GitHub beside the workbench and in the deploy panel, a database in the Backend tab, an MCP server in what the assistant can call.
Disconnect when you are done
Disconnecting deletes the stored token. Nothing else about the account changes, and reconnecting is the same two clicks.
Tokens belong to a person, not to the installation
A connected token is used only for the account that connected it, and the owner cannot read it or use it. That is what makes it safe to let users connect their own accounts to an installation somebody else runs.
When a tab looks thin
| What you see | What it means |
|---|---|
| No templates | None are published: Content → Templates, and check the plan's access |
| No skills beyond the bundled ones | The installation ships a set, and the owner adds more in Intelligence → Skills |
| A connector card disabled with a reason | The integration is not registered, and the reason names what is missing |
| No deploy targets | Platform → Deployments has no target with working credentials |
| Backend is empty | No database provider is configured, so there is nothing to offer |