skykoi 2026.3.11 → 2026.3.13

package/docs/tools/lobster.md

@@ -1,7 +1,7 @@
 ---
 title: Lobster
-summary: "Typed workflow runtime for SkyKoi with resumable approval gates."
-description: Typed workflow runtime for SkyKoi — composable pipelines with approval gates.
+summary: "Typed workflow runtime for SKYKOI with resumable approval gates."
+description: Typed workflow runtime for SKYKOI — composable pipelines with approval gates.
 read_when:
   - You want deterministic multi-step workflows with explicit approvals
   - You need to resume a workflow without re-running earlier steps
@@ -9,7 +9,7 @@ read_when:
 
 # Lobster
 
-Lobster is a workflow shell that lets SkyKoi run multi-step tool sequences as a single, deterministic operation with explicit approval checkpoints.
+Lobster is a workflow shell that lets SKYKOI run multi-step tool sequences as a single, deterministic operation with explicit approval checkpoints.
 
 ## Hook
 
@@ -19,7 +19,7 @@ Your assistant can build the tools that manage itself. Ask for a workflow, and 3
 
 Today, complex workflows require many back-and-forth tool calls. Each call costs tokens, and the LLM has to orchestrate every step. Lobster moves that orchestration into a typed runtime:
 
-- **One call instead of many**: SkyKoi runs one Lobster tool call and gets a structured result.
+- **One call instead of many**: SKYKOI runs one Lobster tool call and gets a structured result.
 - **Approvals built in**: Side effects (send email, post comment) halt the workflow until explicitly approved.
 - **Resumable**: Halted workflows return a token; approve and resume without re-running everything.
 
@@ -35,7 +35,7 @@ Lobster is intentionally small. The goal is not "a new language," it's a predict
 
 ## How it works
 
-SkyKoi launches the local `lobster` CLI in **tool mode** and parses a JSON envelope from stdout.
+SKYKOI launches the local `lobster` CLI in **tool mode** and parses a JSON envelope from stdout.
 If the pipeline pauses for approval, the tool returns a `resumeToken` so you can continue later.
 
 ## Pattern: small CLI + JSON pipes + approvals
@@ -72,7 +72,7 @@ Example: map input items into tool calls:
 
 ```bash
 gog.gmail.search --query 'newer_than:1d' \
-  | SkyKoi.invoke --tool message --action send --each --item-key message --args-json '{"provider":"telegram","to":"..."}'
+  | SKYKOI.invoke --tool message --action send --each --item-key message --args-json '{"provider":"telegram","to":"..."}'
 ```
 
 ## JSON-only LLM steps (llm-task)
@@ -104,7 +104,7 @@ Enable the tool:
 Use it in a pipeline:
 
 ```lobster
-SkyKoi.invoke --tool llm-task --action json --args-json '{
+SKYKOI.invoke --tool llm-task --action json --args-json '{
   "prompt": "Given the input email, return intent and draft.",
   "input": { "subject": "Hello", "body": "Can you help?" },
   "schema": {
@@ -123,7 +123,7 @@ See [LLM Task](/tools/llm-task) for details and configuration options.
 
 ## Workflow files (.lobster)
 
-Lobster can run YAML/JSON workflow files with `name`, `args`, `steps`, `env`, `condition`, and `approval` fields. In SkyKoi tool calls, set `pipeline` to the file path.
+Lobster can run YAML/JSON workflow files with `name`, `args`, `steps`, `env`, `condition`, and `approval` fields. In SKYKOI tool calls, set `pipeline` to the file path.
 
 ```yaml
 name: inbox-triage
@@ -153,7 +153,7 @@ Notes:
 
 ## Install Lobster
 
-Install the Lobster CLI on the **same host** that runs the SkyKoi Gateway (see the [Lobster repo](https://github.com/SkyKoi/lobster)), and ensure `lobster` is on `PATH`.
+Install the Lobster CLI on the **same host** that runs the SKYKOI Gateway (see the [Lobster repo](https://github.com/SKYKOI/lobster)), and ensure `lobster` is on `PATH`.
 If you want to use a custom binary location, pass an **absolute** `lobsterPath` in the tool call.
 
 ## Enable the tool
@@ -190,7 +190,7 @@ Or per-agent:
 Avoid using `tools.allow: ["lobster"]` unless you intend to run in restrictive allowlist mode.
 
 Note: allowlists are opt-in for optional plugins. If your allowlist only names
-plugin tools (like `lobster`), SkyKoi keeps core tools enabled. To restrict core
+plugin tools (like `lobster`), SKYKOI keeps core tools enabled. To restrict core
 tools, include the core tools or groups you want in the allowlist too.
 
 ## Example: Email triage
@@ -199,12 +199,12 @@ Without Lobster:
 
 ```
 User: "Check my email and draft replies"
-→ SkyKoi calls gmail.list
+→ SKYKOI calls gmail.list
 → LLM summarizes
 → User: "draft replies to #2 and #5"
 → LLM drafts
 → User: "send #2"
-→ SkyKoi calls gmail.send
+→ SKYKOI calls gmail.send
 (repeat daily, no memory of what was triaged)
 ```
 
@@ -318,7 +318,7 @@ OpenProse pairs well with Lobster: use `/prose` to orchestrate multi-agent prep,
 ## Safety
 
 - **Local subprocess only** — no network calls from the plugin itself.
-- **No secrets** — Lobster doesn't manage OAuth; it calls SkyKoi tools that do.
+- **No secrets** — Lobster doesn't manage OAuth; it calls SKYKOI tools that do.
 - **Sandbox-aware** — disabled when the tool context is sandboxed.
 - **Hardened** — `lobsterPath` must be absolute if specified; timeouts and output caps enforced.
 

package/docs/tools/multi-agent-sandbox-tools.md

@@ -26,14 +26,14 @@ when the container is created.
 Auth is per-agent: each agent reads from its own `agentDir` auth store at:
 
 ```
-~/.skykoi/agents/<agentId>/agent/auth-profiles.json
+~/.SKYKOI/agents/<agentId>/agent/auth-profiles.json
 ```
 
 Credentials are **not** shared between agents. Never reuse `agentDir` across agents.
 If you want to share creds, copy `auth-profiles.json` into the other agent's `agentDir`.
 
 For how sandboxing behaves at runtime, see [Sandboxing](/gateway/sandboxing).
-For debugging “why is this blocked?”, see [Sandbox vs Tool Policy vs Elevated](/gateway/sandbox-vs-tool-policy-vs-elevated) and `SkyKoi sandbox explain`.
+For debugging “why is this blocked?”, see [Sandbox vs Tool Policy vs Elevated](/gateway/sandbox-vs-tool-policy-vs-elevated) and `SKYKOI sandbox explain`.
 
 ---
 
@@ -49,13 +49,13 @@ For debugging “why is this blocked?”, see [Sandbox vs Tool Policy vs Elevate
         "id": "main",
         "default": true,
         "name": "Personal Assistant",
-        "workspace": "~/.skykoi/workspace",
+        "workspace": "~/.SKYKOI/workspace",
         "sandbox": { "mode": "off" }
       },
       {
         "id": "family",
         "name": "Family Bot",
-        "workspace": "~/.skykoi/workspace-family",
+        "workspace": "~/.SKYKOI/workspace-family",
         "sandbox": {
           "mode": "all",
           "scope": "agent"
@@ -98,12 +98,12 @@ For debugging “why is this blocked?”, see [Sandbox vs Tool Policy vs Elevate
     "list": [
       {
         "id": "personal",
-        "workspace": "~/.skykoi/workspace-personal",
+        "workspace": "~/.SKYKOI/workspace-personal",
         "sandbox": { "mode": "off" }
       },
       {
         "id": "work",
-        "workspace": "~/.skykoi/workspace-work",
+        "workspace": "~/.SKYKOI/workspace-work",
         "sandbox": {
           "mode": "all",
           "scope": "shared",
@@ -158,14 +158,14 @@ For debugging “why is this blocked?”, see [Sandbox vs Tool Policy vs Elevate
     "list": [
       {
         "id": "main",
-        "workspace": "~/.skykoi/workspace",
+        "workspace": "~/.SKYKOI/workspace",
         "sandbox": {
           "mode": "off" // Override: main never sandboxed
         }
       },
       {
         "id": "public",
-        "workspace": "~/.skykoi/workspace-public",
+        "workspace": "~/.SKYKOI/workspace-public",
         "sandbox": {
           "mode": "all", // Override: public always sandboxed
           "scope": "agent"
@@ -234,7 +234,7 @@ Tool policies (global, agent, sandbox) support `group:*` entries that expand to
 - `group:automation`: `cron`, `gateway`
 - `group:messaging`: `message`
 - `group:nodes`: `nodes`
-- `group:SkyKoi`: all built-in SkyKoi tools (excludes provider plugins)
+- `group:SKYKOI`: all built-in SKYKOI tools (excludes provider plugins)
 
 ### Elevated Mode
 
@@ -257,7 +257,7 @@ Mitigation patterns:
 {
   "agents": {
     "defaults": {
-      "workspace": "~/.skykoi/workspace",
+      "workspace": "~/.SKYKOI/workspace",
       "sandbox": {
         "mode": "non-main"
       }
@@ -283,7 +283,7 @@ Mitigation patterns:
       {
         "id": "main",
         "default": true,
-        "workspace": "~/.skykoi/workspace",
+        "workspace": "~/.SKYKOI/workspace",
         "sandbox": { "mode": "off" }
       }
     ]
@@ -291,7 +291,7 @@ Mitigation patterns:
 }
 ```
 
-Legacy `agent.*` configs are migrated by `SkyKoi doctor`; prefer `agents.defaults` + `agents.list` going forward.
+Legacy `agent.*` configs are migrated by `SKYKOI doctor`; prefer `agents.defaults` + `agents.list` going forward.
 
 ---
 
@@ -348,13 +348,13 @@ After configuring multi-agent sandbox and tools:
 1. **Check agent resolution:**
 
    ```exec
-   SkyKoi agents list --bindings
+   SKYKOI agents list --bindings
    ```
 
 2. **Verify sandbox containers:**
 
    ```exec
-   docker ps --filter "name=SkyKoi-sbx-"
+   docker ps --filter "name=SKYKOI-sbx-"
    ```
 
 3. **Test tool restrictions:**
@@ -364,7 +364,7 @@ After configuring multi-agent sandbox and tools:
 4. **Monitor logs:**
 
    ```exec
-   tail -f "${SKYKOI_STATE_DIR:-$HOME/.skykoi}/logs/gateway.log" | grep -E "routing|sandbox|tools"
+   tail -f "${SKYKOI_STATE_DIR:-$HOME/.SKYKOI}/logs/gateway.log" | grep -E "routing|sandbox|tools"
    ```
 
 ---

package/docs/tools/plugin.md

@@ -1,5 +1,5 @@
 ---
-summary: "SkyKoi plugins/extensions: discovery, config, and safety"
+summary: "SKYKOI plugins/extensions: discovery, config, and safety"
 read_when:
   - Adding or modifying plugins/extensions
   - Documenting plugin install or load rules
@@ -10,11 +10,11 @@ title: "Plugins"
 
 ## Quick start (new to plugins?)
 
-A plugin is just a **small code module** that extends SkyKoi with extra
+A plugin is just a **small code module** that extends SKYKOI with extra
 features (commands, tools, and Gateway RPC).
 
 Most of the time, you’ll use plugins when you want a feature that’s not built
-into core SkyKoi yet (or you want to keep optional features out of your main
+into core SKYKOI yet (or you want to keep optional features out of your main
 install).
 
 Fast path:
@@ -22,13 +22,13 @@ Fast path:
 1. See what’s already loaded:
 
 ```bash
-SkyKoi plugins list
+SKYKOI plugins list
 ```
 
 2. Install an official plugin (example: Voice Call):
 
 ```bash
-SkyKoi plugins install @SkyKoi/voice-call
+SKYKOI plugins install @SKYKOI/voice-call
 ```
 
 3. Restart the Gateway, then configure under `plugins.entries.<id>.config`.
@@ -37,21 +37,21 @@ See [Voice Call](/plugins/voice-call) for a concrete example plugin.
 
 ## Available plugins (official)
 
-- Microsoft Teams is plugin-only as of 2026.1.15; install `@SkyKoi/msteams` if you use Teams.
+- Microsoft Teams is plugin-only as of 2026.1.15; install `@SKYKOI/msteams` if you use Teams.
 - Memory (Core) — bundled memory search plugin (enabled by default via `plugins.slots.memory`)
 - Memory (LanceDB) — bundled long-term memory plugin (auto-recall/capture; set `plugins.slots.memory = "memory-lancedb"`)
-- [Voice Call](/plugins/voice-call) — `@SkyKoi/voice-call`
-- [Zalo Personal](/plugins/zalouser) — `@SkyKoi/zalouser`
-- [Matrix](/channels/matrix) — `@SkyKoi/matrix`
-- [Nostr](/channels/nostr) — `@SkyKoi/nostr`
-- [Zalo](/channels/zalo) — `@SkyKoi/zalo`
-- [Microsoft Teams](/channels/msteams) — `@SkyKoi/msteams`
+- [Voice Call](/plugins/voice-call) — `@SKYKOI/voice-call`
+- [Zalo Personal](/plugins/zalouser) — `@SKYKOI/zalouser`
+- [Matrix](/channels/matrix) — `@SKYKOI/matrix`
+- [Nostr](/channels/nostr) — `@SKYKOI/nostr`
+- [Zalo](/channels/zalo) — `@SKYKOI/zalo`
+- [Microsoft Teams](/channels/msteams) — `@SKYKOI/msteams`
 - Google Antigravity OAuth (provider auth) — bundled as `google-antigravity-auth` (disabled by default)
 - Gemini CLI OAuth (provider auth) — bundled as `google-gemini-cli-auth` (disabled by default)
 - Qwen OAuth (provider auth) — bundled as `qwen-portal-auth` (disabled by default)
 - Copilot Proxy (provider auth) — local VS Code Copilot Proxy bridge; distinct from built-in `github-copilot` device login (bundled, disabled by default)
 
-SkyKoi plugins are **TypeScript modules** loaded at runtime via jiti. **Config
+SKYKOI plugins are **TypeScript modules** loaded at runtime via jiti. **Config
 validation does not execute plugin code**; it uses the plugin manifest and JSON
 Schema instead. See [Plugin manifest](/plugins/manifest).
 
@@ -75,7 +75,7 @@ Plugins can access selected core helpers via `api.runtime`. For telephony TTS:
 
 ```ts
 const result = await api.runtime.tts.textToSpeechTelephony({
-  text: "Hello from SkyKoi",
+  text: "Hello from SKYKOI",
   cfg: api.config,
 });
 ```
@@ -88,7 +88,7 @@ Notes:
 
 ## Discovery & precedence
 
-SkyKoi scans, in order:
+SKYKOI scans, in order:
 
 1. Config paths
 
@@ -96,23 +96,23 @@ SkyKoi scans, in order:
 
 2. Workspace extensions
 
-- `<workspace>/.skykoi/extensions/*.ts`
-- `<workspace>/.skykoi/extensions/*/index.ts`
+- `<workspace>/.SKYKOI/extensions/*.ts`
+- `<workspace>/.SKYKOI/extensions/*/index.ts`
 
 3. Global extensions
 
-- `~/.skykoi/extensions/*.ts`
-- `~/.skykoi/extensions/*/index.ts`
+- `~/.SKYKOI/extensions/*.ts`
+- `~/.SKYKOI/extensions/*/index.ts`
 
-4. Bundled extensions (shipped with SkyKoi, **disabled by default**)
+4. Bundled extensions (shipped with SKYKOI, **disabled by default**)
 
-- `<SkyKoi>/extensions/*`
+- `<SKYKOI>/extensions/*`
 
 Bundled plugins must be enabled explicitly via `plugins.entries.<id>.enabled`
-or `SkyKoi plugins enable <id>`. Installed plugins are enabled by default,
+or `SKYKOI plugins enable <id>`. Installed plugins are enabled by default,
 but can be disabled the same way.
 
-Each plugin must include a `SkyKoi.plugin.json` file in its root. If a path
+Each plugin must include a `SKYKOI.plugin.json` file in its root. If a path
 points at a file, the plugin root is the file's directory and must contain the
 manifest.
 
@@ -121,12 +121,12 @@ wins and lower-precedence copies are ignored.
 
 ### Package packs
 
-A plugin directory may include a `package.json` with `SkyKoi.extensions`:
+A plugin directory may include a `package.json` with `SKYKOI.extensions`:
 
 ```json
 {
   "name": "my-pack",
-  "SkyKoi": {
+  "SKYKOI": {
     "extensions": ["./src/safety.ts", "./src/tools.ts"]
   }
 }
@@ -140,15 +140,15 @@ If your plugin imports npm deps, install them in that directory so
 
 ### Channel catalog metadata
 
-Channel plugins can advertise onboarding metadata via `SkyKoi.channel` and
-install hints via `SkyKoi.install`. This keeps the core catalog data-free.
+Channel plugins can advertise onboarding metadata via `SKYKOI.channel` and
+install hints via `SKYKOI.install`. This keeps the core catalog data-free.
 
 Example:
 
 ```json
 {
-  "name": "@SkyKoi/nextcloud-talk",
-  "SkyKoi": {
+  "name": "@SKYKOI/nextcloud-talk",
+  "SKYKOI": {
     "extensions": ["./index.ts"],
     "channel": {
       "id": "nextcloud-talk",
@@ -161,7 +161,7 @@ Example:
       "aliases": ["nc-talk", "nc"]
     },
     "install": {
-      "npmSpec": "@SkyKoi/nextcloud-talk",
+      "npmSpec": "@SKYKOI/nextcloud-talk",
       "localPath": "extensions/nextcloud-talk",
       "defaultChoice": "npm"
     }
@@ -169,16 +169,16 @@ Example:
 }
 ```
 
-SkyKoi can also merge **external channel catalogs** (for example, an MPM
+SKYKOI can also merge **external channel catalogs** (for example, an MPM
 registry export). Drop a JSON file at one of:
 
-- `~/.skykoi/mpm/plugins.json`
-- `~/.skykoi/mpm/catalog.json`
-- `~/.skykoi/plugins/catalog.json`
+- `~/.SKYKOI/mpm/plugins.json`
+- `~/.SKYKOI/mpm/catalog.json`
+- `~/.SKYKOI/plugins/catalog.json`
 
 Or point `SKYKOI_PLUGIN_CATALOG_PATHS` (or `SKYKOI_MPM_CATALOG_PATHS`) at
 one or more JSON files (comma/semicolon/`PATH`-delimited). Each file should
-contain `{ "entries": [ { "name": "@scope/pkg", "SkyKoi": { "channel": {...}, "install": {...} } } ] }`.
+contain `{ "entries": [ { "name": "@scope/pkg", "SKYKOI": { "channel": {...}, "install": {...} } } ] }`.
 
 ## Plugin IDs
 
@@ -187,7 +187,7 @@ Default plugin ids:
 - Package packs: `package.json` `name`
 - Standalone file: file base name (`~/.../voice-call.ts` → `voice-call`)
 
-If a plugin exports `id`, SkyKoi uses it but warns when it doesn’t match the
+If a plugin exports `id`, SKYKOI uses it but warns when it doesn’t match the
 configured id.
 
 ## Config
@@ -222,7 +222,7 @@ Validation rules (strict):
 - Unknown `channels.<id>` keys are **errors** unless a plugin manifest declares
   the channel id.
 - Plugin config is validated using the JSON Schema embedded in
-  `SkyKoi.plugin.json` (`configSchema`).
+  `SKYKOI.plugin.json` (`configSchema`).
 - If a plugin is disabled, its config is preserved and a **warning** is emitted.
 
 ## Plugin slots (exclusive categories)
@@ -247,7 +247,7 @@ are disabled with diagnostics.
 
 The Control UI uses `config.schema` (JSON Schema + `uiHints`) to render better forms.
 
-SkyKoi augments `uiHints` at runtime based on discovered plugins:
+SKYKOI augments `uiHints` at runtime based on discovered plugins:
 
 - Adds per-plugin labels for `plugins.entries.<id>` / `.enabled` / `.config`
 - Merges optional plugin-provided config field hints under:
@@ -279,24 +279,24 @@ Example:
 ## CLI
 
 ```bash
-SkyKoi plugins list
-SkyKoi plugins info <id>
-SkyKoi plugins install <path>                 # copy a local file/dir into ~/.skykoi/extensions/<id>
-SkyKoi plugins install ./extensions/voice-call # relative path ok
-SkyKoi plugins install ./plugin.tgz           # install from a local tarball
-SkyKoi plugins install ./plugin.zip           # install from a local zip
-SkyKoi plugins install -l ./extensions/voice-call # link (no copy) for dev
-SkyKoi plugins install @SkyKoi/voice-call # install from npm
-SkyKoi plugins update <id>
-SkyKoi plugins update --all
-SkyKoi plugins enable <id>
-SkyKoi plugins disable <id>
-SkyKoi plugins doctor
+SKYKOI plugins list
+SKYKOI plugins info <id>
+SKYKOI plugins install <path>                 # copy a local file/dir into ~/.SKYKOI/extensions/<id>
+SKYKOI plugins install ./extensions/voice-call # relative path ok
+SKYKOI plugins install ./plugin.tgz           # install from a local tarball
+SKYKOI plugins install ./plugin.zip           # install from a local zip
+SKYKOI plugins install -l ./extensions/voice-call # link (no copy) for dev
+SKYKOI plugins install @SKYKOI/voice-call # install from npm
+SKYKOI plugins update <id>
+SKYKOI plugins update --all
+SKYKOI plugins enable <id>
+SKYKOI plugins disable <id>
+SKYKOI plugins doctor
 ```
 
 `plugins update` only works for npm installs tracked under `plugins.installs`.
 
-Plugins may also register their own top‑level commands (example: `SkyKoi voicecall`).
+Plugins may also register their own top‑level commands (example: `SKYKOI voicecall`).
 
 ## Plugin API (overview)
 
@@ -313,7 +313,7 @@ event-driven automation without a separate hook pack install.
 ### Example
 
 ```
-import { registerPluginHooksFromDir } from "SkyKoi/plugin-sdk";
+import { registerPluginHooksFromDir } from "SKYKOI/plugin-sdk";
 
 export default function register(api) {
   registerPluginHooksFromDir(api, "./hooks");
@@ -324,18 +324,18 @@ Notes:
 
 - Hook directories follow the normal hook structure (`HOOK.md` + `handler.ts`).
 - Hook eligibility rules still apply (OS/bins/env/config requirements).
-- Plugin-managed hooks show up in `SkyKoi hooks list` with `plugin:<id>`.
-- You cannot enable/disable plugin-managed hooks via `SkyKoi hooks`; enable/disable the plugin instead.
+- Plugin-managed hooks show up in `SKYKOI hooks list` with `plugin:<id>`.
+- You cannot enable/disable plugin-managed hooks via `SKYKOI hooks`; enable/disable the plugin instead.
 
 ## Provider plugins (model auth)
 
 Plugins can register **model provider auth** flows so users can run OAuth or
-API-key setup inside SkyKoi (no external scripts needed).
+API-key setup inside SKYKOI (no external scripts needed).
 
 Register a provider via `api.registerProvider(...)`. Each provider exposes one
 or more auth methods (OAuth, API key, device code, etc.). These methods power:
 
-- `SkyKoi models auth login --provider <id> [--method <id>]`
+- `SKYKOI models auth login --provider <id> [--method <id>]`
 
 Example:
 
@@ -561,7 +561,7 @@ Command handler context:
 - `isAuthorizedSender`: Whether the sender is an authorized user
 - `args`: Arguments passed after the command (if `acceptsArgs: true`)
 - `commandBody`: The full command text
-- `config`: The current SkyKoi config
+- `config`: The current SKYKOI config
 
 Command options:
 
@@ -624,14 +624,14 @@ it’s present in your workspace/managed skills locations.
 
 Recommended packaging:
 
-- Main package: `SkyKoi` (this repo)
-- Plugins: separate npm packages under `@SkyKoi/*` (example: `@SkyKoi/voice-call`)
+- Main package: `SKYKOI` (this repo)
+- Plugins: separate npm packages under `@SKYKOI/*` (example: `@SKYKOI/voice-call`)
 
 Publishing contract:
 
-- Plugin `package.json` must include `SkyKoi.extensions` with one or more entry files.
+- Plugin `package.json` must include `SKYKOI.extensions` with one or more entry files.
 - Entry files can be `.js` or `.ts` (jiti loads TS at runtime).
-- `SkyKoi plugins install <npm-spec>` uses `npm pack`, extracts into `~/.skykoi/extensions/<id>/`, and enables it in config.
+- `SKYKOI plugins install <npm-spec>` uses `npm pack`, extracts into `~/.SKYKOI/extensions/<id>/`, and enables it in config.
 - Config key stability: scoped packages are normalized to the **unscoped** id for `plugins.entries.*`.
 
 ## Example plugin: Voice Call
@@ -640,7 +640,7 @@ This repo includes a voice‑call plugin (Twilio or log fallback):
 
 - Source: `extensions/voice-call`
 - Skill: `skills/voice-call`
-- CLI: `SkyKoi voicecall start|status`
+- CLI: `SKYKOI voicecall start|status`
 - Tool: `voice_call`
 - RPC: `voicecall.start`, `voicecall.status`
 - Config (twilio): `provider: "twilio"` + `twilio.accountSid/authToken/from` (optional `statusCallbackUrl`, `twimlUrl`)
@@ -661,4 +661,4 @@ Plugins run in-process with the Gateway. Treat them as trusted code:
 Plugins can (and should) ship tests:
 
 - In-repo plugins can keep Vitest tests under `src/**` (example: `src/plugins/voice-call.plugin.test.ts`).
-- Separately published plugins should run their own CI (lint/build/test) and validate `SkyKoi.extensions` points at the built entrypoint (`dist/index.js`).
+- Separately published plugins should run their own CI (lint/build/test) and validate `SKYKOI.extensions` points at the built entrypoint (`dist/index.js`).

package/docs/tools/skills-config.md

@@ -8,7 +8,7 @@ title: "Skills Config"
 
 # Skills Config
 
-All skills-related configuration lives under `skills` in `~/.skykoi/skykoi.json`.
+All skills-related configuration lives under `skills` in `~/.SKYKOI/SKYKOI.json`.
 
 ```json5
 {
@@ -60,7 +60,7 @@ Per-skill fields:
 ## Notes
 
 - Keys under `entries` map to the skill name by default. If a skill defines
-  `metadata.skykoi.skillKey`, use that key instead.
+  `metadata.SKYKOI.skillKey`, use that key instead.
 - Changes to skills are picked up on the next agent turn when the watcher is enabled.
 
 ### Sandboxed skills + env vars