---
name: kb-labs-explore
description: Use when the user wants to know what is installed in their KB Labs project — which services, plugins, commands are available, what is configured, where things live. Do not use for general code search (use Grep) or for finding file paths the user already knows.
user-invocable: true
---

# Explore a KB Labs Installation

Help the user discover what is installed and configured in their KB Labs project.

## Step 1: Show install status

```bash
kb-create status
```

This prints the platform version, the bound project directory, and the selected
services and plugins.

## Step 2: Show project configuration

The user-editable project config lives at `.kb/kb.config.jsonc`. Read it and
summarise:

- Which services are enabled
- Which plugins are enabled
- Any custom adapter or LLM settings

Do not parse `.kb/kb.config.json` (the platform-internal one) — that is
auto-generated runtime state and may change format.

## Step 3: Discover available commands

```bash
pnpm kb --help
```

This lists all command groups (e.g. `mind`, `qa`, `marketplace`, `workflow`,
`commit`, `agent`). For details on a group:

```bash
pnpm kb <group> --help
```

For a single command:

```bash
pnpm kb <group>:<command> --help
```

## Step 4: Discover services

```bash
pnpm kb-dev status
```

Service states: `alive` / `starting` / `failed` / `stopping` / `dead`.

For machine-readable output (when piping into other tools):

```bash
pnpm kb-dev status --json
```

To see the service registry (definitions, ports, dependencies), look at
`.kb/devservices.yaml`. Do not edit this file unless the user explicitly asks —
it is the source of truth for the dev environment.

## Step 5: Discover installed plugins

```bash
pnpm kb marketplace plugins list
```

To see which entities the marketplace knows about (plugins, adapters, etc.):

```bash
pnpm kb marketplace list
```

The marketplace lock file at `.kb/marketplace.lock` records explicitly installed
entities (it is never auto-populated).

## Step 6: Discover routes (HTTP services only)

If a REST/Workflow/Gateway service is running:

```bash
curl http://localhost:5050/api/v1/routes      # rest-api
curl http://localhost:7778/openapi.json       # workflow-daemon
curl http://localhost:4000/openapi-merged.json # gateway aggregated
```

Or open `/docs` on each port for a Swagger UI.

## Step 7: Where things live

A standard KB Labs project has:

| Path | Purpose |
|---|---|
| `.kb/kb.config.jsonc` | User-editable project config |
| `.kb/devservices.yaml` | Service definitions for kb-dev |
| `.kb/logs/tmp/<service>.log` | Service logs |
| `.kb/tmp/<service>.pid` | Service PIDs (managed by kb-dev) |
| `.kb/marketplace.lock` | Installed marketplace entities |
| `.claude/skills/kb-labs-*` | Managed Claude Code skills |

Do not list or read files under `node_modules/@kb-labs/` unless the user
specifically asks — they are implementation details of the installed platform.

## Important rules

- The user-facing config is `.kb/kb.config.jsonc` (with comments). The other
  file `.kb/kb.config.json` is internal — read it only if you have a reason.
- Services should always be inspected via `kb-dev`, not via raw `ps` / `lsof`.
- For semantic code search of the user's own code, use Grep — Mind RAG is a
  platform-internal tool that is only available inside the kb-labs monorepo
  itself.