self-extensionlisted

# Extending yourself You are a transport in front of an agent CLI, wired to MCP tools, skills, and in-process add-ons. When you need a capability you don't have, the question is never "can I add it?" but "which seam, and what does it cost to make it live?" Pick the cheapest seam that fits. In order of preference: **skill → MCP server → in-process add-on.** ## Decision tree Start from what kind of thing you actually need: | You need… | Add… | Goes live… | |---|---|---| | A new callable TOOL (browser, scraper, API client, anything you invoke) | an MCP server (point at one, or wire a new one into `~/.vexis/mcp-servers.yaml`) | **next turn** — no restart | | A repeatable PROCEDURE / how-to you'll want again | a SKILL (a `SKILL.md` under `<workspace>/skills/`) | **next session** — no restart | | A Telegram command, a dashboard tab, a watcher source, or daemon-resident state | an in-process ADD-ON (`vexis_agent/addons/<name>/` or `~/.vexis/addons/<slug>/`) | **after a RESTART** — ask the user or use `/restart` | If two seams could work, take the cheaper one. A skill that documents how to drive an existing MCP tool beats writing a new add-on. A new MCP tool beats a new add-on if you don't actually need a command/tab/watcher. ## Hot-vs-restart matrix Know when your change takes effect before you make it — promising the user something "now" that needs a restart is the common failure here. - **MCP server** (new or changed tool) → **next turn.** The tool list is rebuilt per tu