### Discovery file http-api.json example

Source: https://soloterm.com/docs/integrations/http-api

Abridged example of the discovery file written to the app data directory when the HTTP API server starts. Contains the bearer token, bound port, base URLs, process ID, and a machine-readable catalog of endpoints with schemas.

```json
{
  "schemaVersion": 3,
  "apiVersion": "1",
  "appVersion": "1.2.3",
  "origin": "http://127.0.0.1:24678",
  "baseUrl": "http://127.0.0.1:24678",
  "apiBaseUrl": "http://127.0.0.1:24678/api",
  "endpointBaseUrl": "http://127.0.0.1:24678",
  "port": 24678,
  "token": "…",
  "pid": 12345,
  "capabilities": ["project_list", "process_spawn", "todo_create", "…"],
  "endpoints": [
    {
      "method": "GET",
      "path": "/api/projects",
      "authentication": "bearer",
      "url": "http://127.0.0.1:24678/api/projects",
      "queryParameters": ["…"],
      "responseSchema": {}
    }
  ]
}
```

--------------------------------

### solo projects usage examples

Source: https://soloterm.com/docs/cli/projects-and-processes

Practical examples of the `solo projects` commands: create a project from an existing path, list projects, rename with a display name and clear it, and delete a project while stopping running processes.

```bash
# Register a project and list what exists
solo projects create my-app ~/Code/my-app
solo projects list

# Give project 3 a friendlier display name, then clear it
solo projects rename 3 "My App (staging)"
solo projects rename 3 --clear

# Delete project 3 even if processes are running
solo projects delete 3 --confirm-stop-running
```

--------------------------------

### Placeholder syntax example

Source: https://soloterm.com/docs/prompt-templates/placeholders

Example of a template body with two placeholders, {{ticket_id}} and {{audience}}, that Solo will prompt for at insert time.

```text
Please review {{ticket_id}} and summarize the changes for {{audience}}.
```

--------------------------------

### Procfile example with web and worker commands

Source: https://soloterm.com/docs/projects/command-auto-detection

Example of a Procfile.dev or Procfile content. Each valid non-comment 'name: command' entry becomes a command suggestion. Blank lines, comments, malformed entries, and entries with empty name or command are skipped.

```plaintext
web: node server.js
worker: node worker.js

```

--------------------------------

### POST /api/projects/{projectId}/start-all

Source: https://soloterm.com/docs/integrations/http-api

Starts all command processes in a project.

```APIDOC
## POST /api/projects/{projectId}/start-all

### Description
Starts all command processes in a project.

### Method
POST

### Endpoint
/api/projects/{projectId}/start-all

### Parameters
#### Path Parameters
- **projectId** (integer) - Required - The ID of the project.

### Response
#### Success Response (200)
- **ok** (boolean) - Indicates success.
- **requestId** (string) - Unique request identifier.
- **data** (object) - Contains action-named arrays: `started`, `stopped`, `restarted`, `skipped`, and `errors`.

#### Response Example
{
  "ok": true,
  "requestId": "req-…",
  "data": {
    "started": [1, 2],
    "stopped": [],
    "restarted": [],
    "skipped": [],
    "errors": []
  }
}
```

--------------------------------

### Install Solo CLI on POSIX shell

Source: https://soloterm.com/docs/cli/overview

Creates ~/.local/bin if needed, symlinks the bundled CLI binary to ~/.local/bin/solo, and runs the installed command's --version check. Solo fills in the correct bundled binary path. Add ~/.local/bin to PATH if the shell cannot find solo. The installed command is a symlink, so it stays current automatically when Solo updates.

```bash
mkdir -p "$HOME/.local/bin"
ln -sf /path/to/bundled/solo-cli "$HOME/.local/bin/solo"
"$HOME/.local/bin/solo" --version

```

--------------------------------

### Bulk command operations with solo commands

Source: https://soloterm.com/docs/cli/projects-and-processes

Use these commands to manage all configured command processes for a project at once. start-all and restart-all only start commands the project trusts, while stop-all stops every running command process. The output reports which commands were started, skipped, or failed.

```bash
solo commands start-all --project-id <id> [--json]
solo commands stop-all --project-id <id> [--json]
solo commands restart-all --project-id <id> [--json]
```

--------------------------------

### Example solo.yml configuration

Source: https://soloterm.com/docs/projects/solo-yml

Shows a complete solo.yml file with a project name, icon, initials, and a single process definition. Note that auto_start and auto_restart are set to false, and env is an empty mapping.

```yaml
name: storefront
icon: assets/project-icon.png
icon_initials: SF
processes:
  Web:
    command: npm run dev
    working_dir: null
    auto_start: false
    auto_restart: false
    restart_when_changed: []
    env: {}

```

--------------------------------

### GET /api/processes/{processId}

Source: https://soloterm.com/docs/integrations/http-api

Gets a single process by its ID.

```APIDOC
## GET /api/processes/{processId}

### Description
Gets a single process by its ID.

### Method
GET

### Endpoint
/api/processes/{processId}

### Parameters
#### Path Parameters
- **processId** (integer) - Required - The ID of the process.

### Response
#### Success Response (200)
- **ok** (boolean) - Indicates success.
- **requestId** (string) - Unique request identifier.
- **data** (object) - The process object.

#### Response Example
{
  "ok": true,
  "requestId": "req-…",
  "data": {
    "id": 1,
    "kind": "command",
    "status": "running",
    "pid": 1234,
    "uptimeSeconds": 10
  }
}
```

--------------------------------

### GET /api/projects/{projectId}/todos/{todoId}

Source: https://soloterm.com/docs/integrations/http-api

Gets a single todo by ID.

```APIDOC
## GET /api/projects/{projectId}/todos/{todoId}

### Description
Gets a single todo by ID.

### Method
GET

### Endpoint
/api/projects/{projectId}/todos/{todoId}

### Parameters
#### Path Parameters
- **projectId** (integer) - Required - The ID of the project.
- **todoId** (integer) - Required - The ID of the todo.

#### Query Parameters
- **includeComments** (boolean) - Optional - Whether to include comments in the response.

### Response
#### Success Response (200)
- **todo** (object) - The todo object.

#### Response Example
{
  "todo": {}
}
```

--------------------------------

### Example Exported Markdown Template

Source: https://soloterm.com/docs/prompt-templates/creating-and-editing

An example of the structure of an exported template file, showing the YAML frontmatter followed by the template body.

```yaml
---
name: Refactor brief
scope: global
description: Standard multi-file refactor prompt
placeholders:
- goal
---
 
Please refactor {{goal}}.
```

--------------------------------

### Prompt to create project memory and todos

Source: https://soloterm.com/docs/workflows/handoff-long-running-work

Use this prompt to instruct the lead agent to create or reuse a Solo scratchpad as the source of truth, create todos for actionable slices, and keep the scratchpad current with goal, decisions, files, commands, tests, risks, and next action. It emphasizes not relying on chat history for anything the next agent must know.

```text
Treat this as work that may outlive this session. Create or reuse one Solo
scratchpad as the source of truth, then create todos for the actionable slices.
Keep the scratchpad current with the goal, decisions, relevant files, verified
commands and tests, risks, and next action. Use todo comments for per-slice
handoffs. Do not rely on chat history for anything the next agent must know.
```

--------------------------------

### Workspace response example

Source: https://soloterm.com/docs/integrations/http-api

Example response for workspace operations, showing the structure of a workspace object with fields like id, name, icon, color, position, timestamps, and projectCount.

```json
{
  "ok": true,
  "requestId": "req-…",
  "data": {
    "id": 2,
    "workspace": {
      "id": 2,
      "uuid": "…",
      "name": "Client work",
      "icon": "briefcase",
      "color": "blue",
      "position": 1,
      "createdAt": "2026-07-01T12:00:00Z",
      "updatedAt": "2026-07-01T12:00:00Z",
      "projectCount": 0
    }
  }
}
```

--------------------------------

### Prompt to start the Solo landing workflow

Source: https://soloterm.com/docs/workflows/build-review-land

Use this prompt to instruct the lead agent to define a landing slice, use one writer, spawn an independent reviewer, validate findings, run the quality gate, and preserve unrelated worktree changes. The prompt explicitly forbids committing or pushing unless asked.

```text
Use Solo to take this change from implementation through review.
 
First define one landing-sized slice: intended behavior, owned files, non-goals,
tests, and stop conditions. Use one writer. When focused checks pass, spawn one
independent read-only reviewer for the exact diff. Validate its findings against
the code, send accepted fixes back to the writer, run the repository's normal
quality gate, and show me the final result. Preserve unrelated worktree changes.
Do not commit or push unless I ask.
```

--------------------------------

### GET /api/workspaces

Source: https://soloterm.com/docs/integrations/http-api

Lists all workspaces with their project counts.

```APIDOC
## GET /api/workspaces

### Description
Lists all workspaces with their project counts.

### Method
GET

### Endpoint
/api/workspaces

### Response
#### Success Response (200)
- **ok** (boolean) - Indicates success.
- **requestId** (string) - Unique request identifier.
- **data** (object) - Contains the list of workspaces.

#### Response Example
{
  "ok": true,
  "requestId": "req-…",
  "data": [
    {
      "id": 2,
      "uuid": "…",
      "name": "Client work",
      "icon": "briefcase",
      "color": "blue",
      "position": 1,
      "createdAt": "2026-07-01T12:00:00Z",
      "updatedAt": "2026-07-01T12:00:00Z",
      "projectCount": 0
    }
  ]
}
```

--------------------------------

### create_project

Source: https://soloterm.com/docs/mcp-tools/project

Registers or imports an existing local directory as a Solo project.

```APIDOC
## create_project

### Description
Register or import an existing local directory as a Solo project without opening the app's onboarding UI. Optional `name` sets the stored project name, and optional `workspace_id` imports into a specific workspace.

### Method
MCP Tool

### Endpoint
`create_project`

### Parameters
#### Required Parameters
- **path** (string) - Required - Must already exist on disk.

#### Optional Parameters
- **name** (string) - Optional - Sets the stored project name.
- **workspace_id** (string) - Optional - Imports into a specific workspace.

### Response
Returns the created project. If the canonical path is already registered, returns the existing project and ignores `name` and `workspace_id`.

```