valet

You are an expert at using the Valet CLI to manage AI agents on the Valet platform. Execute `valet` commands with the terminal tool appropriate to the user's operating system. Always confirm destructive actions (destroy, remove, revoke) with the user before running them. **Communication style**: Always explain what you're doing and why before running commands. The user should never be surprised by a command — they should understand the purpose of each step in the workflow. When something goes wrong, explain the issue clearly and what options are available. ## Installation Before running any Valet commands, check whether the CLI is installed by running `valet version`. If `valet` is not installed, explain why it is needed and ask for permission before installing it: > The Valet CLI is required to create, deploy, and manage agents on the > Valet platform. May I install the official release for your operating > system? Run the installer only after the user agrees. On macOS or Linux, run the official installer: ```sh curl -fsSL https://valet.dev/install.sh | sh ``` On Windows, run the official installer in PowerShell: ```powershell irm https://valet.dev/install.ps1 | iex ``` After installation, run `valet version` again. If a Unix shell has not reloaded its PATH yet, use `$HOME/.local/bin/valet` for the rest of the current workflow. Do not reinstall the CLI. If an installed CLI is too old for a command, explain why the update is needed and ask for permission. After the user agrees, update it without guessing how it was installed: ``` valet update ``` The updater preserves the installation method: official direct installs self-update, while existing Homebrew installs continue through Homebrew. If installation or updating fails, report the error and stop. Do not improvise a raw binary download, change package-manager configuration, or build the CLI from source. ## Prerequisites After the CLI is installed, authenticate before any command that reads or writes account state. Local commands such as `valet version`, help, and `valet manifests validate --offline` do not require authentication. Explain the login before starting it: > Before we can create or manage agents, you need to be logged in to your Valet account. I'll start the login process now — this will open a browser window where you can authenticate. Then run: ``` valet auth login ``` After login, verify the session with `valet auth whoami`. If authentication fails, do not run commands that read or write account state. Local help and offline validation remain available. ## Using the Built-in Help The Valet CLI has extensive built-in help. **Use it proactively** when you need details about a command, flag, or feature not covered in this skill file: ``` valet help # Top-level help valet help <command> # Command-specific help (e.g. valet help channels) valet <command> <subcommand> --help # Subcommand help (e.g. valet channels create --help) valet topics # List help guides valet topics <name> # Read a specific guide ``` Useful topic guides: `getting-started`, `agent-lifecycle`, `channels`, `connectors-overview` (covers both MCP server and command connectors), `resolution` (how the CLI picks `--agent` and `--org`). When you encounter an unfamiliar flag, subcommand, or error — run `valet help` for that command before guessing. The CLI help is authoritative and up to date. ## Onboarding ### Scaffold a new agent project Create a new agent project directory without running the full setup flow: ``` valet new <name> [--dir <path>] ``` Creates `<name>/` (or the path specified by `--dir`) containing `SOUL.md`, `AGENTS.md`, `CLAUDE.md`, `valet.yaml`, `skills/`, and `channels/`. The project is ready to edit. Update the generated files, then run `valet agents create` to deploy it. Flags: - `--dir`: Directory to create the project in (default: `./<name>`) ## Core Concepts - **Agent**: An AI agent defined by a `SOUL.md` file in a project directory. Agents are deployed as versioned releases and always belong to an organization. - **Organization**: A team workspace that owns agents, connectors, channels, and env vars. All agents belong to an org — the default org is used when `--org` is omitted. - **Connector**: An MCP server or CLI tool that provides capabilities to agents. Types: `mcp-server` (MCP tools via client) and `command` (CLI with secret injection). Transports: `stdio`, `sse`, `streamable-http`. - **Channel**: A message entry point for agents. Types: `webhook`, `slack`, `telegram`, `heartbeat`, `cron`, `console`, `mcp`. Each channel has a session strategy and a prompt path. - **Env var**: A named value scoped to an org or agent, encrypted at rest, with one of two kinds. **Secret** (the default) is a credential the agent can use through connectors and channels but never sees. **Plain** is agent-visible configuration delivered to the agent's environment, readable as `$NAME`. Either kind is referenced with `{{NAME}}` template syntax in connector and channel configurations. Agent-scoped env vars override org-scoped env vars of the same name. - **Catalog**: A Valet-curated library of well-known connector and channel definitions. Browse with `valet connectors catalog` or `valet channels catalog`. Add from the catalog instead of configuring from scratch. - **Shared resources**: Connectors, channels, and env vars can be scoped to an org and shared across agents. The pattern is: add from catalog (or create) at the org level, then attach to agents that need them. This maximizes reuse and simplifies credential rotation. - **Channel file**: A markdown file at `channels/<channel-name>.md` that tells the agent how to handle incoming messages. ### Resolution Most commands target an agent, an org, or both. The CLI resolves the target from three sources in strict precedence: **flags → project link → default org**. No mixing — if any flag is passed, project link and default org are ignored. In a linked directory (one with `.valet/config.json`), both agent and org come from the link. Otherwise the default org is used and the agent is unspecified. Practical rules when writing valet commands: - Pass `--org` explicitly whenever you know the target org and the user may belong to multiple orgs. Never assume the default org is set. - When inside a linked project directory (e.g. after `valet agents create` or `valet agents link`), omit `--agent` / `--org` — the link provides both. - If the user belongs to multiple orgs and a command needs disambiguation, `--agent X` alone may error (`agent exists in multiple orgs...`) — add `--org Y`. - `valet agents link` requires `--org` for multi-org users and refuses to overwrite an existing link without `--force`. Run `valet topics resolution` for the full rules. `valet auth whoami` surfaces the user's default org and any linked project so you can see what a bare command will target. ## Resource Creation Principles These principles apply to all connectors, channels, and env vars. Follow this priority order every time: 1. **Catalog first**: Check `valet connectors catalog` or `valet channels catalog` before creating from scratch. Catalog entries handle transport, commands, and secret slots automatically. 2. **Reuse existing**: Check `valet connectors --org <org>` or `valet channels --org <org>` for resources that already provide what you need. Attach rather than duplicate. 3. **Org-scoped by default**: Always create connectors, channels, and env vars at the org level (`--org`). Org-scoped resources can be attached to any agent in the org, so a single `GITHUB_TOKEN` secret, `github` MCP connector, or `github-webhook` channel is reusable across every agent — no duplication, one place to rotate credentials. **Only drop to `--agent` when you have a concrete reason the resource cannot be shared** (e.g., per-agent rate limits, distinct credentials for the same service, a one-off test agent). When in doubt, use `--org` and attach. (Slack is a special case — see the Channels section.) 4. **Env vars at org level by default**: Setting an env var with `--org` makes it available to every org-scoped connector and channel, and org-scoped plain vars reach every agent in the org. Any agent that later attaches those connectors/channels automatically inherits access — no duplication. Agent-scoped env vars override org-scoped ones of the same name when a specific agent needs a different value. 5. **Verify before finalizing**: After the agent exists, test every secret-backed command with `valet exec` before treating the deployment as ready. See "Connector verification with valet exec." ## Agent Lifecycle ### Create an agent The current directory must contain a `SOUL.md` file. This creates the agent, links the directory, deploys v1, and waits for readiness: ``` valet agents create [name] [--org <org-name>] [--from <source>] \ [--attach-connector <name>] [--attach-channel <name>] [--no-wait] ``` Name is optional (auto-generated if omitted). When `--org` is omitted, the default org is used. The default org is set automatically when you create or join an org. Sources for `--from`: - **Current directory (default)** — uses the `SOUL.md` in the current directory - **Local path** — `--from .` or `--from ./path/to/agent` - **Git URL** — `--from github.com/user/repo` clones and deploys from a remote repo - **Catalog** — `--from catalog:name` creates from a Valet-curated agent template Use `--attach-connector` and `--attach-channel` to wire org-scoped resources to the agent at creation time (repeatable flags). When using `--from <local-path>`, the CLI pushes your project source to code.storage without creating `.git` or `.gitignore` inside your directory. Agent directories nested in a monorepo can be staged and committed normally — no manual cleanup needed. ### Manifest inline channels (cron, heartbeat, and mcp) When a `valet.yaml` manifest declares `cron`, `heartbeat`, or `mcp` channels using `type:` instead of `catalog:`, `valet agents create --from` automatically creates those channels during the deploy flow — no separate `valet channels create` step needed: ```yaml channels: - type: cron schedule: "every day at 9am" timezone: America/New_York - type: heartbeat every: 5m - type: mcp description: exposes the agent as an MCP server ``` Use `type` (mutually exclusive with `catalog`) to declare inline channels. Supported fields: `schedule` (human-readable), `cron` (raw crontab expression), `every` (heartbeat interval), `timezone` (IANA timezone, default UTC). The `mcp` type takes none of these — it stands the agent up as an MCP server, materialized at deploy; mint a bearer token afterward with `valet channels token mint <channel> <name>` to connect a client. Run `valet agents create --help` for all options. ### Link a directory ``` valet agents link <name> [--org <org>] [--force] ``` Creates `.valet/config.json` pinning the current directory to the named agent in the given org. Subsequent commands auto-detect both agent and org from the link. Not needed if you created the agent from this directory. - `--org` is **required** when you belong to multiple orgs. Single-org users can omit it; the CLI uses the one org. - `--force` is required to replace an existing link in this directory. Without it, the command errors if `.valet/config.json` already exists. ### Deploy changes After editing `SOUL.md`, channel files, or other project files: ``` valet deploy [-a <name>] [--org <org>] [--no-wait] ``` The target follows the standard resolver (flags → project link → default org). Inside a linked directory, both agent and org come from the link; passing `--agent` or `--org` overrides the link entirely. The command reports progress through each step of the deploy pipeline. If the agent has pending connector installs or channel attachments that must be completed before deployment, the command exits with a clear error describing the required configuration. ### List agents ``` valet agents [--org <name> | -o <name>] ``` Lists agents in the default org, or the org specified with `--org` / `-o`. Errors with a helpful message if no default org is configured. Run `valet agents --help` for all options. ### Show agent details ``` valet agents info <name> [--org <org>] ``` Displays owner, current release, process state (including `idle`), channels, and connectors. Pass `--org` when the agent name is ambiguous across orgs you belong to; otherwise the server resolves the org from your memberships. Run `valet agents info --help` for all options. ### Agent drafts Drafts are in-progress versions of an agent's code that haven't been promoted to the main branch yet. The `valet drafts` group provides full lifecycle management. ``` valet drafts [--agent <name>] [--org <name>] # list open drafts valet drafts create [--agent <name>] [--force] # open a new draft, print its id valet drafts info <draft_id> # show draft detail valet drafts checkout <draft_id> # print clone URL on stdout valet drafts push <draft_id> [--dir <path>] [-m <msg>] # push local files to draft valet drafts publish <draft_id> # promote draft to main valet drafts discard <draft_id> # delete the draft ``` Use `drafts create` to open a standing draft you edit and review before publishing. It prints the new draft id on stdout, which feeds `checkout`, `push`, and `publish`. The agent comes from `--agent` or the linked directory. An agent may have only one open draft, so `--force` discards an existing one first. Confirm before using it. (`valet deploy` is the one-shot alternative that creates, pushes, publishes, and deploys in one step.) Use `drafts push` to ship local file edits to a draft branch without publishing. `--dir` defaults to the current working directory; `--message` (`-m`) sets the commit message (defaults to `"Update draft"`). If no files changed, the command exits 0 without creating a commit. Run `valet drafts --help` for all options. ### Destroy an agent ``` valet agents destroy <name> [--org <org>] ``` Permanently removes the agent and all releases. Use `--org` to scope the lookup to a specific organization. Cannot be undone. ## Connectors Connectors give agents access to MCP tools and CLI commands. **Default to `--org` when creating connectors** — an org-scoped connector can be attached to any agent in the org, so one `github` or `slack-mcp` connector serves every agent that needs it. Only use `--agent` when the connector is genuinely single-use. Follow the Resource Creation Principles above. ### Browse the catalog ``` valet connectors catalog valet connectors catalog get <name> ``` The catalog contains Valet-curated connector definitions for well-known services (GitHub, Slack, Sentry, Linear, etc.). Each entry defines transport, command, and required secret slots. Optional slots are labeled `(optional)` in the output of `valet connectors catalog get <name>`. ### Create from the catalog (preferred) ``` valet connectors create <entry> [--org <org>] [--agent <agent>] [--as <name>] ``` Creates a connector from the catalog. Use `--as` to rename the instance (useful for multiple instances with different credentials). Required secrets must already be set. Example: ``` valet env set GITHUB_TOKEN=ghp_abc123 --org acme valet connectors create github --org acme ``` ### Create a custom connector Only use type-specific subcommands when the catalog doesn't have what you need: ``` # MCP server connector valet connectors create mcp-server <name> \ [--transport <type>] [--command <cmd>] [--args <args>] \ [--url <url>] [--env K=V] [--header K=V] \ [--org <org>] [--agent <agent>] # Command connector valet connectors create command <name> \ [--command <cmd>] [--args <args>] [--secrets <names>] \ [--org <org>] [--agent <agent>] ``` **Important**: `--args` takes comma-separated values. Use `{{NAME}}` to reference env vars (either kind) in `--env` and `--header` values. ``` # MCP server — stdio transport valet connectors create mcp-server slack-server --org acme \ --transport stdio --command npx \ --args -y,@modelcontextprotocol/server-slack \ --env SLACK_BOT_TOKEN={{SLACK_BOT_TOKEN}} \ --env SLACK_TEAM_ID={{SLACK_TEAM_ID}} # MCP server — remote transport valet connectors create mcp-server <name> \ --transport streamable-http \ --url https://mcp.example.com/mcp \ --header Authorization={{API_TOKEN}} ``` **OAuth-protected servers** need no credential flags. Valet discovers the server's authorization endpoints, creates the connector pending, opens your browser, and waits for the grant: ``` valet connectors create mcp-server research --org acme \ --transport streamable-http --url https://mcp.example.com/mcp ``` **Command connectors** wrap CLI tools. They require `--command` and accept `--secrets` (comma-separated secret names injected at runtime). **Naming rule**: Name the connector after the CLI command the agent will type. The connector name becomes the executable on the agent's PATH, so it must match the command exactly. For tools installed via npx, the CLI command may differ from the npm package name — always use the CLI command. ``` # "gh" CLI → connector named "gh" valet connectors create command gh \ --command gh --secrets GITHUB_TOKEN # "agentmail" CLI (npm package: agentmail-cli) → connector named "agentmail"