Skills
A skill is a named procedure the terminal runs when you type a slash command. It is not a prompt template and not a shortcut for typing — it is a contract about what will happen.
Why they exist
A model asked in free text to "send 500 MPRO to my bot wallet" might do exactly that, or something adjacent, and you would find out afterwards. A skill removes the guessing: the same command runs the same tools in the same order, asks for the same confirmations, and refuses under the same rules, every time.
So the model's job stops being decide what to do with your money and becomes work out which skill you meant, and with what arguments. Ambiguity is asked back rather than resolved optimistically.
How every skill behaves
Uniform across the whole library, so you never have to learn a skill's temperament:
- It prints its plan first — one line per step — and says up front if it will need a confirmation.
- It prints each tool call before its result. Nothing happens between two lines you cannot see.
--dryworks on all of them. Every read, every simulation, a printed account of the writes it would make, and nothing written.- A refusal names its rule. Not "cannot do that", but which limit stopped it.
Free text that clearly names a skill's intent — create me a new wallet called bot-2 — runs the same skill with the same confirmations. The commands are the contract; the sentence is a way in.
Naming
The canonical form is noun then verb: /wallet create, /account import, /bot start. The one-word forms (/createwallet) are kept as aliases, and /help lists both.
What is in the library
| Area | Examples | Notes |
|---|---|---|
| Accounts and wallets | /account create, /account import, /wallet create, /wallet list, /wallet send, /wallet label, /wallet export | Anything that reveals or moves goes through the modal, behind your password |
| Contracts | /project new, /write, /edit, /build, /test, /deploy, /verify, /call, /send | This is what makes the terminal a coding agent. /deploy simulates for gas, shows you the decoded constructor arguments, and refuses on a reverting simulation with the revert reason |
| Bots and strategies | Creating a bot from a strategy, starting and stopping it, its parameters, its paper record | See Marketplace for where strategies come from |
| Selling and buying | Listing a bot for sale, posting a request for one, fulfilling somebody's request | Both sides of the marketplace |
| Data | Prices, pools, history for backtests | |
| Portfolio | What you hold, what a bot has cost you, what it has done | Straight questions with straight answers |
| Models, help, session | Which model is assigned, /help, locking |
The guardrails underneath
Skills sit on top of rules that no skill can talk its way past:
- A private key or a recovery phrase typed into the command line is refused, and never echoed. Those go into a masked field in a modal.
- A deployment or a state-changing call shows a panel and waits for you.
- A file operation stays inside the open project. A path that leaves it is refused.
- A trade goes through the platform's router, under the policy caps you set for that wallet.
Every skill is tested three ways before it ships: the path that works, each refusal deliberately planted and observed to fire, and the dry form checked — by inspecting the filesystem and the database afterwards — to have written nothing.