@karmaniverous/jeeves-meta-openclaw 0.13.3 → 0.15.0-0

package/dist/skills/jeeves-meta/SKILL.md

@@ -1,128 +1,102 @@
+---
+name: jeeves-meta
+description: >
+  Knowledge synthesis with jeeves-meta. Use when checking synthesis status, listing or inspecting .meta/ entities, triggering or seeding synthesis, managing the meta service, or troubleshooting stale, failed, or locked metas.
+---
+
 # jeeves-meta — OpenClaw Skill
 
 ## Overview
 
-jeeves-meta is the Jeeves platform's knowledge synthesis engine. It discovers
-`.meta/` directories via the watcher's filesystem walk endpoint (`POST /walk`),
-gathers context from co-located source files, and uses a three-step LLM process
-(architect, builder, critic) to produce structured synthesis artifacts.
+jeeves-meta is the Jeeves platform's knowledge synthesis engine. It discovers `.meta/` directories via the watcher's filesystem walk endpoint (`POST /walk`), gathers context from co-located source files, and uses a three-step LLM process (architect, builder, critic) to produce structured synthesis artifacts.
 
-Each meta entity carries a **phase-state machine** (`_phaseState`) tracking
-the state of each phase independently: `fresh`, `stale`, `pending`, `running`,
-or `failed`. The scheduler picks **one phase per tick** across the entire
-corpus (critic > builder > architect priority), enabling surgical retries of
-failed phases without re-running the full pipeline.
+Each meta entity carries a **phase-state machine** (`_phaseState`) tracking the state of each phase independently: `fresh`, `stale`, `pending`, `running`, or `failed`. The scheduler picks **one phase per tick** across the entire corpus (critic > builder > architect priority), enabling surgical retries of failed phases without re-running the full pipeline.
 
-**Requires:** jeeves-watcher ≥ 0.10.0 (provides `POST /walk` and auto
-rules-reindex on registration).
+**Requires:** jeeves-watcher ≥ 0.10.0 (provides `POST /walk` and auto rules-reindex on registration).
 
-Discovery is filesystem-based (no Qdrant dependency). The service registers
-virtual inference rules with the watcher for rendering and metadata tagging;
-the watcher's `/status` response includes `rulesRegistered` to surface
-registration health.
+Discovery is filesystem-based (no Qdrant dependency). The service registers virtual inference rules with the watcher for rendering and metadata tagging; the watcher's `/status` response includes `rulesRegistered` to surface registration health.
 
 ## Available Tools
 
 ### meta_list
-List all `.meta/` directories with summary stats and per-meta projection.
-Supports filtering by path prefix, error status, staleness, lock state, and
-disabled status. Use for engine health checks and finding stale knowledge.
-Each meta entry includes `phaseState` (`{ architect, builder, critic }`)
-showing the per-phase state.
+
+List all `.meta/` directories with summary stats and per-meta projection. Supports filtering by path prefix, error status, staleness, lock state, and disabled status. Use for engine health checks and finding stale knowledge. Each meta entry includes `phaseState` (`{ architect, builder, critic }`) showing the per-phase state.
 
 **Parameters:**
+
 - `pathPrefix` (optional): Filter by path prefix (e.g. "github/")
 - `filter` (optional): Structured filter (`{ hasError: true }`, `{ staleHours: 24 }`, `{ disabled: true }`)
 - `fields` (optional): Property projection array
 
 ### meta_detail
-Full detail for a single meta, with optional archive history. Includes
-`_phaseState` showing the per-phase state machine status.
+
+Full detail for a single meta, with optional archive history. Includes `_phaseState` showing the per-phase state machine status.
 
 **Parameters:**
+
 - `path` (required): `.meta/` or owner directory path
 - `fields` (optional): Property projection
 - `includeArchive` (optional): false, true, or number (N most recent)
 
 ### meta_preview
-Dry-run for the next synthesis candidate. Shows scope files, delta files,
-architect trigger reasons, steer status, structure changes, and the
-phase that would execute next — without running any LLM calls. Includes
-`phaseState`, `owedPhase` (the phase that would run), `inputStatus`
-(informational flags: structureHash, steerChanged, architectChanged,
-criticChanged, crossRefsDeclChanged, crossRefContentChanged), and
-`architectInvalidators` (list of reasons architect was triggered, e.g.
-`structureHash`, `steer`, `_crossRefs`, `firstRun`, `architectEvery`).
-Use before `meta_trigger` to understand what will happen.
+
+Dry-run for the next synthesis candidate. Shows scope files, delta files, architect trigger reasons, steer status, structure changes, and the phase that would execute next — without running any LLM calls. Includes `phaseState`, `owedPhase` (the phase that would run), `inputStatus` (informational flags: structureHash, steerChanged, architectChanged, criticChanged, crossRefsDeclChanged, crossRefContentChanged), and `architectInvalidators` (list of reasons architect was triggered, e.g. `structureHash`, `steer`, `_crossRefs`, `firstRun`, `architectEvery`). Use before `meta_trigger` to understand what will happen.
 
 **Parameters:**
-- `path` (optional): Specific `.meta/` or owner directory path. If omitted,
-  previews the stalest candidate.
+
+- `path` (optional): Specific `.meta/` or owner directory path. If omitted, previews the stalest candidate.
 
 ### meta_trigger
-Enqueue a synthesis for a specific meta or the next-stalest candidate.
-The synthesis runs asynchronously in the service queue; the tool returns
-immediately with the queue position. Only one phase runs per tick (the
-owed phase). Includes `owedPhase` in the response showing which phase
-will execute.
+
+Enqueue a synthesis for a specific meta or the next-stalest candidate. The synthesis runs asynchronously in the service queue; the tool returns immediately with the queue position. Only one phase runs per tick (the owed phase). Includes `owedPhase` in the response showing which phase will execute.
 
 **Parameters:**
-- `path` (optional): Specific `.meta/` or owner directory path. If omitted,
-  synthesizes the stalest candidate.
+
+- `path` (optional): Specific `.meta/` or owner directory path. If omitted, synthesizes the stalest candidate.
 
 ### meta_seed
-Create a new `.meta/` directory with a skeleton `meta.json` (containing a
-UUID `_id`). Use this to bootstrap synthesis for a new path before the
-first cycle runs. Supports optional cross-references for metas that
-aggregate context from other metas.
+
+Create a new `.meta/` directory with a skeleton `meta.json` (containing a UUID `_id`). Use this to bootstrap synthesis for a new path before the first cycle runs. Supports optional cross-references for metas that aggregate context from other metas.
 
 **Parameters:**
+
 - `path` (required): Owner directory path where `.meta/` will be created.
-- `crossRefs` (optional): JSON array of cross-ref owner paths
-  (e.g. `'["j:/path/a","j:/path/b"]'`). Written as `_crossRefs` in the
-  initial `meta.json`.
-- `steer` (optional): Steering prompt string. Written as `_steer` in the
-  initial `meta.json`.
+- `crossRefs` (optional): JSON array of cross-ref owner paths (e.g. `'["j:/path/a","j:/path/b"]'`). Written as `_crossRefs` in the initial `meta.json`.
+- `steer` (optional): Steering prompt string. Written as `_steer` in the initial `meta.json`.
 
 ### meta_unlock
-Remove a stale `.lock` file from a meta entity. Locks are created during
-synthesis and normally cleaned up automatically; use this when a synthesis
-crashed and left a lock behind.
+
+Remove a stale `.lock` file from a meta entity. Locks are created during synthesis and normally cleaned up automatically; use this when a synthesis crashed and left a lock behind.
 
 **Parameters:**
+
 - `path` (required): `.meta/` or owner directory path with a stuck lock.
 
 ### meta_config
-Query the running service configuration. Supports optional JSONPath
-filtering to extract specific settings. Sensitive fields (e.g.
-`gatewayApiKey`) are redacted.
+
+Query the running service configuration. Supports optional JSONPath filtering to extract specific settings. Sensitive fields (e.g. `gatewayApiKey`) are redacted.
 
 **Parameters:**
-- `path` (optional): JSONPath expression (e.g. `$.schedule`). If omitted,
-  returns the full sanitized config.
+
+- `path` (optional): JSONPath expression (e.g. `$.schedule`). If omitted, returns the full sanitized config.
 
 ### meta_update
-Update user-settable reserved properties on a meta entity. Use this to
-toggle `_disabled`, change `_steer`, adjust `_emphasis` or `_depth`, or
-modify `_crossRefs` — without editing `meta.json` directly on the filesystem.
+
+Update user-settable reserved properties on a meta entity. Use this to toggle `_disabled`, change `_steer`, adjust `_emphasis` or `_depth`, or modify `_crossRefs` — without editing `meta.json` directly on the filesystem.
 
 **Parameters:**
+
 - `path` (required): `.meta/` or owner directory path.
-- `updates` (required): Object with properties to set. Supported:
-  `_steer`, `_emphasis`, `_depth`, `_crossRefs`, `_disabled`.
-  Set a value to `null` to remove the property.
+- `updates` (required): Object with properties to set. Supported: `_steer`, `_emphasis`, `_depth`, `_crossRefs`, `_disabled`. Set a value to `null` to remove the property.
 
 ### meta_queue
-Queue management: list pending items, clear the queue, or abort current
-synthesis. The queue has three layers: `current` (the running phase),
-`overrides` (explicitly triggered entries), and `automatic` (scheduler-
-computed candidates). The `pending` and `state` fields provide legacy
-compatibility.
+
+Queue management: list pending items, clear the queue, or abort current synthesis. The queue has three layers: `current` (the running phase), `overrides` (explicitly triggered entries), and `automatic` (scheduler- computed candidates). The `pending` and `state` fields provide legacy compatibility.
 
 **Parameters:**
+
 - `action` (required): One of `list`, `clear`, `abort`.
-  - `list`: Show current queue state (current with phase, overrides,
-    automatic candidates, pending items).
+  - `list`: Show current queue state (current with phase, overrides, automatic candidates, pending items).
   - `clear`: Remove all override queue entries.
   - `abort`: Stop the currently running phase and release its lock.
 
@@ -145,60 +119,29 @@ compatibility.
 - **Disabling a meta:** `meta_update` with path and `updates: { _disabled: true }`
 - **Re-enabling a meta:** `meta_update` with path and `updates: { _disabled: null }`
 - **Changing steer via API:** `meta_update` with path and `updates: { _steer: "new focus" }`
-- **Reading synthesis output:** Use `watcher_search` filtered by the properties
-  configured in `metaProperty` (e.g. `{ "domains": ["meta"] }` in production).
-  The default properties are `{ _meta: "current" }` for live metas and
-  `{ _meta: "archive" }` for archive snapshots.
+- **Reading synthesis output:** Use `watcher_search` filtered by the properties configured in `metaProperty` (e.g. `{ "domains": ["meta"] }` in production). The default properties are `{ _meta: "current" }` for live metas and `{ _meta: "archive" }` for archive snapshots.
 
 ## Key Concepts
 
-- **Steering (`_steer`):** Human-written prompt in `meta.json` that guides
-  synthesis focus. The only field humans typically write.
-- **Cross-references (`_crossRefs`):** Optional array of owner paths pointing
-  to other metas. Referenced metas' `_content` is included as context for
-  the architect and builder steps (not the critic). Enables organizational
-  views that aggregate across source domains without requiring data
-  co-location. Cycles are permitted (A refs B, B refs A). No transitive
-  closure — if A needs C's content, declare the ref explicitly.
-- **Staleness:** Time since last synthesis. Deeper metas (leaves) update more
-  often than rollup metas (parents). Cross-ref freshness does NOT affect
-  the referencing meta's staleness — each meta synthesizes independently.
-- **Disabled (`_disabled`):** Set `_disabled: true` on a meta to exclude it
-  from automatic staleness scheduling. The scheduler and auto-select both
-  skip disabled metas. Manual triggers (`meta_trigger` with explicit path)
-  still work. Use `meta_update` to toggle the flag.
-- **Three steps:** Architect crafts the task brief, Builder produces content,
-  Critic evaluates quality. The feedback loop self-improves over cycles.
+- **Steering (`_steer`):** Human-written prompt in `meta.json` that guides synthesis focus. The only field humans typically write.
+- **Cross-references (`_crossRefs`):** Optional array of owner paths pointing to other metas. Referenced metas' `_content` is included as context for the architect and builder steps (not the critic). Enables organizational views that aggregate across source domains without requiring data co-location. Cycles are permitted (A refs B, B refs A). No transitive closure — if A needs C's content, declare the ref explicitly.
+- **Staleness:** Time since last synthesis. Deeper metas (leaves) update more often than rollup metas (parents). Cross-ref freshness does NOT affect the referencing meta's staleness — each meta synthesizes independently.
+- **Disabled (`_disabled`):** Set `_disabled: true` on a meta to exclude it from automatic staleness scheduling. The scheduler and auto-select both skip disabled metas. Manual triggers (`meta_trigger` with explicit path) still work. Use `meta_update` to toggle the flag.
+- **Three steps:** Architect crafts the task brief, Builder produces content, Critic evaluates quality. The feedback loop self-improves over cycles.
 - **Archives:** Each cycle creates a timestamped snapshot in `.meta/archive/`.
-- **Progressive synthesis (`_state`):** The builder can set an opaque `_state`
-  value in its output JSON. This state is persisted in `meta.json` and passed
-  back as context on the next cycle, enabling multi-cycle progressive work
-  (e.g. phased analysis, incremental refinement). On builder timeout, the
-  engine attempts to recover partial output — if `_state` advanced, it saves
-  the new state without overwriting existing content.
-- **Phase-state machine (`_phaseState`):** Each meta tracks its three phases
-  independently: `{ architect: <state>, builder: <state>, critic: <state> }`.
-  States are `fresh`, `stale`, `pending`, `running`, or `failed`. The
-  scheduler picks the single highest-priority owed phase across all metas
-  each tick (critic > builder > architect, with staleness tiebreaking).
-  Failed phases are automatically retried on the next tick (promoted from
-  `failed` → `pending`). Only the failed phase reruns — upstream/downstream
-  phases are untouched (surgical retries). A full cycle completes only when
-  all three phases are `fresh`, at which point the archive snapshot is taken
-  and `_synthesisCount` increments. Legacy metas without `_phaseState` have
-  their state derived automatically from existing fields on first load.
+- **Progressive synthesis (`_state`):** The builder can set an opaque `_state` value in its output JSON. This state is persisted in `meta.json` and passed back as context on the next cycle, enabling multi-cycle progressive work (e.g. phased analysis, incremental refinement). On builder timeout, the engine attempts to recover partial output — if `_state` advanced, it saves the new state without overwriting existing content.
+- **Phase-state machine (`_phaseState`):** Each meta tracks its three phases independently: `{ architect: <state>, builder: <state>, critic: <state> }`. States are `fresh`, `stale`, `pending`, `running`, or `failed`. The scheduler picks the single highest-priority owed phase across all metas each tick (critic > builder > architect, with staleness tiebreaking). Failed phases are automatically retried on the next tick (promoted from `failed` → `pending`). Only the failed phase reruns — upstream/downstream phases are untouched (surgical retries). A full cycle completes only when all three phases are `fresh`, at which point the archive snapshot is taken and `_synthesisCount` increments. Legacy metas without `_phaseState` have their state derived automatically from existing fields on first load.
 
 ## Configuration
 
 ### Config File
 
-Location determined by `JEEVES_META_CONFIG` env var or `--config` CLI flag.
-Canonical deployment: `J:\config\jeeves-meta\config.json`.
+Location determined by `JEEVES_META_CONFIG` env var or `--config` CLI flag. Canonical deployment: `J:\config\jeeves-meta\config.json`.
 
 Key settings:
 
 | Setting | Default | Description |
-|---------|---------|-------------|
+| --- | --- | --- |
 | `watcherUrl` | (required) | Watcher service URL (e.g. `http://localhost:1936`) |
 | `gatewayUrl` | `http://127.0.0.1:18789` | OpenClaw gateway URL for subprocess spawning |
 | `gatewayApiKey` | (optional) | API key for gateway authentication |
@@ -212,49 +155,26 @@ Key settings:
 | `thinking` | `low` | Thinking level for spawned LLM sessions |
 | `port` | 1938 | HTTP API listen port |
 
-| `schedule` | `*/30 * * * *` | Cron expression for automatic synthesis scheduling |
-| `serverBaseUrl` | (optional) | Public base URL of the service (e.g. `http://myhost:1938`). When set, progress reports include clickable entity links. |
-| `serverDriveRoots` | (optional) | Drive label to absolute path mapping for Linux path resolution in progress links (e.g. `{ "content": "/opt/jeeves/content" }`). |
-| `reportChannel` | (optional) | Gateway channel name (e.g. `slack`). Legacy: also used as target if `reportTarget` is unset. |
-| `reportTarget` | (optional) | Channel/user ID to send progress messages to |
-| `tier2ScanLimit` | 50 | Max all-fresh candidates to scan per tick in Tier 2 invalidation |
-| `workspaceDir` | OS tmpdir + `/jeeves-meta` | Directory for sub-agent output staging files |
-| `stagingRetries` | 10 | Max retries when staging file not yet visible after session completion (min 0) |
-| `stagingRetryDelayMs` | 250 | Delay between staging file retry attempts in ms (min 0) |
-| `previewDeltaFilesCap` | 50 | Max delta files included in `/preview` response; excess sets `deltaFilesTruncated: true` (min 1) |
-| `logging.level` | `info` | Log level (trace/debug/info/warn/error) |
-| `logging.file` | (optional) | Log file path |
+| `schedule` | `*/30 * * * *` | Cron expression for automatic synthesis scheduling | | `serverUrl` | `http://127.0.0.1:1934` | jeeves-server base URL for progress report links | | `templates` | (see docs) | Templates for phase start, end, and error progress reports | | `reportChannel` | (optional) | Gateway channel name (e.g. `slack`). Legacy: also used as target if `reportTarget` is unset. | | `reportTarget` | (optional) | Channel/user ID to send progress messages to | | `tier2ScanLimit` | 50 | Max all-fresh candidates to scan per tick in Tier 2 invalidation | | `workspaceDir` | OS tmpdir + `/jeeves-meta` | Directory for sub-agent output staging files | | `stagingRetries` | 10 | Max retries when staging file not yet visible after session completion (min 0) | | `stagingRetryDelayMs` | 250 | Delay between staging file retry attempts in ms (min 0) | | `previewDeltaFilesCap` | 50 | Max delta files included in `/preview` response; excess sets `deltaFilesTruncated: true` (min 1) | | `logging.level` | `info` | Log level (trace/debug/info/warn/error) | | `logging.file` | (optional) | Log file path |
 
 ### Meta Discovery
 
 Discovery is entirely filesystem-based (no Qdrant dependency). The engine:
 
-1. **Registers virtual inference rules** at service startup. These rules match
-   file paths (`**/.meta/meta.json` and `**/.meta/archive/*.json`) and apply
-   the configured `metaProperty`/`metaArchiveProperty` values as watcher
-   metadata on those indexed points.
+1. **Registers virtual inference rules** at service startup. These rules match file paths (`**/.meta/meta.json` and `**/.meta/archive/*.json`) and apply the configured `metaProperty`/`metaArchiveProperty` values as watcher metadata on those indexed points.
+
+2. **Discovers metas** via `watcher.walk(["**/.meta/meta.json"])` — a filesystem walk provided by the watcher's `POST /walk` endpoint. This enumerates all `.meta/meta.json` files under watched paths without using Qdrant or any vector database queries.
 
-2. **Discovers metas** via `watcher.walk(["**/.meta/meta.json"])` — a filesystem
-   walk provided by the watcher's `POST /walk` endpoint. This enumerates all
-   `.meta/meta.json` files under watched paths without using Qdrant or any
-   vector database queries.
+3. **Deduplicates** results by `.meta/` directory path and builds the ownership tree.
 
-3. **Deduplicates** results by `.meta/` directory path and builds the
-   ownership tree.
+**Important:** If you change `metaProperty` or `metaArchiveProperty` in config, you must:
 
-**Important:** If you change `metaProperty` or `metaArchiveProperty` in config,
-you must:
-- Restart the jeeves-meta service (so it re-registers virtual rules with the
-  new property values)
-- Trigger a watcher rules reindex (`watcher_reindex` with scope `rules`) so
-  existing indexed points get retagged with the new properties
+- Restart the jeeves-meta service (so it re-registers virtual rules with the new property values)
+- Trigger a watcher rules reindex (`watcher_reindex` with scope `rules`) so existing indexed points get retagged with the new properties
 
 ### Configuring Meta Properties
 
-`metaProperty` and `metaArchiveProperty` are `Record<string, unknown>` — any
-JSON-serializable key-value structure. The virtual rules spread these properties
-onto every matching indexed point. The discovery filter is derived from the same
-properties.
+`metaProperty` and `metaArchiveProperty` are `Record<string, unknown>` — any JSON-serializable key-value structure. The virtual rules spread these properties onto every matching indexed point. The discovery filter is derived from the same properties.
 
 **Example configurations:**
 
@@ -276,23 +196,17 @@ properties.
 
 ### Prompt System
 
-The service ships with built-in default architect and critic prompts. Prompts
-ship with the package and cannot be overridden via config.
+The service ships with built-in default architect and critic prompts. Prompts ship with the package and cannot be overridden via config.
 
-**Per-meta overrides:** Set `_architect` or `_critic` directly in a `meta.json`
-to override the defaults for that specific entity.
+**Per-meta overrides:** Set `_architect` or `_critic` directly in a `meta.json` to override the defaults for that specific entity.
 
-**Template variables:** All prompts (built-in and per-meta)
-are compiled as Handlebars templates at synthesis time with access to:
+**Template variables:** All prompts (built-in and per-meta) are compiled as Handlebars templates at synthesis time with access to:
 
 - `{{config.maxLines}}`, `{{config.architectEvery}}`, etc.
 - `{{scope.fileCount}}`, `{{scope.deltaCount}}`, `{{scope.childCount}}`, `{{scope.crossRefCount}}`
 - `{{meta._depth}}`, `{{meta._emphasis}}`
 
-The architect prompt can write template expressions into its `_builder` output
-using escaped syntax (`\{{config.maxLines}}`). These pass through the
-architect compilation as literal `{{...}}` text and resolve when the builder
-prompt is compiled.
+The architect prompt can write template expressions into its `_builder` output using escaped syntax (`\{{config.maxLines}}`). These pass through the architect compilation as literal `{{...}}` text and resolve when the builder prompt is compiled.
 
 ### Minimal Config Example
 
@@ -308,55 +222,41 @@ A minimum viable config file requires `watcherUrl`, `metaProperty`, and `metaArc
 }
 ```
 
-All other fields use sensible defaults (port 1938, schedule every 30 min,
-depth weight 0.5, built-in prompts, etc). Add `reportChannel`, `logging`, etc. as needed.
+All other fields use sensible defaults (port 1938, schedule every 30 min, depth weight 0.5, built-in prompts, etc). Add `reportChannel`, `logging`, etc. as needed.
 
 ### Adding New Metas
 
 1. Create the `.meta/` directory under the domain path
-2. Seed it: `jeeves-meta seed <path>` — creates `meta.json`
-   with a UUID (`_id`). All other fields are populated on first synthesis
-3. Optionally edit `meta.json` to set `_steer`, `_depth`, `_emphasis`,
-   and `_crossRefs`
-4. Wait for the watcher to index the new `meta.json` (typically seconds via
-   chokidar file watching)
+2. Seed it: `jeeves-meta seed <path>` — creates `meta.json` with a UUID (`_id`). All other fields are populated on first synthesis
+3. Optionally edit `meta.json` to set `_steer`, `_depth`, `_emphasis`, and `_crossRefs`
+4. Wait for the watcher to index the new `meta.json` (typically seconds via chokidar file watching)
 5. The entity appears in `meta_list` on the next query
 
-**Note:** `_id` is optional in `meta.json`. A minimal stub of just `{}` or
-`{ "_steer": "..." }` is valid — a UUID will be auto-generated on first
-synthesis. The `meta_seed` tool and auto-seed always generate `_id` at
-creation time.
+**Note:** `_id` is optional in `meta.json`. A minimal stub of just `{}` or `{ "_steer": "..." }` is valid — a UUID will be auto-generated on first synthesis. The `meta_seed` tool and auto-seed always generate `_id` at creation time.
 
 ### Auto-Seed Policy
 
-The `autoSeed` config field enables declarative, config-driven `.meta/`
-creation. It is an array of policy rules, each with the shape:
+The `autoSeed` config field enables declarative, config-driven `.meta/` creation. It is an array of policy rules, each with the shape:
 
 ```json
-{ "match": "<glob>", "steer": "<optional>", "crossRefs": ["<optional>"], "parentDepth": 0 }
+{
+  "match": "<glob>",
+  "steer": "<optional>",
+  "crossRefs": ["<optional>"],
+  "parentDepth": 0
+}
 ```
 
-- **`match`** (required) — a glob pattern compatible with `watcher.walk()`.
-  The watcher walks all watched paths matching this glob and returns file
-  paths. Parent directories of matched files become seed candidates.
-- **`steer`** (optional) — steering prompt written as `_steer` in the
-  seeded `meta.json`.
-- **`crossRefs`** (optional) — array of cross-ref owner paths written as
-  `_crossRefs` in the seeded `meta.json`.
-- **`parentDepth`** (optional, default 0) — walk up this many extra parent
-  levels from the matched file's directory.
-**Evaluation order: Rules are processed in array order. If multiple rules
-match the same directory, the last match wins for `steer` and `crossRefs`.
+- **`match`** (required) — a glob pattern compatible with `watcher.walk()`. The watcher walks all watched paths matching this glob and returns file paths. Parent directories of matched files become seed candidates.
+- **`steer`** (optional) — steering prompt written as `_steer` in the seeded `meta.json`.
+- **`crossRefs`** (optional) — array of cross-ref owner paths written as `_crossRefs` in the seeded `meta.json`.
+- **`parentDepth`** (optional, default 0) — walk up this many extra parent levels from the matched file's directory. **Evaluation order: Rules are processed in array order. If multiple rules match the same directory, the last match wins for `steer` and `crossRefs`.
 
 **Behavior:**
-- Auto-seed runs at the start of each scheduler tick, before candidate
-  discovery. Directories that already have a `.meta/` subdirectory are
-  skipped.
-- Empty directories (no files matching any glob) will not be seeded — the
-  watcher walk only returns actual file paths, and parent directories are
-  derived from those.
-- The `autoSeed` field hot-reloads with all other non-restart-required
-  config fields.
+
+- Auto-seed runs at the start of each scheduler tick, before candidate discovery. Directories that already have a `.meta/` subdirectory are skipped.
+- Empty directories (no files matching any glob) will not be seeded — the watcher walk only returns actual file paths, and parent directories are derived from those.
+- The `autoSeed` field hot-reloads with all other non-restart-required config fields.
 
 **Example:**
 
@@ -371,66 +271,43 @@ match the same directory, the last match wins for `steer` and `crossRefs`.
 
 ### Adding Cross-Reference Metas
 
-For metas that aggregate context from other metas (e.g. an organizational
-rollup that pulls from GitHub, Slack, and email metas):
+For metas that aggregate context from other metas (e.g. an organizational rollup that pulls from GitHub, Slack, and email metas):
 
-1. Seed with cross-refs: use `meta_seed` with both `path` and `crossRefs`
-   parameters. Example: seed `j:/veterancrowd/projects/ops` with refs to
-   `["j:/veterancrowd/github","j:/veterancrowd/slack"]`
+1. Seed with cross-refs: use `meta_seed` with both `path` and `crossRefs` parameters. Example: seed `j:/veterancrowd/projects/ops` with refs to `["j:/veterancrowd/github","j:/veterancrowd/slack"]`
 2. Set `_steer` to guide synthesis focus across the referenced sources
 3. Verify refs: `meta_detail <path>` shows `crossRefs` status (resolved/missing)
-4. Cross-ref metas can have zero sibling files — all context comes from refs
-   and child metas. The engine handles empty scopes gracefully.
+4. Cross-ref metas can have zero sibling files — all context comes from refs and child metas. The engine handles empty scopes gracefully.
 
-**Pure meta trees:** Directories containing only `.meta/` subdirectories and
-no source data are valid. Use `_crossRefs` and `_steer` to define what context
-flows in. Useful for organizational views (people, projects) that aggregate
-across physically distributed data.
+**Pure meta trees:** Directories containing only `.meta/` subdirectories and no source data are valid. Use `_crossRefs` and `_steer` to define what context flows in. Useful for organizational views (people, projects) that aggregate across physically distributed data.
 
 ### Tuning Scheduling
 
 - **`_depth`:** Higher = updates more often. Defaults from tree nesting depth.
-- **`_emphasis`:** Per-meta multiplier (default 1). Set 2 to double priority,
-  0.5 to halve it.
+- **`_emphasis`:** Per-meta multiplier (default 1). Set 2 to double priority, 0.5 to halve it.
 - **`depthWeight`:** Global exponent. Set 0 for pure staleness rotation.
-- **`architectEvery`:** Higher = fewer architect runs (cheaper but slower to
-  adapt to structural changes).
+- **`architectEvery`:** Higher = fewer architect runs (cheaper but slower to adapt to structural changes).
 
 ### Config Hot-Reload
 
-All config fields hot-reload without restarting the service **except** these
-restart-required fields:
+All config fields hot-reload without restarting the service **except** these restart-required fields:
 
 - `port` — HTTP listen port
 - `watcherUrl` — watcher service URL
 - `gatewayUrl` — OpenClaw gateway URL
 - `gatewayApiKey` — gateway authentication key
 
-Edit the config file and save; the service detects changes via `fs.watchFile`.
-When a restart-required field changes, the service logs a warning but the
-change does not take effect until restart. All other fields (including
-`schedule`, `reportChannel`, `metaProperty`, timeouts, `autoSeed`,
-`logging.level`, etc.) are applied immediately.
+Edit the config file and save; the service detects changes via `fs.watchFile`. When a restart-required field changes, the service logs a warning but the change does not take effect until restart. All other fields (including `schedule`, `reportChannel`, `metaProperty`, timeouts, `autoSeed`, `logging.level`, etc.) are applied immediately.
 
 ### Progress Reporting
 
-When `reportChannel` is set, the service sends real-time progress messages
-to that channel via the OpenClaw gateway. Events include: synthesis started,
-phase started/completed (architect, builder, critic), synthesis completed,
-and errors. This uses
-`/tools/invoke` → `message` tool — zero LLM token cost.
+When `reportChannel` is set, the service sends real-time progress messages to that channel via the OpenClaw gateway. Events include: synthesis started, phase started/completed (architect, builder, critic), synthesis completed, and errors. This uses `/tools/invoke` → `message` tool — zero LLM token cost.
 
-### TOOLS.md Bootstrapping Prompts
+### Bootstrapping Signals
 
-The plugin's TOOLS.md injection automatically prompts bootstrapping:
-- **Service unreachable:** Shows "ACTION REQUIRED: jeeves-meta service is
-  unreachable" with troubleshooting steps and directs to this skill's
-  Bootstrapping section
-- **No entities found:** Shows "ACTION REQUIRED: No synthesis entities found"
-  and directs to this skill's Bootstrapping section
+The plugin writes nothing into workspace files or the system prompt. Check live state with the tools:
 
-These messages appear in the agent's system prompt, ensuring proactive
-discovery of configuration issues.
+- **Service unreachable:** any `meta_*` tool returns a connection error with troubleshooting guidance; see this skill's Bootstrapping section
+- **No entities found:** `meta_list` returns an empty list; see this skill's Bootstrapping section
 
 ## Bootstrapping
 
@@ -438,8 +315,7 @@ discovery of configuration issues.
 
 Before the synthesis engine can operate:
 
-1. **OpenClaw gateway** must be running (the service spawns LLM sessions
-   through it via `gatewayUrl`)
+1. **OpenClaw gateway** must be running (the service spawns LLM sessions through it via `gatewayUrl`)
    - Verify: `openclaw gateway status` or check the URL in config
 
 2. **jeeves-watcher** must be running and indexing data
@@ -451,8 +327,7 @@ Before the synthesis engine can operate:
 
 4. **Config file** must exist at the path specified by `JEEVES_META_CONFIG`
    - Must contain valid `watcherUrl`, `metaProperty`, and `metaArchiveProperty`
-   - Built-in architect and critic prompts ship with the package; no prompt
-     configuration is required
+   - Built-in architect and critic prompts ship with the package; no prompt configuration is required
 
 5. **`.meta/` directories** must exist and be within paths the watcher indexes
    - Seed new metas: `jeeves-meta seed <path>`
@@ -466,19 +341,21 @@ npm install -g @karmaniverous/jeeves-meta
 jeeves-meta start --config J:\config\jeeves-meta\config.json
 ```
 
-2. Install the OpenClaw plugin:
+2. Install the OpenClaw plugin with the Jeeves CLI, which also writes the plugin config (`configRoot`, `apiUrl`):
 
 ```bash
-npx @karmaniverous/jeeves-meta-openclaw install
+jeeves install meta --config-root J:\config
 ```
 
-For non-default OpenClaw installations, set `OPENCLAW_CONFIG` (path to
-`openclaw.json`) or `OPENCLAW_HOME` (path to `.openclaw` directory).
+Or install it directly with OpenClaw and configure it yourself:
+
+```bash
+openclaw plugins install npm:@karmaniverous/jeeves-meta-openclaw@<version> --pin --accept-capabilities
+```
 
-To uninstall: `npx @karmaniverous/jeeves-meta-openclaw uninstall`
+To uninstall: `jeeves uninstall` or `openclaw plugins uninstall jeeves-meta-openclaw`.
 
-3. (Optional) Configure the plugin with the service URL — only needed if the
-   service runs on a non-default port or host:
+3. Configure the plugin. `configRoot` (the platform config root) is needed by `meta_service` `install`; set it in plugin config or via the `JEEVES_CONFIG_ROOT` env var. The plugin loads without it and logs one warning. `apiUrl` is only needed if the service runs on a non-default port or host:
 
 ```json
 {
@@ -487,7 +364,8 @@ To uninstall: `npx @karmaniverous/jeeves-meta-openclaw uninstall`
       "jeeves-meta-openclaw": {
         "enabled": true,
         "config": {
-          "apiUrl": "http://127.0.0.1:1938"
+          "apiUrl": "http://127.0.0.1:1938",
+          "configRoot": "J:/config"
         }
       }
     }
@@ -497,8 +375,7 @@ To uninstall: `npx @karmaniverous/jeeves-meta-openclaw uninstall`
 
 4. Restart the OpenClaw gateway to load the plugin.
 
-5. Verify: check that `## Meta` appears in TOOLS.md injection and
-   `jeeves-meta` appears in available skills.
+5. Verify: `meta_status` reports the service healthy and `jeeves-meta` appears in available skills.
 
 ### First Synthesis
 
@@ -517,11 +394,13 @@ jeeves-meta service install --config J:\config\jeeves-meta\config.json
 ```
 
 This prints OS-specific instructions:
+
 - **Windows:** NSSM service commands
 - **macOS:** launchd plist
 - **Linux:** systemd unit
 
 Management commands (print OS-specific equivalents):
+
 ```bash
 jeeves-meta service start     # print start instructions
 jeeves-meta service stop      # print stop instructions
@@ -534,7 +413,7 @@ jeeves-meta service remove    # print removal instructions
 The service exposes these endpoints (default port 1938):
 
 | Method | Path | Description |
-|--------|------|-------------|
+| --- | --- | --- |
 | GET | `/status` | Service health, queue state, dependency checks, phase-state summary |
 | GET | `/metas` | List metas with filtering and field projection |
 | GET | `/metas/:path` | Single meta detail with optional archive |
@@ -549,8 +428,7 @@ The service exposes these endpoints (default port 1938):
 | GET | `/queue` | Queue state: current (with phase), overrides, automatic, pending |
 | POST | `/queue/clear` | Remove all override queue entries |
 
-All endpoints return JSON. The OpenClaw plugin tools are thin wrappers
-around these endpoints.
+All endpoints return JSON. The OpenClaw plugin tools are thin wrappers around these endpoints.
 
 ## Service CLI
 
@@ -560,143 +438,99 @@ The service package ships a CLI:
 jeeves-meta <command> [options]
 ```
 
-Commands: `start`, `status`, `list`, `detail`, `preview`, `synthesize`,
-`seed`, `unlock`, `abort`, `prune`, `config`, `queue list|clear`,
-`service install|start|stop|status|remove`.
+Commands: `start`, `status`, `list`, `detail`, `preview`, `synthesize`, `seed`, `unlock`, `abort`, `prune`, `config`, `queue list|clear`, `service install|start|stop|status|remove`.
 
-Config resolution: `--config` flag → `JEEVES_META_CONFIG` env var → error.
-All client commands support `-p, --port` to specify the service port (default: 1938).
-The `start` command uses `--config`/`-c` instead (port is read from the config file).
+Config resolution: `--config` flag → `JEEVES_META_CONFIG` env var → error. All client commands support `-p, --port` to specify the service port (default: 1938). The `start` command uses `--config`/`-c` instead (port is read from the config file).
 
 ## Operational Monitoring
 
 Recommended periodic checks:
-- **Errors:** `meta_list` with `filter: { hasError: true }` — investigate
-  and retry with `meta_trigger`
-- **Failed phases:** The TOOLS.md injection shows a "Failed:" alert listing
-  metas with failed phases. Failed phases auto-retry on the next scheduler
-  tick. Use `meta_detail` to inspect the `_phaseState` and `_error` fields.
-- **Stuck locks:** `meta_list` with `filter: { locked: true }` — locks
-  older than 30 minutes indicate a crashed synthesis; use `jeeves-meta unlock`
-- **Stale knowledge:** `meta_list` with `filter: { staleHours: 48 }` — check
-  if the scheduler is running and the watcher is up
-- **Phase health:** `/status` includes `phaseStateSummary` with aggregate
-  counts per phase (`fresh`, `stale`, `pending`, `running`, `failed`) and
-  `nextPhase` showing the next candidate.
-- **Service health:** `/status` endpoint (via `meta_list` summary or direct
-  HTTP) includes dependency status for watcher and gateway
-
-The TOOLS.md injection surfaces the most critical stats (entity count, errors,
-stalest entity, phase summary, failed-phase alerts, next-phase indicator) in
-the agent's system prompt automatically.
+
+- **Errors:** `meta_list` with `filter: { hasError: true }` — investigate and retry with `meta_trigger`
+- **Failed phases:** `/status` (`meta_status`) reports failed phases in `phaseStateSummary`. Failed phases auto-retry on the next scheduler tick. Use `meta_detail` to inspect the `_phaseState` and `_error` fields.
+- **Stuck locks:** `meta_list` with `filter: { locked: true }` — locks older than 30 minutes indicate a crashed synthesis; use `jeeves-meta unlock`
+- **Stale knowledge:** `meta_list` with `filter: { staleHours: 48 }` — check if the scheduler is running and the watcher is up
+- **Phase health:** `/status` includes `phaseStateSummary` with aggregate counts per phase (`fresh`, `stale`, `pending`, `running`, `failed`) and `nextPhase` showing the next candidate.
+- **Meta counts:** `/status` includes `health.metaCounts` with totals: `total`, `enabled`, `disabled`, `neverSynthesized`, `stale`, `errors`, and `locked`.
+- **Service health:** `/status` endpoint (via `meta_list` summary or direct HTTP) includes dependency status for watcher and gateway
+
+The plugin no longer injects these stats into the system prompt; call `meta_status` and `meta_list` when you need them.
 
 ## Troubleshooting
 
 ### Service unreachable
 
-**Symptom:** TOOLS.md shows "ACTION REQUIRED: jeeves-meta service is unreachable"
-**Cause:** Meta service not running or wrong `apiUrl` in plugin config
-**Fix:**
+**Symptom:** `meta_*` tools return a connection error for the meta service **Cause:** Meta service not running or wrong `apiUrl` in plugin config **Fix:**
+
 1. Check if the service is running: `jeeves-meta service status` or `curl http://localhost:1938/status`
 2. If down, start it: `jeeves-meta service start` or `jeeves-meta start --config <path>`
 3. If running on a different port, update `apiUrl` in plugin config
 
+### configRoot not configured
+
+**Symptom:** `meta_service` `install` returns "configRoot not configured", or the gateway log shows "[jeeves-meta] configRoot not configured yet" **Cause:** The plugin was loaded before its config was written (normal right after `openclaw plugins install`), or no config root is set **Fix:** Set `plugins.entries.jeeves-meta-openclaw.config.configRoot` (e.g. via `jeeves install --config-root <path>`) or the `JEEVES_CONFIG_ROOT` env var. The other `meta_service` actions and all other `meta_*` tools do not read `configRoot` and keep working.
+
 ### Watcher unreachable
 
-**Symptom:** TOOLS.md shows a ⚠️ **Watcher** dependency warning in the entity summary
-**Cause:** Watcher service not running or wrong URL in meta service config
-**Fix:**
+**Symptom:** `meta_status` reports the watcher dependency as unreachable **Cause:** Watcher service not running or wrong URL in meta service config **Fix:**
+
 1. Check watcher status: `watcher_status` tool or `curl http://localhost:1936/status`
 2. If down, start the watcher service
 3. If running on a different port, update `watcherUrl` in meta service config and restart the service
 
 ### No entities discovered
 
-**Symptom:** `meta_list` returns empty, TOOLS.md shows "No synthesis entities found"
-**Cause:** No `.meta/meta.json` files indexed, or `metaProperty` mismatch
-**Fix:**
+**Symptom:** `meta_list` returns empty **Cause:** No `.meta/meta.json` files indexed, or `metaProperty` mismatch **Fix:**
+
 1. Verify `.meta/meta.json` files exist on disk
-2. Check that the watcher indexes those paths (paths must be in watcher's
-   configured `watch` globs)
-3. Check that `metaProperty` in config matches the properties actually set
-   on indexed points. If you changed `metaProperty`, run `watcher_reindex`
-   with scope `rules` and restart the meta service.
+2. Check that the watcher indexes those paths (paths must be in watcher's configured `watch` globs)
+3. Check that `metaProperty` in config matches the properties actually set on indexed points. If you changed `metaProperty`, run `watcher_reindex` with scope `rules` and restart the meta service.
 4. Seed new metas if needed: `jeeves-meta seed <path>`
 
 ### Synthesis stuck (locked entities)
 
-**Symptom:** `meta_list` shows locked entities that never unlock
-**Cause:** Previous synthesis crashed, leaving stale `.lock` file
-**Fix:**
+**Symptom:** `meta_list` shows locked entities that never unlock **Cause:** Previous synthesis crashed, leaving stale `.lock` file **Fix:**
+
 1. Check lock: `meta_detail <path>` — look for `locked: true`
 2. Locks auto-expire after 30 minutes
-3. For immediate unlock: `jeeves-meta unlock <path>`
-   or delete `.meta/.lock` file manually
+3. For immediate unlock: `jeeves-meta unlock <path>` or delete `.meta/.lock` file manually
 
 ### Executor timeouts
 
-**Symptom:** `meta_detail` shows `_error` with code `TIMEOUT`
-**Cause:** Subprocess took longer than configured timeout
-**Note:** The engine attempts partial recovery on builder timeouts. If the
-builder wrote partial output with an advanced `_state`, the state is saved
-(preserving existing content) and the error is recorded. This means
-progressive work is not lost on timeout — only the content update is skipped.
-**Fix:**
-1. Check if `_state` advanced (partial recovery succeeded) — subsequent
-   cycles can continue from where the builder left off
+**Symptom:** `meta_detail` shows `_error` with code `TIMEOUT` **Cause:** Subprocess took longer than configured timeout **Note:** The engine attempts partial recovery on builder timeouts. If the builder wrote partial output with an advanced `_state`, the state is saved (preserving existing content) and the error is recorded. This means progressive work is not lost on timeout — only the content update is skipped. **Fix:**
+
+1. Check if `_state` advanced (partial recovery succeeded) — subsequent cycles can continue from where the builder left off
 2. Check the gateway's `agents.defaults.subagents.runTimeoutSeconds` setting and increase it if needed
 3. Check if the LLM provider is slow or rate-limited
 4. Check scope size: large scopes with many files take longer
 
 ### LLM errors in synthesis phases
 
-**Symptom:** `meta_detail` shows `_error` field with step/code/message, and
-`_phaseState` shows `failed` for one or more phases.
-**Cause:** Subprocess failed (API error, malformed output, rate limit)
-**Fix:**
-1. Check error details: `meta_detail <path>` — `_error.step` tells you
-   which phase failed; `_phaseState` shows the exact state of each phase
-2. Failed phases are **automatically retried** on the next scheduler tick
-   (promoted from `failed` → `pending`). Only the failed phase reruns —
-   other phases are untouched (surgical retry).
-3. Architect failure with existing `_builder`: engine reuses cached brief
-   (self-healing)
+**Symptom:** `meta_detail` shows `_error` field with step/code/message, and `_phaseState` shows `failed` for one or more phases. **Cause:** Subprocess failed (API error, malformed output, rate limit) **Fix:**
+
+1. Check error details: `meta_detail <path>` — `_error.step` tells you which phase failed; `_phaseState` shows the exact state of each phase
+2. Failed phases are **automatically retried** on the next scheduler tick (promoted from `failed` → `pending`). Only the failed phase reruns — other phases are untouched (surgical retry).
+3. Architect failure with existing `_builder`: engine reuses cached brief (self-healing)
 4. Architect failure without `_builder` (first run): retry with `meta_trigger`
 5. Builder failure: meta stays stale, retried next tick automatically
 6. Critic failure: content saved without feedback, not critical
 
 ### Discovery returns wrong/stale results
 
-**Symptom:** `meta_list` shows old metas or misses new ones
-**Cause:** Virtual rules not re-registered after config change, or watcher
-not yet indexed new files
-**Fix:**
+**Symptom:** `meta_list` shows old metas or misses new ones **Cause:** Virtual rules not re-registered after config change, or watcher not yet indexed new files **Fix:**
+
 1. If `metaProperty` changed: restart meta service + `watcher_reindex` (scope: rules)
-2. If new `.meta/` directory: wait for chokidar detection (seconds) or
-   trigger `watcher_reindex` (scope: full)
-3. Verify with `watcher_scan`: query for the expected properties to confirm
-   the watcher has the right metadata on the points
+2. If new `.meta/` directory: wait for chokidar detection (seconds) or trigger `watcher_reindex` (scope: full)
+3. Verify with `watcher_scan`: query for the expected properties to confirm the watcher has the right metadata on the points
 
 ## Gotchas
 
-- `meta_trigger` enqueues a single phase (not all three). A full cycle
-  requires three separate ticks (one per phase). Use `meta_detail` to
-  check `_phaseState` for progress.
+- `meta_trigger` enqueues a single phase (not all three). A full cycle requires three separate ticks (one per phase). Use `meta_detail` to check `_phaseState` for progress.
 - A locked meta (another synthesis in progress) will be skipped silently.
 - First-run quality is lower — the feedback loop needs 2-3 cycles to calibrate.
-- Changing `metaProperty` requires both a meta service restart AND a watcher reindex.
-  The service restart re-registers virtual rules; the reindex retags existing points.
-- Built-in architect and critic prompts ship with the package and cannot be
-  overridden via config.
-- All prompts (built-in and per-meta `_architect`/`_critic`) are compiled as
-  Handlebars templates. Avoid using `{{` in prompt text unless you intend
-  template variable resolution. Escape with `\{{` for literal double-braces.
-- The synthesis queue is single-threaded with three layers: `current` (the
-  running phase), `overrides` (explicitly triggered entries, highest priority),
-  and `automatic` (scheduler-computed candidates). Override entries are
-  processed before automatic candidates.
-- The scheduler uses adaptive backoff: if no stale candidates are found, it
-  doubles the skip interval (max 4×). Backoff resets after any successful
-  phase execution (not just full-cycle completion).
-- All CLI commands except `start` require the service to be running (they call
-  the HTTP API).
+- Changing `metaProperty` requires both a meta service restart AND a watcher reindex. The service restart re-registers virtual rules; the reindex retags existing points.
+- Built-in architect and critic prompts ship with the package and cannot be overridden via config.
+- All prompts (built-in and per-meta `_architect`/`_critic`) are compiled as Handlebars templates. Avoid using `{{` in prompt text unless you intend template variable resolution. Escape with `\{{` for literal double-braces.
+- The synthesis queue is single-threaded with three layers: `current` (the running phase), `overrides` (explicitly triggered entries, highest priority), and `automatic` (scheduler-computed candidates). Override entries are processed before automatic candidates.
+- The scheduler uses adaptive backoff: if no stale candidates are found, it doubles the skip interval (max 4×). Backoff resets after any successful phase execution (not just full-cycle completion).
+- All CLI commands except `start` require the service to be running (they call the HTTP API).