crystalline-provisioning

Crystalline Provisioning

A domain can ship the tools its knowledge depends on - skills, commands, agents and MCP servers - into the person's coding harnesses. The person decides; you do the legwork and show each step first.

Before you start

Call list_domains and take the domain's path. Stop and say why when the domain is virtual or when that path does not exist on the machine your shell sees: the server then runs elsewhere, and the person provisions with crystalline provision on their own machine. Call provision with action: "status"; if it lists no harness, the person runs crystalline install <harness> first. Call origin_status: if the domain has a team origin, choose the location from "Team domains" below. If origin_status is not among your tools, or refuses because collaboration is off, the domain is local; do not turn collaboration on.

Choose where the tools live

For a local domain the tools live in a git repo beside the domain folder, by default <domain-folder>-tools, declared from the MANIFEST as ../<domain-folder>-tools/<kind>. If the person names an existing repo, propose git clone <url> <path>; for a new one, propose git init <path>. Show the exact path and command, then stop: end your turn and run it only after the person says yes.

Lay out the folders

Create one folder per kind, and only the kinds the person will use:

• skills/<name>/SKILL.md with frontmatter name equal to the folder name and a one-line description. Scripts and references inside the skill folder ship with it.
• commands/<name>.md or commands/<namespace>/<name>.md, frontmatter optional (description, argument-hint).
• agents/<name>.md with frontmatter name and description; the body is the agent's instructions. Write agents in markdown, never x.md beside x.toml.
• mcps/<name>.json, a JSON object with name and a server object: stdio as command, args and env, HTTP as "type": "http", url and headers.

{ "name": "tide-tables", "server": { "command": "tide-mcp", "args": ["--stdio"] } }