CAPABILITY · LIBRARY
A versioned library your agents can read before they spend
Every compiled skill is stored per tenant with a version and a run contract — the params it takes, the secrets it fills, and whether your stored auth is ready for its host.
GET /api/v1/skills · GET /api/v1/catalogCapability
Inside skill library & catalog
As your agents work, they accumulate compiled skills. The library keeps them per tenant, versioned and individually runnable. The catalog goes one step further: for each skill it publishes the run contract — the parameters a call must supply, the secrets the path will fill, and whether the credentials for that host are actually in place — so an agent can decide whether a run will work before it pays for one.
Versioned by name
A compile upserts a version on a stable name. Runs record which version executed, so "what program ran on Tuesday" has an answer.
A machine-readable run contract
GET /api/v1/catalog returns each skill with the params it needs and the secrets it fills — the difference between an agent guessing at arguments and an agent knowing them.
Auth readiness per host
The catalog reports whether the host has a usable login (mode, ready, and what is missing), so an agent can send the user a connect link BEFORE it burns a run on a credential_missing failure.
Runnable from any surface
A skill is a first-class object: replay it over REST, over the MCP server with run_skill, or from the dashboard. There is no goal to re-state.
How it works
The mechanism, in execution order
4 stages, in the order the runtime performs them — not a summary of them.
- 1CompileA successful compile persists the skill under a name, with an inferred param list and an intent embedding.
- 2ListGET /api/v1/skills returns this tenant's skills. The list is read from the control plane, not the engine, so it is tenant-scoped by construction.
- 3Read the contractGET /api/v1/catalog adds the params, the secrets and the per-host auth readiness for each skill.
- 4Run itPOST /api/v1/skills/{name}/run with a target and the params the catalog named.
In practice
A call you can paste and run
The catalog is what an agent reads before it spends: the arguments a skill needs, and whether the login for its host is already in place.
curl "https://twin-browser.com/api/v1/catalog?host=app.example.com" \
-H "Authorization: Bearer $TWIN_API_KEY"
# {
# "count": 2,
# "host": "app.example.com",
# "skills": [
# {
# "name": "export-invoices",
# "version": 3,
# "params": ["month"], // → {{param:month}} in the path
# "secrets": ["EXAMPLE_PASSWORD"],
# "auth": { "mode": "session", "ready": true, "missing": [] }
# }
# ]
# }- Compiledone
- Listrunning
- Read the contractqueued
- Run itqueued
What it costs, how to switch it on
Priced from the same rate card the API serves
Every credit figure on this page is read from the rate card behind GET /api/v1/pricing — it is not typed into the copy, so it cannot drift from what you are billed.
Free to list · 50 credits to compile
Listing the library and reading the catalog cost nothing — they are control-plane reads that reserve no credits. A compile bills a 50-credit floor, settled higher-of against the metered model cost of the discovery it ran. A replay of what it produced bills 1 credit.
Turning it on
- 1Create an API keyA key from the dashboard carries the skills:read and skills:write scopes by default.
- 2Compile your first skillPOST /api/v1/skills with { target, goal, as } or { url, prompt, success, as }.
- 3Expose the catalog to your agentOver MCP the same data is the list_catalog tool, so a model can read the contract as part of its own planning.
- 4Pin what mattersRecord the version a run reported when you need a known-good program, and re-compile deliberately rather than by accident.
At a glance
The contract, in the fewest rows that say it
| Property | Twin Browser |
|---|---|
| List | GET /api/v1/skills |
| Contract | GET /api/v1/catalog (optional ?host=) |
| Compile | POST /api/v1/skills |
| Replay | POST /api/v1/skills/{name}/run |
| Scope | Per tenant, default-deny RLS |
| Surfaces | REST · MCP · dashboard |
Limits
Where it stops, and what it deliberately does not do
A capabilities page with no limits section is a brochure. These are the ceilings, the defaults that will surprise you, and the things this capability is not.
Limits and defaults
- The library is tenant-scoped. There is no cross-tenant listing — the shared pool is reached through GET /api/v1/library instead.
- A skill is addressed by name. Two compiles under the same `as` produce two versions of one skill, not two skills.
- The catalog reports auth readiness from stored credentials and sessions; it cannot know that a stored session has been invalidated by the site since the last run.
- Skills compiled before the embedding step succeeded are runnable by name but invisible to dispatch until the next compile.
What it does not do
- It is not a marketplace. You cannot publish a skill for another tenant to install by name — cross-tenant reuse happens only as a sanitized corpus adapt.
- It does not store your credentials. The catalog names the secrets a skill fills; the values live in the vault and never appear in the listing.
- It does not version by content hash. A recompile bumps the version whether or not the path changed.
- It does not run anything on its own. The library is inert until you call a skill or dispatch a goal.
FAQ
Questions about skill library & catalog
Can I run a skill without stating a goal?
How does an agent know what arguments a skill takes?
What does auth readiness actually check?
Do versions roll forward automatically?
Keep reading
The rest of the platform
The capabilities this one works with, the tools that expose it, the guides that use it end to end, and the vocabulary behind it.
Deterministic replay
A successful run is minimized into a named, versioned skill — an ordered action path with its variable parts lifted out — and replaying it is a program, not a prompt.
Semantic dispatch cache
A re-phrased request is embedded, vector-matched against the skills you have already compiled, and replayed deterministically — so the second ask and every one after it skips the planner.
Connected accounts & handoff
Mint a single-use link, your end user completes the sign-in in a hosted browser, and the captured session makes every later run already logged in — with no password anywhere.
Tools that expose it
Related reading
Put your agent to work. Keep the decision.
Start free. Hand your agent a goal on a site you authorize, set the guardrails, and let the first successful run compile the skill every run after it replays.