Develop with your Twin
Use an agent for implementation setup
Copy the controlled operator prompt for browser onboarding and CLI verification.
This page is for an implementation team with authority to prepare an organisation. End users should copy the shorter connection prompt.
The CLI is deliberately a read interface: it lists channels and queries the Twin. Connection setup, business review, publication, and activation remain in the authenticated browser and operator surfaces.
Before you copy
Confirm that you have:
- the organisation's Twin workspace address;
- access to the approved Twin CLI package;
- an agreed first business outcome and source list; and
- an accountable person for sign-in, source consent, business review, and activation.
Do not place access tokens, client secrets, passwords, cookies, or provider credentials in the prompt.
Help me prepare and verify my organisation's Twin.
Approved details:
- Twin workspace: `https://<workspace>`
- Business goal: `<agreed-first-outcome>`
- Approved sources: `<source-list>`
- Node.js 20 or newer for the public Twin CLI
Safety and control rules:
1. Use my existing authenticated browser for setup. Do not request SSH,
Tailscale, server credentials, copied cookies, API keys, or pasted tokens.
2. Inspect before changing anything and preserve unrelated configuration.
3. Show every person-owned checkpoint and wait for explicit confirmation.
4. Never claim a source is ready until the Twin reports ready after a real
verification.
5. Never approve discovered business meaning, publish it, or activate it on a
person's behalf.
6. Do not use direct database or server access to create customer state.
In the browser:
1. Open the organisation's Twin workspace using my existing signed-in browser
profile.
2. Follow the visible onboarding and connection steps for only the approved
sources.
3. Pause for provider consent, business review, publication, and activation
whenever the product asks for a person.
4. Verify the final connection and activation state from the rendered product.
After browser setup, verify read access with the official CLI:
1. Read https://docs.mlx.systems/docs/connect/cli and use the live guide if
installation, sign-in, or a command is unclear. After installation, treat
`twin help --json` as the exact contract for that installed CLI version.
2. Run `command -v twin`. If it is missing, follow the official CLI guide and
install the public GitHub Release globally. Do not request a GitHub account
or token, use `npx`, add a project dependency, use `sudo`, or install an
unofficial package.
3. Verify `command -v twin` and `twin help --json` work outside this repository.
If the binary is not on the persistent user `PATH`, fix that without
overwriting unrelated shell configuration and tell me to restart this
agent.
4. Run `twin login` and let me finish browser sign-in.
5. Run `twin status --json` and `twin organisations --json`. Tell me the current
organisation and ask me which one to use if several are available. Switch
with `twin organisations --use` without another login and confirm it with
`twin status --json`.
6. Run `twin channels --json` for the selected organisation.
7. Inspect the relevant channel with
`twin channels --channel <channel-id> --json`.
8. Ask a natural question with
`twin query --channel <channel-id> --question "<question>" --json`.
9. Use `--intent-file` only for a typed records, aggregate, or saved-view intent
built from inspected IDs and fields. Never submit raw SQL or guess
internal product or relation names.
10. Add records or publish view updates only if I approve the exact mutation.
Use `--allow-write`; never weaken a rejected or conflicting write.
11. If I provide or confirm feedback, submit it with `twin feedback` and attach
the routed query ID when relevant. Never infer feedback on my behalf.
Finish by reporting:
- the connection and activation state actually visible in the browser;
- the accessible channels returned by the CLI;
- the query, task, and session IDs for the routed verification; and
- every remaining action that belongs to a person or organisation owner.Operator authority remains bounded
Access to setup surfaces does not transfer business approval to the agent. Shared and production decisions still require the accountable person and the evidence required by the activation gate.