Bring your own tools

Nothing in Chrysalis is only reachable from the built-in agent. Your whole Chrysalis is a folder of plain files under git, so the editor and coding agent you already use work on it directly.

#Find the workspace

Open a terminal — any terminal, anywhere — and run:

chrysalis workspace

Chrysalis makes itself a command the first time it starts, so there is nothing to install. If you started it just now, open a new terminal: one already running has not re-read your PATH.

Don't want it? chrysalis uninstall-cli removes it, and it stays removed.

It prints the workspace folder, the address the engine is serving on, and the apps inside it. This works the same on every install — a downloaded build keeps its data in your app-data folder rather than beside the program, which is the only reason it is hard to find by hand. If you have more than one account, add --user <name>.

Point your editor or coding agent at that folder and work normally. Saves reach open pages on their own: a change under an app's data/ shows up in about a second, and a change under its src/ rebuilds in your browser. There is nothing to restart.

#What it will find

AGENTS.md — the workspace contract: the layout, what belongs where, and the rules. It is written for whatever agent reads it, not just the built-in one.
apps/<id>/ — src/ for the UI, plugins/ for backend behavior, data/ for everything the app stores. Each app carries its own AGENTS.md too.
notes/ and commands/ — your plans and your reusable prompts. The built-in agent reads both, so anything you leave there reaches it as well.
A git repository, already set up. Your edits stay pending until you commit them; if an app request lands first, Chrysalis commits them for you under an out-of-band: label so nothing is ever lost.

#Drive the engine from a terminal

Files cover most work, but some things only the running engine knows — whether an app built, what its page logged, what models are connected. One command reaches all of it:

chrysalis api GET  /v1/apps
chrysalis api GET  /v1/apps/roleplay/build
chrysalis api POST /v1/apps/roleplay/build '{}'
chrysalis api GET  /v1/agent/commands

It calls the API of the Chrysalis running on this machine, as your account, and prints what comes back. Anything the app can do, this can do — it is the same API the shell uses.

Sending a body? Pipe it. Shells, and Windows especially, chew on quotes inside a JSON argument; a pipe carries the bytes untouched. Chrysalis checks the body before sending and tells you if your shell got to it first.

echo '{"persona":"Prefer small diffs."}' | chrysalis api PUT /v1/settings/persona

It only works locally and only for someone who can already read the data folder, so it grants nothing that running the command did not.

#Your prompts, in the composer

Put a markdown file in commands/ and it becomes a / command in the agent's composer. review.md becomes /review, its first line is the description in the menu, and picking it drops the text into the box so you can add to it before sending. It is whatever you would have typed, saved.

Typing @ in the composer picks a file out of the workspace, so you can name one instead of describing it.

#Where the line is

The built-in agent's command shell runs in a sandbox in your browser, not on your computer: it has no node, no npm, no native programs, and it cannot see outside the workspace. That is deliberate, and it is why it cannot run your test suite or your build. Your own tools have none of those limits — that is the reason to bring them.