---
name: myagents
description: |
  myagents CLI — loads agent profiles, retrieves credentials, and manages integrations
  for AI agents. Use to load an agent's full context (identity, credentials, integrations,
  memory), push memory/files/instructions back, or run diagnostics.
  TRIGGER when: user says "load [agent name]", "use my agent", "load ark", or any agent
  slug; user asks to get credentials, tokens, or API keys from their agent; user wants to
  push memory, a file, or updated instructions to their agent; user mentions myagents
  CLI commands (load, push, doctor, credentials, init, status, hook); project has a
  .myagents/ directory or myagents.json config; user says "my agent" in the context of
  credentials or work configuration; user asks "what tools/integrations does my agent have".
  DO NOT TRIGGER when: user asks about generic AI agent frameworks (LangChain, CrewAI,
  AutoGPT, OpenAI Assistants) with no myagents context.
---

# myagents CLI Reference

You have the `myagents` CLI installed.

Use `myagents load <slug>` as the default happy path, and prefer `--json` whenever the output will be parsed by an agent or tool call.

Default `myagents credentials <provider>` output is secret-safe. Use `--json` for machine-readable secrets or `--shell` only when you explicitly need an export command.

## Fast Operating Rules

- `myagents load <slug>` once at the start, then keep working from the loaded agent.
- After your own successful CLI write on this same machine, do **not** rerun `myagents load <slug>`. The CLI already resyncs the active local cache silently.
- Run `myagents load <slug>` again only when you switch agents or need to pull changes that happened in the dashboard or on another machine.
- Agent identity is fixed after creation. The agent name and slug are the same dashed value, so if you need a different identity later, duplicate the agent and choose a new one there.
- Default load mode writes `~/.myagents/<slug>.env` for convenience. For the safer no-local-env path, use `myagents load <slug> --credential-mode on-demand` and fetch secrets just in time with `myagents credentials <provider> --json`.
- Linked GitHub skills are stored as links only. `myagents load <slug>` can prompt to download them locally, or you can force the choice with `--download-linked-skills ask|yes|no`.
- Use `myagents status --json` when you need to confirm the active agent, current access role, whether a shared team agent is writable, or which credential mode is active.

---

## Intent -> Command Quick Reference

| What the user says | Command to run |
|---|---|
| "load agent mars" / "use my ark agent" | `myagents load <slug>` |
| "load my agent without writing a local env file" / "use safer credential mode" | `myagents load <slug> --credential-mode on-demand --json` |
| "load my agent and install its linked GitHub skills" | `myagents load <slug> --download-linked-skills yes --json` |
| "set up myagents for this project" / "init an agent here" | `myagents init` |
| "check if everything is working" / "health check" / "debug my setup" | `myagents doctor` |
| "what agents do I have?" / "list my agents" | `myagents agent list --json` |
| "which agent is active?" / "am I logged in?" | `myagents status --json` |
| "get my GitHub token" / "what is my OpenAI key?" | `myagents credentials <provider> --json` |
| "open the GitHub connector login" / "connect this MCP URL" | `myagents connector open <provider> --json` |
| "save this to my agent" / "push my state" | `myagents push memory <slug> "..." --json` |
| "create a new agent" | `myagents agent create --name my-agent [--slug my-agent] --json` |
| "update my agent description/status" | `myagents agent update <slug> --description "..." --status disabled --json` |
| "disable/activate my agent" | `myagents agent update <slug> --status disabled --json` |
| "upload this file to my agent" | `myagents push resource <slug> ./file.md --type document --json` |
| "link this GitHub skill repo to my agent" | `myagents push skill <slug> --github-repo https://github.com/org/repo --json` |
| "show recent activity" / "what did I do?" | `myagents activity list <slug> --json` |
| "list integrations" / "what tools am I connected to?" | `myagents integration list <slug> --json` |
| "update my agent's name/email for forms" | `myagents identity update <slug> --set full_name="..." --set email="..." --json` |
| "install the skill" | `myagents skill install --json` |
| "auto-load when I mention ark" | `myagents hook install ark --json` |

---

## Fast Mental Model

Use myagents with this short loop: `load` once, read directly, write directly, keep working.
Do not rerun `myagents load <slug>` after your own successful CLI write on the same machine. The CLI already resyncs the active local cache for you.
Run `myagents load <slug>` again only when you switch agents, start fresh on a machine or session, or need to pull remote changes from the dashboard or another machine.
Use `myagents status --json` when you need to confirm the active agent, current access role, whether a shared team agent is writable, or which credential mode is active.

```bash
myagents load <slug> --json
myagents load <slug> --credential-mode on-demand --json
myagents load <slug> --download-linked-skills yes --json
myagents status --json
```

- Agent identity is fixed after creation. New agents use the same dashed value for both name and slug, so if you need a different slug-backed identity, duplicate the agent and create a new one.
- If the loaded agent includes linked GitHub skills, `load` can prompt to install them locally without copying those repos into myagents itself.

---

## Quick Start

Install the CLI once, authenticate once, then load any agent on demand.
For agentic use, prefer `--json` on any command whose output will be parsed.

```bash
# 1. Install CLI
curl -fsSL https://myagents.sh/install.sh | bash

# 2. Log in (one time)
myagents login --email you@example.com --password yourpassword --json

# 3. Create or link an agent for the current project
myagents init --json

# 4. Load your agent (restores env cache + skills + session)
myagents load <slug> --json

# 5. Run diagnostics any time something feels wrong
myagents doctor --json
```

- If another AI agent is handling first-time setup, give it the simple prompt: `Go to https://myagents.sh/setup and install myagents for me.`
- The `/setup` endpoint is terminal-first and machine-readable. It should be fetched as text and followed with shell tools directly.

---

## Account

After `myagents load <slug>`, `myagents status --json` includes `access_role` and `can_manage_shared_config` so an agent can tell whether the current shared session is loaded as `viewer` or `admin`.

```bash
# Create account (no browser required)
myagents signup --email you@example.com --password yourpassword [--name "Your Name"] [--json]

# Log in headless (no browser)
myagents login --email you@example.com --password yourpassword [--json]

# Log in with browser
myagents login

# Log out
myagents logout [--json]

# Show current user + active agent + expiries
myagents status [--json]
```

---

## Load an Agent

This is the main entrypoint for both humans and agents. It refreshes auth/session state, writes local cache files, and refreshes skills.
Use it at the start of work, when switching agents, or when you need to pull remote changes from the dashboard or another machine.
Do not rerun it after your own successful CLI write on the same machine — the CLI already keeps that local cache in sync.

```bash
myagents load <slug> [--json] [--silent] [--credential-mode env|on-demand] [--download-linked-skills ask|yes|no]
```

- Default `env` mode may write `~/.myagents/<slug>.env`, `~/.myagents/<slug>.connectors.json`, `~/.claude/skills/myagents/SKILL.md`, and `~/.claude/skills/<slug>/SKILL.md`.
- Use `--credential-mode on-demand` when you do not want a local per-agent `.env` file. In that mode, fetch secrets just in time with `myagents credentials <provider> --json` or `--shell`.
- If the agent includes linked GitHub skills, the default interactive mode is `ask`: `load` can prompt to download them locally into `~/.claude/skills/myagents-linked-*`. Use `--download-linked-skills yes` or `no` when you need a deterministic non-interactive choice.
- The dashboard Agent settings dialog now includes the Agent status toggle, an On-demand mode switch with a help popover, webhook controls, and API key management. When the On-demand switch is on, the next `myagents load <slug>` uses on-demand mode by default.
- If the agent is disabled in Agent settings, future CLI loads and session-backed requests fail until it is re-enabled.
- The main dashboard now presents long-lived agent context under `Knowledge & Files`, separating uploaded files, reference notes, memory notes, and skills so the saved context is easier to inspect.
- For shared team agents, the load response also persists `access_role` and `can_manage_shared_config` into the local session metadata.
- The per-agent skill version is derived from the live agent row plus its integrations, resources, and enabled policies, so the next load notices more than just agent timestamp or integration-count changes.
- Each agent is capped at 100 manual environment variables and 100 skill resources or linked GitHub skills.

---

## Init

Use this from a project root to create an agent and optionally write a local `SKILL.md` stub.
If flags are omitted, the CLI prompts for the missing values.

```bash
myagents init [--name project-agent] [--slug project-agent] [--description "..."] [--visibility private|public|unlisted] [--json]
```

---

## Doctor

Checks auth refresh, active session health, API reachability, installed skill freshness, and integration expiry for the active agent.

```bash
myagents doctor [--json]
```

---

## Agent Management

Listing and showing agents is available to both admins and viewers on shared team agents. Creating agents in a team, updating shared team agents, transferring them, or deleting them requires admin access.
Agent identity is slug-backed and fixed after creation. New agents keep the stored name identical to the slug, so if you need a different identity, duplicate the agent instead of trying to rename it.

```bash
myagents agent list [--json]
myagents agent show <slug> [--json]
myagents agent create --name agent-slug [--slug agent-slug] [--description "..."] [--visibility public|private|unlisted] [--json]
myagents agent update <slug> [--description "..."] [--status active|disabled|archived] [--visibility public|private|unlisted] [--system-prompt "You are..."] [--preferred-model claude-sonnet-4-6] [--json]
myagents agent transfer <slug> [--to-team team-slug | --to-personal] [--json]
myagents agent delete <slug> --confirm [--json]
```

---

## Credentials

In the default `env` mode, credentials are normally restored during `load`; use this command when you need to fetch one directly.
In `on-demand` mode, this becomes the primary just-in-time secret path because no local per-agent `.env` file is written.

```bash
# Secret-safe default output
myagents credentials <provider> [--label <label>]

# Machine-readable secret payload
myagents credentials <provider> [--label <label>] --json

# Explicit shell export command
myagents credentials <provider> [--label <label>] --shell
```

---

## Connectors

Use connector flows for MCP-style or native auth handshakes. Opening a connector login from the CLI is a shared-team write action, so it requires admin access.

```bash
myagents connector open <provider> [--json]
```

- If `myagents status --json` shows `access_role: viewer`, do not attempt connector login flows. Ask a team admin for admin permission instead.

---

## Push

Use `push` to write state back so it is available the next time the agent is loaded.
On shared team agents, the `push` commands are shared-write operations. Viewers can inspect and use the loaded setup, but only admins can push memory, instructions, resources, skills, or integration changes.
After a successful CLI write on the currently loaded agent, myagents silently refreshes the local cache for that same agent on the same machine. Keep working — do not immediately rerun `myagents load <slug>`.
If the change happened in the dashboard or on another machine, rerun `myagents load <slug>` to pull it locally.

```bash
myagents push memory <slug> "what you learned" [--json]
myagents push instructions <slug> --file ./CLAUDE.md [--json]
myagents push instructions <slug> --content "You are a helpful assistant..." [--json]
myagents push resource <slug> ./notes.md --type document [--json]
myagents push skill <slug> [file] [--skill-version 1.0.0] [--tool-permissions Bash,Read,Write] [--github-repo https://github.com/org/repo] [--github-ref main] [--github-path skills/my-skill] [--title my-skill] [--json]
myagents push integration <slug> openai --secret sk-xxx --env-var OPENAI_API_KEY [--label default] [--usage-notes "Use for model calls"] [--expires-at 2026-12-31T00:00:00Z] [--json]
myagents push integration <slug> agentmail --category reference --display "agent@agentmail.to" [--json]
myagents push status [--json]
```

- Use `push skill <slug> ./SKILL.md ...` to upload a local skill file into myagents, or `push skill <slug> --github-repo ...` to store only a GitHub link that can be downloaded locally later during `load`.
- Agents are capped at 100 skill resources, including linked GitHub skills.

---

## Resources

`resource list` is readable by viewers on shared team agents. Uploading or deleting shared resources requires admin access.

```bash
myagents resource list <slug> [--type document|note|file|memory|artifact|skill] [--json]
myagents resource push <slug> ./file.md [--type document|memory] [--json]
myagents resource delete <slug> <resource-id> [--json]
```

---

## Instructions

Updating shared instructions is an admin-only action on shared team agents.

```bash
myagents instructions update <slug> --file ./instructions.md [--json]
myagents instructions update <slug> --content "Updated instructions..." [--json]
```

---

## Activity

Activity is automatic audit history. `activity list` is readable by viewers on shared team agents, and there is no manual CLI command for writing custom activity entries.

```bash
myagents activity list <slug> [--limit 100] [--json]
```

---

## Integrations

`integration list` is readable by viewers on shared team agents. `integration update` and `integration delete` require admin access because they change shared setup.

```bash
myagents integration list <slug> [--json]
myagents integration update <slug> <provider> [--label <label>] [--usage-notes "..."] [--display <value>] [--status active|revoked|expired] [--is-default] [--dashboard-url <url>] [--expires-at 2026-12-31T00:00:00Z] [--json]
myagents integration delete <slug> <provider> [--label <label>] [--json]
```

---

## Identity Data

Identity fields are private agent data used for form fills, signups, and automation.
`identity show` is readable by viewers on shared team agents, while `identity update` requires admin access.

```bash
myagents identity show <slug> [--json]
myagents identity update <slug> --file ./identity.json [--json]
myagents identity update <slug> --set full_name="Agent Name" --set email="agent@example.com" [--json]
```

---

## Policies

`policy list` is readable by viewers on shared team agents. Creating, updating, or deleting policies requires admin access.

```bash
myagents policy list <slug> [--json]
myagents policy create <slug> --type hitl --name "Require Approval" --config '{"channel":"#approvals"}' [--json]
myagents policy update <slug> <policy-id> [--name "..."] [--config '{}'] [--enabled] [--disabled] [--json]
myagents policy delete <slug> <policy-id> [--json]
```

---

## API Keys

`api-key list` is readable by viewers on shared team agents so they can inspect shared inventory. Creating or revoking API keys requires admin access.

```bash
myagents api-key list <slug> [--json]
myagents api-key create <slug> --name "My Integration" [--scopes credentials,read] [--expires-at 2026-12-31T00:00:00Z] [--json]
myagents api-key revoke <slug> <key-id> [--json]
```

---

## Hooks

```bash
myagents hook install <slug> [--json]
myagents hook remove <slug> [--json]
myagents hook list [--json]
```

---

## Skill File Management

```bash
myagents skill install [--json]
myagents skill update [--json]
myagents skill show [--json]
```

---

## Teams

Use `viewer` as the default collaborator role. The CLI also accepts the legacy aliases `view`, `user`, and `member`, but `viewer` is the preferred user-facing term.
Viewers can inspect shared connectors, environment-variable inventory, and API key inventory and use shared credentials. Only admins can add, update, revoke, or remove shared connectors, integrations, environment variables, and API keys.
When an agent is loaded from a team workspace, use `myagents status --json` to confirm whether the active session is `viewer` or `admin` before attempting shared writes.

```bash
myagents team list [--json]
myagents team create --name "Team Name" --slug team-slug [--description "..."] [--json]
myagents team show <slug> [--json]
myagents team update <slug> [--name "New Name"] [--description "..."] [--json]
myagents team invite <slug> <email> [--role admin|viewer] [--json]
myagents team set-role <slug> <email> <role> [--json]
myagents team remove <slug> <email> [--json]
myagents team delete <slug> --confirm [--json]
```

---

## Fresh Machine Bootstrap

- If myagents is not installed yet on a machine, use https://myagents.sh/setup as the bootstrap URL.
- That endpoint is terminal-first plain text or markdown. Fetch it as text and use shell tools directly.
- Do not open a browser just to read the install instructions. Only open one later if the chosen auth flow truly requires it.
- The simple prompt to give another coding agent is: "Go to https://myagents.sh/setup and install myagents for me."
- The installer downloads platform binaries from `https://myagents.sh/bin/*`, so `public/bin/` must be included in every deployment.

---

## Dashboard Notes

- In the dashboard, **Connectors** open as a popup from the agent overview instead of taking over the whole page.
- Use **Connectors** for native or MCP-style connection flows, including custom remote MCP connectors added with a name, remote MCP URL, and optional OAuth client settings under Advanced settings.
- Use **Environment Variables** for raw API keys, manual service tokens, and one-off values.
- The main agent page now uses a clearer **Knowledge & Files** section instead of treating everything as one generic resources list. It separates uploaded files, reference notes, memory notes, and skills, and each item can be expanded to inspect the full contents or metadata.
- Linked GitHub skills also live under **Knowledge & Files**, but they should stay metadata-only in myagents itself. Store the GitHub URL/ref/path there, then let `myagents load <slug>` offer the local download step later.
- The older deep links for **Identity**, **Knowledge & Files**, and **Policies & guardrails** now hand off into the unified main agent page sections instead of maintaining a second, older-looking management UI. Keep that single overview surface as the source of truth.
- New agents now use one slug-safe identity field. The stored agent name and slug are the same dashed value everywhere, including the dashboard header, public URL, and `myagents load <slug>` command.
- The agent detail header includes an **Agent settings** dialog. That dialog holds the **Agent status** toggle, the **On-demand mode** switch, webhook controls, API key management, and a read-only **End-to-end encryption** coming-soon card. Agent identity is fixed after creation, so the header no longer offers rename. If the operator needs a new identity, duplicate the agent and choose a new one there. Keep On-demand mode off for the default local `.env` cache, or turn it on to make the next `myagents load <slug>` use just-in-time credential fetches by default for that agent. The planned encryption flow is per-agent: set a unique passphrase for that agent, encrypt secrets client-side before upload, then supply the same passphrase during `myagents load <slug>` so decryption happens locally.
- On shared team agents, **view-only collaborators** can inspect shared connectors, environment-variable inventory, and API key inventory and use the shared credentials, but only **admins** can add, update, revoke, or remove that shared setup.
- Dashboard API keys are now created from **Agent settings**. The raw key is revealed exactly once at creation time so it can be copied, then only the inventory metadata remains visible.
- When an agent is disabled in **Agent settings**, future CLI loads, session-backed requests, and programmatic API-key access should fail until the agent is re-enabled.
- Run `myagents status --json` whenever you need to confirm whether the currently loaded shared team session is `viewer` or `admin` before attempting a shared write.
- After a successful CLI write on the currently loaded agent, myagents silently refreshes the local env/connectors/skill cache on that same machine. Keep working — do not fall into a write-then-load loop. Run `myagents load <slug>` again only if the change came from the dashboard or another machine.
- Cap manual per-agent environment variables at **100** and cap per-agent skill resources or linked GitHub skills at **100**.
- On the personal dashboard home, **Recent Activity** lives on its own `/dashboard/activity` page instead of sharing the agents overview layout.
- On wider dashboard screens, the agents overview should settle into a clean three-card row instead of stretching each agent card too wide.
- In team views, **Team Settings** should be a visible header action beside the other primary controls, not a tiny inline text link.
- The primary dashboard, public, and auth surfaces use a monochrome visual system in **both dark and light mode**. Keep new UI work inside that palette unless there is a product reason not to, and keep the light theme close to a clean white-background / black-text Vercel-style treatment rather than a warm off-white fallback.
- The app now exposes the theme switcher in two deliberate places: a compact icon in the public marketing header and a logged-in light/dark switcher in **Settings**. Dark remains the default, but UI changes must keep both themes readable and polished rather than treating light mode as a partial fallback.
- Shared status affordances like **Active**, **Connected**, **Enabled**, onboarding-complete states, and copy-success feedback should stay monochrome too. Do not reintroduce older green success chips on dashboard surfaces.
- Menus, dropdowns, and popovers should use the shared theme tokens too. Do not hardcode dark-only menu backgrounds on dashboard overlays like the account dropdown.
- Shared form primitives should stay token-driven as well. Avoid manual `dark:` overrides on live inputs or textareas — use the same theme tokens in both modes.
- Production-facing public and auth surfaces should avoid legacy `transition-all` motion or raw `outline-none` form styling. Prefer explicit transition properties plus visible `focus-visible` treatment from the shared shadcn primitives.
- Brand assets and public brand configuration should load from the shared brand layer: keep the source files under `public/brand/`, define logos, support email, social links, and standalone theme values in `lib/brand.ts`, and render the logo through the shared `BrandLogo` component with its built-in size presets instead of hardcoding asset paths, contact URLs, or one-off sizing in individual pages.
- Main application palette changes should happen through the global CSS design tokens and utilities in `app/globals.css`, not through scattered hardcoded hex values or old accent glows in individual components. When you change shared tokens, verify both the `.dark`/default and `.light` experiences.
- When testing the local dashboard or teams visually, use `npm run dev:fixtures:seed` to create ten realistic personal agents plus a shared team with seeded collaborators and agents. Use `npm run dev:fixtures:status` to inspect the current seed state and `npm run dev:fixtures:reset` to remove all seeded fixture users, agents, team data, and vault secrets.
- In local development, a real Supabase login session should always override any older dev-bypass cookie. The bypass is only a fallback when no real user session exists.
- The human-facing docs page lives at https://myagents.sh/docs.

---

## Exit Codes

- `0` Success
- `1` Auth, session, or operational failure
- `2` Not found
- `3` Validation or usage error

---

## Rules

- Never ask the user to run commands themselves — run the CLI directly.
- Operate with this mental model: load once, read directly, write directly, and keep going.
- Prefer `--json` whenever the output will be parsed or inspected by an agent.
- Use `myagents load <slug>` as the primary happy path; it refreshes auth/session state and restores cached files.
- If `myagents load <slug>` fails with `agent_disabled`, tell the user to re-enable the agent in Agent settings before trying again.
- Default credential mode is `env`, which writes `~/.myagents/<slug>.env` with `0600` permissions for convenience.
- Each agent can save its own default credential mode from the dashboard Agent settings dialog. `myagents load <slug>` uses that saved agent preference unless you explicitly override it with `--credential-mode`.
- Use `myagents load <slug> --credential-mode on-demand` when you want the more secure no-local-env mode. That skips the per-agent `.env` cache and makes `myagents credentials <provider>` the just-in-time secret path.
- Linked GitHub skills are stored as metadata only. `myagents load <slug>` can prompt to download them locally, or you can force the choice with `--download-linked-skills ask|yes|no`.
- Successful CLI write commands already silently refresh the active loaded agent cache on the same machine, including env vars, connector metadata, and per-agent skills when the config version changed. Do not fall into a write-then-load loop after your own successful CLI write.
- Only rerun `myagents load <slug>` when you switch agents, start fresh on a machine or session, or need to pull changes that happened in the dashboard or on another machine.
- Agent identity is set once. New agents use the same dashed value for both name and slug, and renaming is disabled, so if you need a new slug-backed identity, duplicate the agent and choose a new one there.
- Default `myagents credentials <provider>` output is secret-safe; use `--json` for machine-readable secrets or `--shell` for an explicit export command.
- The CLI may cache credentials in `~/.myagents/<slug>.env` with `0600` permissions after `myagents load`.
- Global and per-agent skills live under `~/.claude/skills/` and are refreshed automatically.
- For first-time install by another AI agent, use `https://myagents.sh/setup` as the bootstrap URL. Fetch it as plain text or markdown and use shell tools directly; do not open a browser just to read the install instructions.
- The install flow downloads platform binaries from `/bin/*`, so myagents deployments must include the static assets in `public/bin/`.
- Token refresh and session renewal are automatic; do not ask the user to manage them manually.
- When you need to know whether a loaded shared team agent is writable, run `myagents status --json` and inspect `access_role` plus `can_manage_shared_config`.
- On shared team agents, viewers can inspect shared connectors, environment-variable inventory, and API key inventory and use shared credentials, but only admins can change the shared setup.
- Activity is an automatic audit trail. Use `myagents activity list <slug>` to inspect it; there is no manual CLI command for writing custom activity entries.
- In the dashboard, `Knowledge & Files` is the clearer home for uploaded files, reference notes, memory notes, and skills attached to an agent.
- Each agent can store up to 100 manual environment variables and 100 skill resources or linked GitHub skills.
- When working on myagents itself, never hardcode backend secrets in source. For local development, pull env vars with `vercel env pull .env.local`. myagents tolerates the occasional extra wrapper quotes Vercel leaves around `SUPABASE_PAT` and `SUPABASE_PROJECT_REF`, but keep local env files clean when you can.
- For myagents UI work, use shared primitives from `components/ui` and avoid duplicate component trees or raw hand-built checkbox/radio/switch/dialog controls when a shadcn/ui primitive exists.
- Keep settings affordances monochrome too: the shared question-mark help popovers and on/off switches should use the same black-and-white shadcn styling as the rest of the dashboard instead of older blue-tinted variants.