--- 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:

```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 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 ex

--- 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:

```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 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 ex

--- 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:

```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 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 ex

--- 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:

```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 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 ex