---
title: CLI Management Commands
description: elevasis-sdk management commands -- project, note, acquisition, client, agent, session, queue, schedule, om, ui, and skill subcommand families
---

This page covers the domain management commands for `elevasis-sdk`. For core SDK commands (check, deploy, exec, resources, executions, describe, creds, rename), see [CLI Reference](cli.mdx).

---

## JSON-valued options

Any option that expects JSON can take inline JSON or a file reference:

```bash
elevasis-sdk queue:select <id> --action-id approve --payload @json:tmp/queue-payload.json
elevasis-sdk schedule:create --name "Weekly report" --target-resource-type workflow --target-resource-id weekly-report --schedule-config @json:tmp/schedule-config.json
elevasis-sdk project:task:save <id> --current-state "Updated" --files-modified @json:tmp/files-modified.json
```

`@json:<path>` is expanded before command parsing, so existing command handlers receive the same JSON string they would receive from an inline argument. Relative paths resolve against the Elevasis project root when the current directory is inside a project; otherwise they resolve against the current working directory. The referenced file must contain valid JSON.

Use `@json:<path>` for generated payloads, nested objects, arrays, or Windows shells. Inline JSON remains supported for small values.

### Passing JSON arguments across shells

Agents launch `elevasis-sdk` from either bash or PowerShell, so JSON quoting guidance must hold for both. A JSON argument crosses two parsers before the CLI sees it:

1. **The outer shell** (bash or PowerShell) -- decides whether embedded `"` survive.
2. **The pnpm run-script layer** -- `pnpm elevasis-sdk ...` is an npm run-script. On Windows, pnpm runs scripts through `cmd.exe /c`, which re-parses arguments. `pnpm exec elevasis-sdk` and direct bin calls do not add this layer.

Each shell fails at a different layer, so a single inline-quoting fix does not cover both.

- **bash** preserves embedded double quotes, so inline JSON survives the shell itself. The failure is the `pnpm <run-script>` wrapper's `cmd.exe` re-parse: `cmd` treats `( ) & < > | ^ %` as metacharacters, and a value containing them aborts with `<X> was unexpected at this time.` before the CLI runs. Keep inline JSON ASCII and metacharacter-free, or bypass the run-script layer with the direct exec form (`pnpm -C operations exec elevasis-sdk ...`).
- **Windows PowerShell 5.1** strips embedded double quotes when calling a native exe (`node`, `pnpm`), with or without pnpm. The stop-parsing token `--%` and backslash-escaped quotes both fail. There is no reliable inline-JSON route. PowerShell 7+ fixes this class via `$PSNativeCommandArgumentPassing = 'Standard'`.

**Cross-shell rule:** file-based input is shell-agnostic -- only a path crosses the shell boundary. Prefer `@json:<path>` (or `-f` / `--input-file` for `exec` and `request:submit`) for any non-trivial JSON, and write the file with an editor rather than a shell heredoc.

| Shell          | Inline JSON                             | Why                                           | Use instead                          |
| -------------- | --------------------------------------- | --------------------------------------------- | ------------------------------------ |
| bash           | OK if values avoid `( ) & < > | ^ %` | run-script `cmd.exe` re-parses metacharacters | direct exec form, or `@json:<path>`  |
| PowerShell 5.1 | Never reliable                          | strips embedded `"`; `--%` and `\"` both fail | `@json:<path>`                       |
| either         | n/a                                     | path arguments avoid all JSON shell escaping  | `@json:<path>` + editor-written file |

---

## elevasis-sdk project:\*

`elevasis-sdk project:*` is the canonical project-management surface. Use it for project, milestone, task, and note operations whether the caller is a human, a scripted workflow, or a slash-command router like `/project`.

This CLI family is SDK-first, but it is not semantically standalone. It operates on the same Organization OS contract that the shared delivery UI uses:

- UI manifest key: `delivery`
- Organization model System ID: `PROJECTS_SYSTEM_ID` (`platform.projects`)
- Default surface: `PROJECTS_INDEX_SURFACE_ID` (`platform.projects.index`)
- Semantic domain fields: `organizationModel.delivery`
- Core entity/capability IDs: `delivery.project`, `delivery.milestone`, `delivery.task`, `delivery.projects.view`

### Projects

```bash
elevasis-sdk project:list
elevasis-sdk project:get <id>
elevasis-sdk project:create --name "Website Refresh" --kind client_engagement
elevasis-sdk project:update <id> --status completed
elevasis-sdk project:delete <id>
```

**Behavior:**

- `project:list` filters by `--kind` and `--status`
- `project:get` returns a single project
- `project:create` and `project:update` operate on `/api/external/projects`

### Milestones

```bash
elevasis-sdk project:milestone:list --project <id>
elevasis-sdk project:milestone:create --project <id> --name "Phase 1"
elevasis-sdk project:milestone:update <id> --status completed
elevasis-sdk project:milestone:update <id> --description "Updated scope description"
elevasis-sdk project:milestone:update <id> --checklist @json:tmp/milestone-checklist.json
elevasis-sdk project:milestone:delete <id>
```

`project:milestone:update` accepts `--description` to set or clear the milestone description. Passing an empty string clears the field, matching `project:task:update --description` semantics.

Checklist updates are full replacements. Use `--checklist <json>` for small inline arrays, or `--checklist @json:<path>` for generated JSON. `--checklist-file <path>` is also supported for checklist-specific file input.

### Tasks

```bash
elevasis-sdk project:task:list --project <id>
elevasis-sdk project:task:get <id>
elevasis-sdk project:task:create --project <id> --title "Implement API"
elevasis-sdk project:task:create --project <id> --title "Implement API" --checklist @json:tmp/task-checklist.json
elevasis-sdk project:task:update <id> --status in_progress
elevasis-sdk project:task:update <id> --checklist @json:tmp/task-checklist.json
elevasis-sdk project:task:delete <id>
```

Task commands also expose agent-oriented resume state:

```bash
elevasis-sdk project:task:resume <id> [--pretty]
elevasis-sdk project:task:save <id> --current-state <text> [--files-modified <json>] [--next-steps <text>] [--key-docs <json>] [--tools <json>]
```

- `project:task:resume <id>` -- reads the task's `resume_context` JSONB; `--pretty` renders a human-readable briefing with current state, next steps, files modified, key docs, and tools used
- `project:task:save <id>` -- merges fields into `resume_context`; `--current-state` is required; all other flags are optional JSON arrays or plain text
- these commands are the CLI counterpart to `/work resume` and `/work save` style flows

Task checklist flags are also full replacements. `project:task:create`, `project:task:update`, and `project:milestone:update` support `--checklist <json>`, `--checklist @json:<path>`, and `--checklist-file <path>`. Prefer `@json:<path>` for non-trivial JSON and Windows shells because it works across JSON-valued options, not only checklist commands.

**`project:task:save` flags:**

| Flag                        | Description                               |
| --------------------------- | ----------------------------------------- |
| `--current-state <text>`  | Required. Current state description       |
| `--files-modified <json>` | JSON array of modified file paths         |
| `--next-steps <text>`     | Next steps description                    |
| `--key-docs <json>`       | JSON array of key doc paths               |
| `--tools <json>`          | JSON array of tool names used             |
| `--pretty`                  | Human-readable output instead of raw JSON |
| `--api-url <url>`         | Override the API base URL                 |

### Notes

```bash
elevasis-sdk project:note:list --project <id>
elevasis-sdk project:note:create --project <id> --content "Client approved scope"
elevasis-sdk project:note:create --project <id> --type agent_learning --content "Learned X"
elevasis-sdk project:note:update <id> --content "Updated status"
elevasis-sdk project:note:delete <id>
```

The `--type` flag accepts: `call_note`, `status_update`, `issue`, `blocker`, `agent_learning`. The `agent_learning` type is the canonical way for agents to record durable skill observations. Accepted values are derived from `NoteTypeSchema` in `packages/core/src/projects/api-schemas.ts` -- that schema is the source of truth; the CLI help text is generated from it to prevent drift.

### Requests

```bash
elevasis-sdk request:submit --input-file ./tmp/request-report.json
elevasis-sdk request:submit --input '{"type":"bug","category":"sdk","severity":"high","title":"..."}'
```

Submits a structured request report to `POST /api/external/requests`. The payload is validated against `CreateRequestInputSchema` before the network call.

**Payload enum values** (inline in `--help` output; sourced from `packages/core/src/requests/api-schemas.ts`):

| Field      | Accepted values                                                                       |
| ---------- | ------------------------------------------------------------------------------------- |
| `type`     | Values from `RequestTypeEnum` -- see `request:submit --help` for the current list     |
| `category` | Values from `RequestCategoryEnum` -- see `request:submit --help` for the current list |
| `severity` | Values from `RequestSeverityEnum` -- see `request:submit --help` for the current list |

**Flags:**

| Flag                        | Description                                                                   |
| --------------------------- | ----------------------------------------------------------------------------- |
| `-i, --input <json>`      | Request body as JSON string                                                   |
| `-f, --input-file <path>` | Read body from a JSON file; relative paths resolve against the project root   |
| `--pretty`                  | Human-readable output instead of raw JSON                                     |
| `--cleanup-input`           | Delete the input file after success (only files under `<projectRoot>/tmp/`) |
| `--api-url <url>`         | Override the API base URL                                                     |

**Read commands** (added once `request` cleared the 4-point promotion bar):

```bash
elevasis-sdk request:list --status open --severity critical
elevasis-sdk request:get <id>
```

`request:list` calls `GET /api/external/requests` and `request:get` calls `GET /api/external/requests/:id`. Both default to raw JSON; pass `--pretty` for human-readable output (mirrors `request:submit`). Organization scope is derived from the API key, so `request:get` returns 404 for an id belonging to another tenant -- a cross-tenant id is indistinguishable from a missing one (no existence oracle).

| Flag                  | Description                                     |
| --------------------- | ----------------------------------------------- |
| `--status <status>` | Filter list by status (`RequestStatusEnum`)     |
| `--severity <sev>`  | Filter list by severity (`RequestSeverityEnum`) |
| `--project-id <id>` | Filter list by project id                       |
| `--limit <n>`       | Max rows (1-200, default 50)                    |
| `--pretty`            | Human-readable output instead of raw JSON       |
| `--api-url <url>`   | Override the API base URL                       |

---

### Shared Flags

Most `project:*` commands support:

| Flag              | Description                                        |
| ----------------- | -------------------------------------------------- |
| `--pretty`        | Human-readable terminal output instead of raw JSON |
| `--api-url <url>` | Override the API base URL                          |

For exact required flags and accepted enum values, see the command source under `packages/sdk/src/cli/commands/project/`.

### Command Boundary

- `/project` is a convenience router to these `elevasis-sdk project:*` commands. It is not a separate project system.
- `/work` is for docs-backed in-progress task tracking and session resume, not project CRUD.
- `/external` is for managing standalone apps in `external/`, not project records inside a deployed system.
- `/adev` is for implementation, debugging, testing, and platform execution flows. Use it when you need to build or run agent/workflow code rather than update project data.

---

## elevasis-sdk note:\*

`elevasis-sdk note:*` is the agent-facing surface for pushing and reading user notes. Workflows and agents use it to surface information -- such as "deal X stalled" or "review run completed" -- directly into a user's Notes panel in the Command Center, without sending an email or notification.

Agent-written notes are private to the target user and scoped to the calling organization. The authenticated Notes panel can also create and edit org-shared notes (`visibility: 'org'`), which are visible to active members of the same organization and show creator attribution. The external SDK CLI surface exposes `GET + POST` only; `note:update` and `note:delete` are not yet available via SDK CLI. Users edit, delete, and change visibility through the right-panel view.

### note:create

Create a personal note for a user.

**Synopsis:**

```
elevasis-sdk note:create --content <text>
                         [--user <email>]
                         [--title <text>]
                         [--priority low|normal|high|urgent]
                         [--pinned]
                         [--source <id>]
                         [--api-url <url>] [--pretty]
```

**Flags:**

| Flag                      | Description                                                                               |
| ------------------------- | ----------------------------------------------------------------------------------------- |
| `--content <text>`      | Required. The note body text                                                              |
| `--user <email>`        | Target user email. Defaults to the API key owner when omitted                             |
| `--title <text>`        | Optional note title                                                                       |
| `--priority <priority>` | Priority level: `low`, `normal` (default), `high`, or `urgent`                            |
| `--pinned`                | Pin the note to the top of the panel                                                      |
| `--source <id>`         | Source identifier -- set this to the workflow or agent ID when calling from agent runtime |
| `--api-url <url>`       | Override the API base URL                                                                 |
| `--pretty`                | Human-readable terminal output instead of raw JSON                                        |

**Behavior:**

- Posts to `POST /api/external/user-notes`
- When `--user` is omitted the note is created for the identity bound to the API key (the caller)
- When `--user` is provided the platform resolves the email to a Supabase user UUID and verifies the resolved user is an active member of the calling organization before writing
- External agent-created notes are always private; org-shared visibility is a signed-in UI capability, not a broadcast CLI mode
- The `--source` flag is recorded as the `source` column in `user_notes`; agent runtimes should pass their resource ID here so users can see which workflow created the note
- Priority `normal` produces no badge in the UI; `high` renders orange, `urgent` renders red, `low` renders dimmed gray

**Examples:**

```bash
# Create a note for the API key owner
elevasis-sdk note:create --content "Deal X has stalled -- follow up needed"

# Create a high-priority pinned note for a specific user
elevasis-sdk note:create \
  --content "Review run completed for batch_abc123" \
  --user ops@acme.com \
  --priority high \
  --pinned \
  --source "report-review-workflow" \
  --pretty
```

```
  Note created
    ID:       note_550e8400-...
    Priority: high
```

---

### note:list

List notes for a user.

**Synopsis:**

```
elevasis-sdk note:list --user <email>
                       [--priority <p>] [--pinned]
                       [--limit <n>] [--offset <n>]
                       [--api-url <url>] [--pretty]
```

**Flags:**

| Flag                      | Description                                              |
| ------------------------- | -------------------------------------------------------- |
| `--user <email>`        | Required. The user whose notes to retrieve               |
| `--priority <priority>` | Filter by priority: `low`, `normal`, `high`, or `urgent` |
| `--pinned`                | Return only pinned notes                                 |
| `--limit <n>`           | Maximum number of results to return                      |
| `--offset <n>`          | Pagination offset                                        |
| `--api-url <url>`       | Override the API base URL                                |
| `--pretty`                | Human-readable terminal output instead of raw JSON       |

**Behavior:**

- Queries `GET /api/external/user-notes?user_email=<email>`
- `--user` is required -- the external GET endpoint requires an explicit user target
- Results are sorted by the platform: pinned first, then by priority (`urgent` > `high` > `normal` > `low`), then by most recently updated
- Organization scope is derived from the API key -- only notes belonging to users in the calling organization are returned

**Examples:**

```bash
# List all notes for a user
elevasis-sdk note:list --user ops@acme.com

# List only high-priority pinned notes, human-readable
elevasis-sdk note:list --user ops@acme.com --priority high --pinned --pretty
```

```
  Notes (2):

  (no title) [pinned] [high]
    ID: note_abc001
    Review run completed for batch_abc123

  Deal X stalled [pinned] [high]
    ID: note_abc002
    Deal X has stalled -- follow up needed
```

---

### Shared Flags

| Flag                | Description                                        |
| ------------------- | -------------------------------------------------- |
| `--pretty`          | Human-readable terminal output instead of raw JSON |
| `--api-url <url>` | Override the API base URL                          |

### Command Boundary

- `note:create` and `note:list` operate on the **user notes** surface -- not project notes. For project-scoped notes use `project:note:*`.
- `note:update` and `note:delete` are not yet available via SDK CLI. Edit and delete notes using the Notes panel in the Command Center.
- The shared Notes panel view (`NotesPanelView`) is exported from `@elevasis/ui/features/notes` and registered in the right-panel registry alongside Overview, Recent Executions, and Notifications.

**Implementation:** `packages/sdk/src/cli/commands/notes.ts` -- delegates to `POST /api/external/user-notes` and `GET /api/external/user-notes`

### Notes Design Contract

The following invariants govern the Notes feature and are relevant when building agents or workflows that write notes:

- **Scope:** Notes are user-scoped and organization-scoped by default. A signed-in user can mark a note as org-shared; agent-created notes stay private to the target user.
- **Org-shared visibility:** `visibility: 'org'` lets active org members see and edit the note. Only the creator can change the visibility value.
- **Sort order:** Pinned first, then by priority (`urgent` > `high` > `normal` > `low`), then by most recently updated.
- **Broadcast:** Out of scope. Agents create notes for one resolved user at a time. Broadcast is a notifications concern, not a notes concern.
- **Retention:** Notes persist until the user explicitly deletes them. There is no TTL and no dismissed state.
- **Agent creation:** One-to-one only. Pass `--source` with the agent or workflow resource ID so users can trace which resource created the note.

---

## elevasis-sdk acquisition:\*

Read-only access to acquisition lists and CRM deals. The acquisition CLI scope is intentionally read-only; mutating commands are deferred.

### acquisition:list:\*

```bash
elevasis-sdk acquisition:list:list
elevasis-sdk acquisition:list:get <id>
elevasis-sdk acquisition:list:status
```

- `acquisition:list:list` -- list all acquisition lists for the organization
- `acquisition:list:get <id>` -- get full detail for a single acquisition list by UUID
- `acquisition:list:status` -- summarize counts and progress across all lists

### acquisition:deal:\*

```bash
elevasis-sdk acquisition:deal:list
elevasis-sdk acquisition:deal:get <id>
elevasis-sdk acquisition:deal:status
```

- `acquisition:deal:list` -- list all CRM deals visible to the organization
- `acquisition:deal:get <id>` -- get a single deal record
- `acquisition:deal:status` -- summarize deal pipeline counts

**API routes:**

- Acquisition lists: `GET /api/external/acquisition/lists`, `/api/external/acquisition/lists/:listId`, `/api/external/acquisition/lists/status`
- Deals: `GET /api/external/deals`, `/api/external/deals/:dealId`, `/api/external/deals/summary`

JWT-gated routes at the original unprefixed paths remain for the Command Center. All SDK CLI calls use `/api/external/*` gated by `requireApiKey`.

**Note:** List-inspection routing lives in `/om` (Acquisition Operations dispatch). The `/acquisition` skill was folded into `/om`; all list reads still route to `elevasis-sdk acquisition:list:get <uuid>`.

**`acquisition:list:get` flags:**

| Flag                     | Description                                        |
| ------------------------ | -------------------------------------------------- |
| `--no-include-deals`     | Exclude thin deal lineage refs from the response   |
| `--deal-limit <limit>` | Maximum number of thin deal refs to include        |
| `--include-progress`     | Include processing progress aggregates             |
| `--pretty`               | Human-readable terminal output instead of raw JSON |
| `--api-url <url>`      | Override the API base URL                          |

**Shared flags (all other acquisition commands):**

| Flag                | Description                                        |
| ------------------- | -------------------------------------------------- |
| `--pretty`          | Human-readable terminal output instead of raw JSON |
| `--api-url <url>` | Override the API base URL                          |

**Implementation:** `packages/sdk/src/cli/commands/acquisition/`

---

## elevasis-sdk client:\*

Full CRUD management for client records. The `client:*` family covers create, read, update, and delete operations at `/api/external/clients`.

For complete field definitions, filter options, and relationship semantics, see the [Clients feature documentation](/technical/features/operations/clients).

**Quick reference:**

```bash
elevasis-sdk client:list
elevasis-sdk client:get <id>
elevasis-sdk client:create --name "Acme Corp"
elevasis-sdk client:update <id> --name "Acme Corp Updated"
elevasis-sdk client:delete <id>
```

**Flags:**

| Flag                | Description                                        |
| ------------------- | -------------------------------------------------- |
| `--pretty`          | Human-readable terminal output instead of raw JSON |
| `--api-url <url>` | Override the API base URL                          |

**Implementation:** `packages/sdk/src/cli/commands/` (client family)

---

## elevasis-sdk agent:\*

Read-only inspection of deployed agents.

```bash
elevasis-sdk agent:list
elevasis-sdk agent:get <id>
```

- `agent:list` -- list all agents registered for the organization
- `agent:get <id>` -- get metadata and schema for a specific agent

**API routes:** `GET /api/external/agents`, `/api/external/agents/:id`

**Flags:**

| Flag                | Description                                        |
| ------------------- | -------------------------------------------------- |
| `--pretty`          | Human-readable terminal output instead of raw JSON |
| `--api-url <url>` | Override the API base URL                          |

**Implementation:** `packages/sdk/src/cli/commands/` (agent family)

---

## elevasis-sdk session:\*

Create, operate, inspect, and export multi-turn agent sessions. Use `elevasis-sdk exec`
for one-off workflow or agent execution; use `elevasis-sdk session:*` when the deployed
agent is `sessionCapable` and needs transcript persistence across turns.

```bash
elevasis-sdk session:create <resourceId>
elevasis-sdk session:turn <id> -f tmp/turn-1.json
elevasis-sdk session:messages <id>
elevasis-sdk session:list
elevasis-sdk session:get <id>
elevasis-sdk session:end <id>
```

- `session:create <resourceId>` -- create a session for a session-capable deployed agent
- `session:turn <id>` -- execute a turn in an active session; pass input with `--input`
  or `--input-file`
- `session:messages <id>` -- export the full transcript by default; use `--page` for a
  single paginated API read
- `session:list` -- list sessions for the organization; supports filtering by resource ID, user ID, and limit
- `session:get <id>` -- get session state and metadata
- `session:end <id>` -- gracefully end an active session

**API routes:** `POST /api/external/sessions`, `GET /api/external/sessions`,
`GET /api/external/sessions/:id`, `POST /api/external/sessions/:id/turns`,
`GET /api/external/sessions/:id/messages`, `POST /api/external/sessions/:id/end`

Hard deletion is intentionally not part of `session:end`; any destructive delete surface
must be exposed as a separate explicit command.

**`session:create` flags:**

| Flag                  | Description                    |
| --------------------- | ------------------------------ |
| `--user-id <id>`    | Optional user ID for session   |
| `--metadata <json>` | Optional session metadata JSON |
| `--json`              | Output as JSON                 |
| `--api-url <url>`   | Override the API base URL      |

**`session:turn` flags:**

| Flag                        | Description                                  |
| --------------------------- | -------------------------------------------- |
| `-i, --input <json>`      | Turn input as JSON                           |
| `-f, --input-file <path>` | Read turn input from a JSON file             |
| `--json`                    | Output as JSON                               |
| `--api-url <url>`         | Override the API base URL                    |

**`session:messages` flags:**

| Flag                  | Description                                                 |
| --------------------- | ----------------------------------------------------------- |
| `--limit <limit>`   | Messages per API page; default comes from the API           |
| `--cursor <cursor>` | Message index cursor to start after                         |
| `--page`              | Fetch one API page for debugging instead of all pages       |
| `--all`               | Fetch all pages; this is the default transcript export mode |
| `--json`              | Output as JSON                                              |
| `--api-url <url>`   | Override the API base URL                                   |

**`session:list` flags:**

| Flag                   | Description                          |
| ---------------------- | ------------------------------------ |
| `--resource-id <id>` | Filter by agent resource ID          |
| `--user-id <id>`     | Filter by user ID                    |
| `--limit <limit>`    | Maximum number of sessions to return |
| `--json`               | Output as JSON                       |
| `--api-url <url>`    | Override the API base URL            |

**Shared flags (`session:get`, `session:end`):**

| Flag                | Description               |
| ------------------- | ------------------------- |
| `--json`            | Output as JSON            |
| `--api-url <url>` | Override the API base URL |

**Implementation:** `packages/sdk/src/cli/commands/session/session.ts`

---

## elevasis-sdk queue:\*

Manage HITL command queue tasks. See the [Command Queue CLI Guide](/technical/development/agent-driven-development/cli-operations) for the full command reference.

**Quick reference:**

```bash
elevasis-sdk queue:list --status pending --pretty
elevasis-sdk queue:get <id> --pretty
elevasis-sdk queue:select <id> --action-id <action-id> --pretty
elevasis-sdk queue:expire <id> --pretty
elevasis-sdk queue:status --pretty
```

**`queue:list` filter flags:**

| Flag                        | Description                                                                 |
| --------------------------- | --------------------------------------------------------------------------- |
| `--status <status>`       | Filter by status: `pending`, `processing`, `completed`, `failed`, `expired` |
| `--human-checkpoint <id>` | Filter by checkpoint ID, or `ungrouped` for tasks without a checkpoint      |
| `--time-range <range>`    | Filter by created time range: `1h`, `24h`, `7d`, `30d`                      |
| `--priority-min <number>` | Minimum priority, 1-10                                                      |
| `--priority-max <number>` | Maximum priority, 1-10                                                      |
| `--limit <limit>`         | Maximum number of tasks to return                                           |
| `--offset <offset>`       | Number of tasks to skip                                                     |
| `--pretty`                  | Human-readable output instead of raw JSON                                   |
| `--api-url <url>`         | Override the API base URL                                                   |

**`queue:select` flags:**

| Flag                 | Description                               |
| -------------------- | ----------------------------------------- |
| `--action-id <id>` | Required. Action ID to select             |
| `--payload <json>` | Optional action payload as JSON           |
| `--notes <notes>`  | Optional human decision notes             |
| `--pretty`           | Human-readable output instead of raw JSON |
| `--api-url <url>`  | Override the API base URL                 |

**Auth:** Calls `/api/external/command-queue/*` with API-key auth.

---

## elevasis-sdk schedule:\*

Manage recurring, relative, and absolute task schedules. See the [Schedule CLI Guide](/technical/development/agent-driven-development/cli-operations) for the full command reference including schedule config JSON shapes.

**Quick reference:**

```bash
elevasis-sdk schedule:list --status active --pretty
elevasis-sdk schedule:get <id> --pretty
elevasis-sdk schedule:create --name <name> --target-resource-type workflow --target-resource-id <id> --schedule-config '{...}' --pretty
elevasis-sdk schedule:update <id> --name "Updated name" --pretty
elevasis-sdk schedule:pause <id> --pretty
elevasis-sdk schedule:resume <id> --pretty
elevasis-sdk schedule:cancel <id> --pretty
```

**`schedule:update` flags:**

| Flag                         | Description                                                               |
| ---------------------------- | ------------------------------------------------------------------------- |
| `--name <name>`            | New schedule name                                                         |
| `--description <text>`     | New schedule description                                                  |
| `--clear-description`        | Remove the schedule description (mutually exclusive with `--description`) |
| `--schedule-config <json>` | Replacement schedule config JSON                                          |
| `--max-retries <number>`   | Maximum retry attempts, 0-10                                              |
| `--pretty`                   | Human-readable output instead of raw JSON                                 |
| `--api-url <url>`          | Override the API base URL                                                 |

At least one field must be provided. `--description` and `--clear-description` are mutually exclusive.

**Auth:** Calls `/api/external/task-scheduler/schedules*` with API-key auth.

---

## elevasis-sdk om:\*

Knowledge map inspection. The `om:*` (Organization Model) commands expose knowledge graph traversal via the CLI.

For the full command reference, flag details, and graph architecture, see the [knowledge:\* CLI documentation](/technical/features/knowledge/cli-and-skill).

In tenant projects, SDK read commands load `core/config/organization-model.ts` through the SDK's layout-aware TypeScript loader. The temporary bundle and dependency resolution are anchored at the package root that owns SDK dependencies, so hoisted pnpm workspaces resolve `esbuild` and `@elevasis/core` correctly. Missing org-model files still return the default model; malformed files or files with no usable export emit diagnostics. `knowledge:generate` / `om:generate` is the exception because it reads MDX and codegen inputs directly.

**Quick reference:**

```bash
elevasis-sdk knowledge:ls /by-system/sales.crm
elevasis-sdk knowledge:cat <node-id>
elevasis-sdk knowledge:graph
elevasis-sdk knowledge:search <query>
elevasis-sdk knowledge:describe <nodeId>
elevasis-sdk knowledge:skills <nodeId>
elevasis-sdk knowledge:generate
```

These are registered as `knowledge:*` subcommands on `elevasis-sdk`. Both the SDK CLI (`elevasis-sdk knowledge:*`) and the platform CLI (`elevasis knowledge:*`) call the same query functions in `@repo/core/knowledge/queries`.

### knowledge:search

Universal keyword search across the entire Organization Model (systems, resources, knowledge, ontology, roles, policies). Alias: `om:search`.

```bash
elevasis-sdk knowledge:search <query> [--limit <n>] [--kinds <list>] [--json] [--ids-only]
```

| Flag               | Description                                                                    |
| ------------------ | ------------------------------------------------------------------------------ |
| `--limit <n>`    | Max hits to return; `0` = unlimited. Default: 10                               |
| `--kinds <list>` | Comma-separated kinds filter: `system,resource,knowledge,ontology,role,policy` |
| `--json`           | Print wrapped JSON envelope `{ query, limit, kinds, count, results }`          |
| `--ids-only`       | Print one ID per line (for piping)                                             |

**Examples:**

```bash
elevasis-sdk om:search "lead gen"
elevasis-sdk om:search outreach --kinds knowledge
elevasis-sdk om:search apollo --ids-only
```

### knowledge:describe

Structured neighborhood view for any OM node ID. Auto-detects kind (system, resource, knowledge, ontology, role, policy) from the ID shape. Alias: `om:describe`.

```bash
elevasis-sdk knowledge:describe <nodeId> [--json]
```

**Examples:**

```bash
elevasis-sdk om:describe sales.lead-gen
elevasis-sdk om:describe knowledge.outreach-playbook
```

### knowledge:skills

Show callable invocations on graph neighbors for a knowledge node -- useful for discovering which actions or agent resources are linked to a given knowledge entry. Alias: `om:skills`.

```bash
elevasis-sdk knowledge:skills <nodeId> [--json]
```

**Example:**

```bash
elevasis-sdk om:skills knowledge.new-vertical-launch-playbook
```

### knowledge:generate

Generate Organization Model knowledge nodes from MDX source files. Alias: `om:generate`.

```bash
elevasis-sdk knowledge:generate [--source <path>] [--output <path>] [--flags-output <path>]
```

| Flag                      | Description                                                                                           |
| ------------------------- | ----------------------------------------------------------------------------------------------------- |
| `--source <path>`       | MDX source directory relative to project root. Default: `core/config/knowledge/nodes`                 |
| `--output <path>`       | Generated TS file path relative to project root. Default: `core/config/knowledge/_generated/nodes.ts` |
| `--flags-output <path>` | Generated knowledge flag registry path. Default: `.claude/registries/knowledge-flags.json`            |

**Example:**

```bash
elevasis-sdk om:generate
```

---

## elevasis-sdk ui:use-local / ui:use-published

Switch the `@elevasis/ui` dependency in an external project between a local tarball build and the published npm package.

**Synopsis:**

```bash
elevasis-sdk ui:use-local
elevasis-sdk ui:use-published
```

**Behavior:**

- `ui:use-local` -- builds a tarball from the local `packages/ui/` source and rewrites the project's `package.json` to point at the tarball path. Use this during active `@elevasis/ui` development to test changes without publishing.
- `ui:use-published` -- reverts `package.json` to the published `@elevasis/ui` version string and removes any local tarball reference.

Both commands install after rewriting `package.json`. The `external/_template` root scripts `ui:use-local` and `ui:use-published` are compatibility wrappers that delegate to these CLI commands.

**Implementation:** `packages/sdk/src/cli/commands/ui/ui-switcher.ts`

---

## elevasis-sdk skill:\*

Developer-facing skill tooling keeps the template `.claude/skills/` surface aligned with the live CLI catalog.

```bash
elevasis-sdk skill:scaffold <domain>
elevasis-sdk skill:check-coverage
```

- `skill:scaffold <domain>` prints a `SKILL.md` stub built from `elevasis-sdk cli --format json` for that domain. Author the curated skill at `external/_template/.claude/skills/<domain>/SKILL.md`; do not edit generated SDK reference copies directly.
- `skill:check-coverage` compares live CLI domains against `.claude/registries/skill-coverage.json`. Domains must be owned by a skill or explicitly waived.

The same coverage gate runs inside `elevasis-sdk check` when the coverage registry exists in the project root.

**Implementation:** `packages/sdk/src/cli/commands/skill/`

---

## Appendix: Domain Status

Current status of all SDK CLI domains. Domains marked `deferred` have no CLI commands yet.

| Domain      | CLI surface                                                               | API surface                                                    | Status                        |
| ----------- | ------------------------------------------------------------------------- | -------------------------------------------------------------- | ----------------------------- |
| platform    | top-level SDK commands                                                    | mixed platform APIs                                            | implemented                   |
| project     | `project:*`                                                               | `apps/api/src/projects/`                                       | implemented                   |
| knowledge   | `knowledge:*`                                                             | file/generated knowledge data                                  | implemented                   |
| creds       | `creds *` nested Commander group                                          | credentials API                                                | implemented                   |
| ui          | `ui:*`                                                                    | local project file edits                                       | implemented                   |
| request     | `request:submit`, `request:list`, `request:get`                           | requests API                                                   | implemented read/write scope  |
| error       | `error resolve`, `error resolve-execution`                                | execution error APIs                                           | partial                       |
| acquisition | `acquisition:list:*`, `acquisition:deal:*`                                | `/api/external/acquisition/lists*`, `/api/external/deals*`     | implemented read-only scope   |
| client      | `client:*`                                                                | `/api/external/clients`                                        | implemented read/write scope  |
| agent       | `agent:list`, `agent:get`                                                 | `/api/external/agents*`                                        | implemented read-only scope   |
| session     | `session:create`, `session:turn`, `session:messages`, `session:list`, `session:get`, `session:end` | `/api/external/sessions*`                                      | implemented multi-turn scope  |
| queue       | `queue:list`, `queue:get`, `queue:select`, `queue:expire`, `queue:status` | `/api/external/command-queue*`                                 | implemented                   |
| schedule    | `schedule:list`, `schedule:get`, `schedule:create`, `schedule:update`     | `/api/external/task-scheduler/schedules*`                      | implemented                   |
| skill       | `skill:scaffold`, `skill:check-coverage`                                  | local CLI catalog and `.claude/registries/skill-coverage.json` | implemented developer tooling |
| content     | none                                                                      | not scoped here                                                | deferred                      |
| seo         | none                                                                      | not scoped here                                                | deferred                      |
| monitoring  | none                                                                      | not scoped here                                                | deferred                      |

### Promotion Criteria

A domain should meet all four criteria before gaining a `*:list` / `*:get` surface in the SDK CLI:

1. The domain has DB-backed state with tenant scoping.
2. External SDK tenants have a plausible read or operation need.
3. Operators repeat the same query pattern often enough that ad-hoc DB reads are becoming workflow surface.
4. There are at least three concrete use cases.

---

**Last Updated:** 2026-05-19
