valet

name

valet

description

Use when the user wants to manage Valet agents, channels, connectors, organizations, or environment variables (secrets and plain config) via the valet CLI. Handles creation, deployment, linking, teardown, and all multi-step workflows. Also use when asked to "create an agent", "deploy an agent", "design an agent", "build me an agent that...", "create a connector", "set up a webhook", or anything involving the Valet platform or any request to create and deploy AI agents. Also use when asked to "learn from this session", "capture this workflow", "save this as an agent", "make this repeatable", or when writing SOUL.md files.

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:

curl -fsSL https://valet.dev/install.sh | sh

On Windows, run the official installer in 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:

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"