@openparachute/agent 0.1.2 → 0.2.2

package/.claude/skills/init-first-agent/SKILL.md

@@ -1,120 +0,0 @@
----
-name: init-first-agent
-description: Walk the operator through creating the first NanoClaw agent for a DM channel — resolve the operator's channel identity, wire the DM messaging group to a new agent, and trigger a welcome DM via the normal delivery path. Use after channel credentials are configured and the service is running.
----
-
-# Init First Agent
-
-Stand up the first NanoClaw agent for a channel and verify end-to-end delivery by having the agent DM the operator. Everything the skill does is idempotent — rerunning is safe.
-
-## Prerequisites
-
-- **Service running.** Check: `launchctl list | grep nanoclaw` (macOS) or `systemctl --user status nanoclaw` (Linux). If stopped, tell the user to run `/setup` first.
-- **Target channel installed.** At least one `/add-<channel>` skill has run, credentials are in `.env`, and the adapter is uncommented in `src/channels/index.ts`.
-- **Adapter connected.** Tail `logs/nanoclaw.log` — look for a recent `channel setup` / `adapter connected` line for the target channel.
-
-## 1. Pick the channel
-
-Read `src/channels/index.ts` to find enabled channels (uncommented imports). Cross-check `.env` for the relevant credentials.
-
-AskUserQuestion: "Which channel should host the welcome DM?" with one option per enabled channel (Discord, Slack, Telegram, WhatsApp, Webex, Teams, Google Chat, Matrix, iMessage, Resend, …).
-
-Record the choice as `CHANNEL` (lowercase, e.g. `discord`).
-
-## 2. Ask for the operator's identity
-
-Read the channel's own skill for its `## Channel Info > how-to-find-id` section (e.g. `.claude/skills/add-discord/SKILL.md`, `.claude/skills/add-telegram/SKILL.md`). Show those instructions to the user in plain text.
-
-Then ask in plain text (NOT `AskUserQuestion` — these are free-form):
-
-1. **Your user id on this channel** — e.g. a Discord user ID, Telegram user ID, Slack user ID. Record as `USER_HANDLE`.
-2. **Your display name** — human name, used to name the agent group (`dm-with-<normalized>`) and as the welcome-message addressee. Record as `DISPLAY_NAME`.
-3. **Agent persona name** — the assistant's display name. Default: `DISPLAY_NAME`. Record as `AGENT_NAME`.
-
-## 3. Resolve the DM platform id
-
-This depends on whether the channel supports cold DM via `adapter.openDM`.
-
-**Channels without cold DM (direct-addressable): telegram, whatsapp, imessage, matrix, resend.** The user handle doubles as the DM chat id. Set:
-
-```
-PLATFORM_ID=${CHANNEL}:${USER_HANDLE}
-```
-
-Skip to step 4.
-
-**Channels with cold DM (resolution-required): discord, slack, teams, webex, gchat.** The bot can DM cold at runtime via Chat SDK, but this skill runs standalone — it can't call the adapter. Two resolutions:
-
-### 3a. User DMs the bot once (Discord / Slack / Teams / Webex / gChat)
-
-Tell the user:
-
-> Send any single message to the bot as a DM from your account on `${CHANNEL}`. The router will record the DM as a messaging group. Reply `done` here when you've sent the message.
-
-Wait for the user's confirmation. Then look up the most recent DM messaging groups:
-
-```bash
-sqlite3 data/v2.db "SELECT id, platform_id, name, created_at FROM messaging_groups WHERE channel_type='${CHANNEL}' AND is_group=0 ORDER BY created_at DESC LIMIT 5"
-```
-
-Show the top rows to the user and confirm which `platform_id` is theirs (usually the most recent). Record as `PLATFORM_ID`. If none appeared, check `logs/nanoclaw.log` for `unknown_sender` drops — the adapter might be rejecting inbound due to connection or permission issues.
-
-### 3b. Telegram pair-code path (if the user prefers not to DM first)
-
-For Telegram only, there's an existing pair-code primitive. When you run this tool, take the output and extract the pairing code. Then show it to the user in plain text and ask the user to send the code in the Telegram chat to complete the pairing.
-
-```bash
-npx tsx setup/index.ts --step pair-telegram -- --intent new-agent:dm-with-<folder>
-```
-
-Parse the `PAIR_TELEGRAM_ISSUED` status block for `CODE` and follow the `REMINDER_TO_ASSISTANT` line in that block. Then wait for the `PAIR_TELEGRAM` block — read `PLATFORM_ID` and `PAIRED_USER_ID` from it. telegram.ts's interceptor has already upserted the user and granted owner if none existed yet. Use `PLATFORM_ID` and `PAIRED_USER_ID` directly in step 4.
-
-## 4. Run the init script
-
-```bash
-npx tsx scripts/init-first-agent.ts \
-  --channel "${CHANNEL}" \
-  --user-id "${CHANNEL}:${USER_HANDLE}" \
-  --platform-id "${PLATFORM_ID}" \
-  --display-name "${DISPLAY_NAME}" \
-  --agent-name "${AGENT_NAME}"
-```
-
-Add `--welcome "System instruction: ..."` to override the default welcome prompt.
-
-The script:
-1. Upserts the `users` row and grants `owner` role if no owner exists.
-2. Creates the `agent_groups` row and calls `initGroupFilesystem` at `groups/dm-with-<name>/`.
-3. Reuses or creates the DM `messaging_groups` row.
-4. Wires them via `messaging_group_agents` (which auto-creates the companion `agent_destinations` row).
-5. Hands the welcome message to the running service via its CLI socket (`data/cli.sock`), targeting the DM messaging group. The service routes it into the DM session, which wakes the container synchronously. If the socket isn't reachable (service down), falls back to a direct `inbound.db` write that the next host sweep picks up.
-
-Show the script's output to the user.
-
-## 5. Verify
-
-The welcome DM is queued synchronously; the only wait is container cold-start (~60s on first launch) before the agent processes the message and the reply flows through `outbound.db` to the channel.
-
-Do not tail the log or poll in a sleep loop. Ask the user in plain text:
-
-> The welcome DM should arrive shortly. Let me know when you've received it (or if it doesn't arrive within two minutes).
-
-Wait for the user's reply. If they confirm receipt, the skill is done.
-
-If they say it didn't arrive, then diagnose using the DB directly (no waiting loops required — the message either delivered or it didn't):
-
-- `sqlite3 data/v2-sessions/<agent-group-id>/sessions/<session-id>/outbound.db "SELECT id, status, created_at FROM messages_out ORDER BY created_at DESC LIMIT 5"` — check for stuck `pending` rows. Replace `<agent-group-id>` and `<session-id>` with the values from the script's output.
-- `grep -E 'Unauthorized channel destination|container.*exited|error' logs/nanoclaw.log | tail -20` — look for ACL rejections or container crashes.
-- `ls data/v2-sessions/<agent-group-id>/sessions/*/outbound.db` — confirm the session exists.
-
-## Troubleshooting
-
-**"Missing required args"** — the script wants `--channel`, `--user-id`, `--platform-id`, `--display-name` at minimum. Re-check the command you assembled.
-
-**No `messaging_groups` row appears after the user DMs (step 3a)** — the router silently drops messages from unknown senders under `strict` policy but still creates the `messaging_groups` row. If the row is missing entirely, the adapter isn't receiving the inbound message. Check `logs/nanoclaw.log` for adapter errors (auth, gateway disconnect, rate limit).
-
-**Owner already exists** — `hasAnyOwner()` returned true, so the grant is skipped silently. That's fine; the script still creates the agent and wiring. Reassigning ownership needs a separate flow (not this skill).
-
-**Wrong person got the welcome DM** — the `--platform-id` you passed is someone else's DM channel. Rerun with the correct one; the script is idempotent on user/messaging-group/agent-group but writes a new session welcome each run.
-
-**Agent group name collision** — if `dm-with-<display-name>` already exists (e.g. rerunning with the same display name), the script reuses it. Pass a different `--display-name` to get a distinct folder.

package/.claude/skills/init-onecli/SKILL.md

@@ -1,270 +0,0 @@
----
-name: init-onecli
-description: Install and initialize OneCLI Agent Vault. Migrates existing .env credentials to the vault. Use after /update-nanoclaw brings in OneCLI as a breaking change, or for first-time OneCLI setup.
----
-
-# Initialize OneCLI Agent Vault
-
-This skill installs OneCLI, configures the Agent Vault gateway, and migrates any existing `.env` credentials into it. Run this after `/update-nanoclaw` introduces OneCLI as a breaking change, or any time OneCLI needs to be set up from scratch.
-
-**Principle:** When something is broken or missing, fix it. Don't tell the user to go fix it themselves unless it genuinely requires their manual action (e.g. pasting a token).
-
-## Phase 1: Pre-flight
-
-### Check if OneCLI is already working
-
-```bash
-onecli version 2>/dev/null
-```
-
-If the command succeeds, OneCLI is installed, check for an Anthropic secret:
-
-```bash
-onecli secrets list
-```
-
-If an Anthropic secret exists, tell the user OneCLI is already configured and working. Use AskUserQuestion:
-
-1. **Keep current setup** — description: "OneCLI is installed and has credentials configured. Nothing to do."
-2. **Reconfigure** — description: "Start fresh — reinstall OneCLI and re-register credentials."
-
-If they choose to keep, skip to Phase 5 (Verify). If they choose to reconfigure, continue.
-
-### Check for native credential proxy
-
-```bash
-grep "credential-proxy" src/index.ts 2>/dev/null
-```
-
-If `startCredentialProxy` is imported, the native credential proxy skill is active. Tell the user: "You're currently using the native credential proxy (`.env`-based). This skill will switch you to OneCLI's Agent Vault, which adds per-agent policies and rate limits. Your `.env` credentials will be migrated to the vault."
-
-Use AskUserQuestion:
-1. **Continue** — description: "Switch to OneCLI Agent Vault."
-2. **Cancel** — description: "Keep the native credential proxy."
-
-If they cancel, stop.
-
-### Check the codebase expects OneCLI
-
-```bash
-grep "@onecli-sh/sdk" package.json
-```
-
-If `@onecli-sh/sdk` is NOT in package.json, the codebase hasn't been updated to use OneCLI yet. Tell the user to run `/update-nanoclaw` first to get the OneCLI integration, then retry `/init-onecli`. Stop here.
-
-## Phase 2: Install OneCLI
-
-### Install the gateway and CLI
-
-```bash
-curl -fsSL onecli.sh/install | sh
-curl -fsSL onecli.sh/cli/install | sh
-```
-
-Verify: `onecli version`
-
-If the command is not found, the CLI was likely installed to `~/.local/bin/`. Add it to PATH:
-
-```bash
-export PATH="$HOME/.local/bin:$PATH"
-grep -q '.local/bin' ~/.bashrc 2>/dev/null || echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.bashrc
-grep -q '.local/bin' ~/.zshrc 2>/dev/null || echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.zshrc
-```
-
-Re-verify with `onecli version`.
-
-### Configure the CLI
-
-Point the CLI at the local OneCLI instance, the ONECLI_URL was output from the install script above:
-
-```bash
-onecli config set api-host ${ONECLI_URL}
-```
-
-### Set ONECLI_URL in .env
-
-```bash
-grep -q 'ONECLI_URL' .env 2>/dev/null || echo 'ONECLI_URL=${ONECLI_URL}' >> .env
-```
-
-### Wait for gateway readiness
-
-The gateway may take a moment to start after installation. Poll for up to 15 seconds:
-
-```bash
-for i in $(seq 1 15); do
-  curl -sf ${ONECLI_URL}/health && break
-  sleep 1
-done
-```
-
-If it never becomes healthy, check if the gateway process is running:
-
-```bash
-ps aux | grep -i onecli | grep -v grep
-```
-
-If it's not running, try starting it manually: `onecli start`. If that fails, show the error and stop — the user needs to debug their OneCLI installation.
-
-## Phase 3: Migrate existing credentials
-
-### Scan .env for credentials to migrate
-
-Read the `.env` file and look for these credential variables:
-
-| .env variable | OneCLI secret type | Host pattern |
-|---|---|---|
-| `ANTHROPIC_API_KEY` | `anthropic` | `api.anthropic.com` |
-| `CLAUDE_CODE_OAUTH_TOKEN` | `anthropic` | `api.anthropic.com` |
-| `ANTHROPIC_AUTH_TOKEN` | `anthropic` | `api.anthropic.com` |
-
-Read `.env`:
-
-```bash
-cat .env
-```
-
-Parse the file for any of the credential variables listed above.
-
-### If credentials found in .env
-
-For each credential found, migrate it to OneCLI:
-
-**Anthropic API key** (`ANTHROPIC_API_KEY=sk-ant-...`):
-```bash
-onecli secrets create --name Anthropic --type anthropic --value <key> --host-pattern api.anthropic.com
-```
-
-**Claude OAuth token** (`CLAUDE_CODE_OAUTH_TOKEN=...` or `ANTHROPIC_AUTH_TOKEN=...`):
-```bash
-onecli secrets create --name Anthropic --type anthropic --value <token> --host-pattern api.anthropic.com
-```
-
-After successful migration, remove the credential lines from `.env`. Use the Edit tool to remove only the credential variable lines (`ANTHROPIC_API_KEY`, `CLAUDE_CODE_OAUTH_TOKEN`, `ANTHROPIC_AUTH_TOKEN`). Keep all other `.env` entries intact (e.g. `ONECLI_URL`, `TELEGRAM_BOT_TOKEN`, channel tokens).
-
-Verify the secret was registered:
-```bash
-onecli secrets list
-```
-
-Tell the user: "Migrated your Anthropic credentials from `.env` to the OneCLI Agent Vault. The raw keys have been removed from `.env` — they're now managed by OneCLI and will be injected at request time without entering containers."
-
-### Offer to migrate other container-facing credentials
-
-After handling Anthropic credentials (whether migrated or freshly registered), scan `.env` again for remaining credential variables that containers use for outbound API calls.
-
-**Important:** Only migrate credentials that containers use via outbound HTTPS. Channel tokens (`TELEGRAM_BOT_TOKEN`, `SLACK_BOT_TOKEN`, `SLACK_APP_TOKEN`, `DISCORD_BOT_TOKEN`) are used by the NanoClaw host process to connect to messaging platforms — they must stay in `.env`.
-
-Known container-facing credentials:
-
-| .env variable | Secret name | Host pattern |
-|---|---|---|
-| `OPENAI_API_KEY` | `OpenAI` | `api.openai.com` |
-| `PARALLEL_API_KEY` | `Parallel` | `api.parallel.ai` |
-
-If any of these are found with non-empty values, present them to the user:
-
-AskUserQuestion (multiSelect): "These credentials are used by container agents for outbound API calls. Moving them to the vault means agents never see the raw keys, and you can apply rate limits and policies."
-
-- One option per credential found (e.g., "OPENAI_API_KEY" — description: "Used by voice transcription and other OpenAI integrations inside containers")
-- **Skip — keep them in .env** — description: "Leave these in .env for now. You can move them later."
-
-For each credential the user selects:
-
-```bash
-onecli secrets create --name <SecretName> --type api_key --value <value> --host-pattern <host>
-```
-
-If there are credential variables not in the table above that look container-facing (i.e. not a channel token), ask the user: "Is `<VARIABLE_NAME>` used by agents inside containers? If so, what API host does it authenticate against? (e.g., `api.example.com`)" — then migrate accordingly.
-
-After migration, remove the migrated lines from `.env` using the Edit tool. Keep channel tokens and any credentials the user chose not to migrate.
-
-Verify all secrets were registered:
-```bash
-onecli secrets list
-```
-
-### If no credentials found in .env
-
-No migration needed. Proceed to register credentials fresh.
-
-Check if OneCLI already has an Anthropic secret:
-```bash
-onecli secrets list
-```
-
-If an Anthropic secret already exists, skip to Phase 4.
-
-Otherwise, register credentials using the same flow as `/setup`:
-
-AskUserQuestion: Do you want to use your **Claude subscription** (Pro/Max) or an **Anthropic API key**?
-
-1. **Claude subscription (Pro/Max)** — description: "Uses your existing Claude Pro or Max subscription. You'll run `claude setup-token` in another terminal to get your token."
-2. **Anthropic API key** — description: "Pay-per-use API key from console.anthropic.com."
-
-#### Subscription path
-
-Tell the user to run `claude setup-token` in another terminal and copy the token it outputs. Do NOT collect the token in chat.
-
-Once they have the token, AskUserQuestion with two options:
-
-1. **Dashboard** — description: "Best if you have a browser on this machine. Open ${ONECLI_URL} and add the secret in the UI. Use type 'anthropic' and paste your token as the value."
-2. **CLI** — description: "Best for remote/headless servers. Run: `onecli secrets create --name Anthropic --type anthropic --value YOUR_TOKEN --host-pattern api.anthropic.com`"
-
-#### API key path
-
-Tell the user to get an API key from https://console.anthropic.com/settings/keys if they don't have one.
-
-AskUserQuestion with two options:
-
-1. **Dashboard** — description: "Best if you have a browser on this machine. Open ${ONECLI_URL} and add the secret in the UI."
-2. **CLI** — description: "Best for remote/headless servers. Run: `onecli secrets create --name Anthropic --type anthropic --value YOUR_KEY --host-pattern api.anthropic.com`"
-
-#### After either path
-
-Ask them to let you know when done.
-
-**If the user's response happens to contain a token or key** (starts with `sk-ant-` or looks like a token): handle it gracefully — run the `onecli secrets create` command with that value on their behalf.
-
-**After user confirms:** verify with `onecli secrets list` that an Anthropic secret exists. If not, ask again.
-
-## Phase 4: Build and restart
-
-```bash
-pnpm run build
-```
-
-If build fails, diagnose and fix. Common issue: `@onecli-sh/sdk` not installed — run `pnpm install` first.
-
-Restart the service:
-- macOS (launchd): `launchctl kickstart -k gui/$(id -u)/com.nanoclaw`
-- Linux (systemd): `systemctl --user restart nanoclaw`
-- WSL/manual: stop and re-run `bash start-nanoclaw.sh`
-
-## Phase 5: Verify
-
-Check logs for successful OneCLI integration:
-
-```bash
-tail -30 logs/nanoclaw.log | grep -i "onecli\|gateway"
-```
-
-Expected: `OneCLI gateway config applied` messages when containers start.
-
-If the service is running and a channel is configured, tell the user to send a test message to verify the agent responds.
-
-Tell the user:
-- OneCLI Agent Vault is now managing credentials
-- Agents never see raw API keys — credentials are injected at the gateway level
-- To manage secrets: `onecli secrets list`, or open ${ONECLI_URL}
-- To add rate limits or policies: `onecli rules create --help`
-
-## Troubleshooting
-
-**"OneCLI gateway not reachable" in logs:** The gateway isn't running. Check with `curl -sf ${ONECLI_URL}/health`. Start it with `onecli start` if needed.
-
-**Container gets no credentials:** Verify `ONECLI_URL` is set in `.env` and the gateway has an Anthropic secret (`onecli secrets list`).
-
-**Old .env credentials still present:** This skill should have removed them. Double-check `.env` for `ANTHROPIC_API_KEY`, `CLAUDE_CODE_OAUTH_TOKEN`, or `ANTHROPIC_AUTH_TOKEN` and remove them manually if still present.
-
-**Port 10254 already in use:** Another OneCLI instance may be running. Check with `lsof -i :10254` and kill the old process, or configure a different port.

package/.claude/skills/manage-channels/SKILL.md

@@ -1,87 +0,0 @@
----
-name: manage-channels
-description: Wire channels to agent groups, manage isolation levels, add new channel groups. Use after adding a channel, during setup, or standalone to reconfigure.
----
-
-# Manage Channels
-
-Wire messaging channels to agent groups. See `docs/isolation-model.md` for the full isolation model.
-
-Privilege is a **user-level** concept, not a channel-level one (see `src/db/user-roles.ts`, `src/access.ts`). There is no "main channel" / "main group" — any user can be granted `owner` or `admin` (global or scoped to an agent group) via `grantRole()`, and messages from unknown senders are gated per-messaging-group by `unknown_sender_policy` (`strict` | `request_approval` | `public`).
-
-## Assess Current State
-
-Read the central DB (`data/v2.db`) — query `agent_groups`, `messaging_groups`, `messaging_group_agents`, `users`, and `user_roles` tables. Also check `.env` for channel tokens and `src/channels/index.ts` for uncommented imports.
-
-Categorize channels as: **wired** (has DB entities + messaging_group_agents row), **configured but unwired** (has credentials + barrel import, no DB entities), or **not configured**.
-
-If the instance has no owner yet (`SELECT COUNT(*) FROM user_roles WHERE role='owner' AND agent_group_id IS NULL` returns 0), tell the user they should run `/init-first-agent` first — it stands up the first agent group, promotes the operator to owner, and verifies delivery end-to-end by having the agent DM them. Then return here for any additional channels/groups.
-
-## First Channel (No Agent Groups Exist)
-
-**Delegate to `/init-first-agent`.** It handles: channel choice, operator identity lookup, DM platform id resolution (with cold-DM or pair-code fallback), agent group creation, wiring, and the welcome DM. Return here afterward for any additional channels.
-
-## Wire New Channel
-
-For each unwired channel:
-
-1. Read its SKILL.md `## Channel Info` for terminology, how-to-find-id, typical-use, and default-isolation
-2. Ask for the platform ID using the platform's terminology
-3. Ask the isolation question (see below)
-4. Register with the appropriate flags
-
-### Isolation Question
-
-Present a multiple-choice with a contextual recommendation. The three options:
-
-- **Same conversation** (`--session-mode "agent-shared"` + existing folder) — all messages land in one session. Recommend for webhook + chat combos (GitHub + Slack).
-- **Same agent, separate conversations** (`--session-mode "shared"` + existing folder) — shared workspace/memory, independent threads. Recommend for same user across platforms.
-- **Separate agent** (new `--folder`) — full isolation. Recommend when different people are involved.
-
-Use the channel's `typical-use` and `default-isolation` fields to pick the recommendation. Offer to explain more if the user is unsure — reference `docs/isolation-model.md` for the detailed explanation.
-
-### Register Command
-
-```bash
-pnpm exec tsx setup/index.ts --step register -- \
-  --platform-id "<id>" --name "<name>" \
-  --folder "<folder>" --channel "<type>" \
-  --session-mode "<shared|agent-shared|per-thread>" \
-  --assistant-name "<name>"
-```
-
-The `register` step creates the agent group (reusing it if the folder already exists), the messaging group, and the wiring row. `createMessagingGroupAgent` auto-creates the companion `agent_destinations` row so the agent can address the channel by name — no separate destination step needed.
-
-For separate agents, also ask for a folder name and optionally a different assistant name.
-
-## Add Channel Group
-
-When adding another group/chat on an already-configured platform (e.g. a second Telegram group):
-
-1. **Telegram:** ask the isolation question first to determine intent (`wire-to:<folder>` for an existing agent, `new-agent:<folder>` for a fresh one). Run `pnpm exec tsx setup/index.ts --step pair-telegram -- --intent <intent>`, show the CODE (follow the `REMINDER_TO_ASSISTANT` line in the `PAIR_TELEGRAM_ISSUED` block) and tell the user to post `@<botname> CODE` in the target group (or DM the bot for a private chat). Wait for the `PAIR_TELEGRAM` block. The inbound interceptor has already created the `messaging_groups` row with `unknown_sender_policy = 'strict'` and upserted the paired user — `register` only needs to add the wiring:
-
-   ```bash
-   pnpm exec tsx setup/index.ts --step register -- \
-     --platform-id "<PLATFORM_ID>" --name "<group-name>" \
-     --folder "<folder>" --channel "telegram" \
-     --session-mode "<shared|agent-shared|per-thread>" \
-     --assistant-name "<name>"
-   ```
-
-2. **Other channels:** read the channel's SKILL.md `## Channel Info` for terminology and how-to-find-id. Ask for the new group/chat ID, ask the isolation question, then register. No package or credential changes needed.
-
-## Change Wiring
-
-1. Show current wiring (agent_groups × messaging_group_agents)
-2. Ask which channel to move and to which agent group
-3. Delete the old `messaging_group_agents` entry, create a new one
-4. Note: existing sessions stay with the old agent group; new messages route to the new one. The `agent_destinations` row created for the old wiring is NOT automatically removed — if you want the old agent to stop seeing the channel as a named target, delete it from `agent_destinations` manually.
-
-## Show Configuration
-
-Display a readable summary showing:
-
-- **Agent groups** with their wired channels (from `messaging_group_agents`)
-- **Configured-but-unwired** channels (credentials present, no DB entities)
-- **Unconfigured** channels
-- **Privileged users**: `SELECT user_id, role, agent_group_id FROM user_roles ORDER BY role='owner' DESC`

package/.claude/skills/manage-mounts/SKILL.md

@@ -1,47 +0,0 @@
----
-name: manage-mounts
-description: Configure which host directories agent containers can access. View, add, or remove mount allowlist entries. Triggers on "mounts", "mount allowlist", "agent access to directories", "container mounts".
----
-
-# Manage Mounts
-
-Configure which host directories NanoClaw agent containers can access. The mount allowlist lives at `~/.config/nanoclaw/mount-allowlist.json`.
-
-## Show Current Config
-
-```bash
-cat ~/.config/nanoclaw/mount-allowlist.json 2>/dev/null || echo "No mount allowlist configured"
-```
-
-Show the current config to the user in a readable format: which directories are allowed, whether non-main agents are read-only.
-
-## Add Directories
-
-Ask which directories the user wants agents to access. For each path:
-- Validate the path exists
-- Ask if it should be read-only for non-main agents (default: yes)
-
-Build the JSON config and write it:
-
-```bash
-npx tsx setup/index.ts --step mounts --force -- --json '{"allowedRoots":[{"path":"/path/to/dir","readOnly":false}],"blockedPatterns":[],"nonMainReadOnly":true}'
-```
-
-Use `--force` to overwrite the existing config.
-
-## Remove Directories
-
-Read the current config, show it, ask which entry to remove, write the updated config.
-
-## Reset to Empty
-
-```bash
-npx tsx setup/index.ts --step mounts --force -- --empty
-```
-
-## After Changes
-
-Restart the service so containers pick up the new config:
-
-- macOS: `launchctl kickstart -k gui/$(id -u)/com.nanoclaw`
-- Linux: `systemctl --user restart nanoclaw`

package/.claude/skills/migrate-from-openclaw/MIGRATE_CRONS.md

@@ -1,100 +0,0 @@
-# Migrating OpenClaw Cron Jobs to NanoClaw Scheduled Tasks
-
-This file is referenced by SKILL.md Phase 5 when cron jobs are detected.
-
-**Before inserting tasks:** Read `src/db.ts` and search for `scheduled_tasks` to verify the current table schema. The schema below is a reference — if columns have been added, removed, or renamed, use the current schema from the source code.
-
-Also verify the `createTask` function signature in `src/db.ts` — it may be simpler to call it via a script than raw SQL.
-
-## OpenClaw Cron Job Format
-
-Source: `<STATE_DIR>/cron/jobs.json` (from `src/cron/types.ts`). If the file format doesn't match what's described below, read the actual file and adapt — OpenClaw may have changed the schema.
-
-The jobs file is `{ version: 1, jobs: CronJob[] }`. Each job has:
-- `id`, `name`, `description`, `enabled`, `deleteAfterRun`
-- `schedule`: `{ kind: "cron", expr: string, tz?: string }` | `{ kind: "every", everyMs: number }` | `{ kind: "at", at: string }`
-- `payload`: `{ kind: "agentTurn", message: string, model?, thinking?, timeoutSeconds? }` | `{ kind: "systemEvent", text: string }`
-- `sessionTarget`: `"main"` | `"isolated"` | `"current"` | `"session:<id>"`
-- `wakeMode`: `"next-heartbeat"` | `"now"`
-- `delivery`: `{ mode: "none" | "announce" | "webhook", channel?, to?, threadId?, bestEffort? }`
-- `failureAlert`: `{ after?: number, channel?, to?, cooldownMs? }` | `false`
-- `state`: runtime state (nextRunAtMs, lastRunStatus, consecutiveErrors, etc.)
-
-## NanoClaw `scheduled_tasks` Table
-
-Source: `src/db.ts`
-
-| Column | Type | Notes |
-|--------|------|-------|
-| `id` | TEXT PK | Unique task ID |
-| `group_folder` | TEXT | Target group directory (e.g. `"main"`) |
-| `chat_jid` | TEXT | Target chat JID |
-| `prompt` | TEXT | Task instructions |
-| `script` | TEXT | Optional bash pre-check script |
-| `schedule_type` | TEXT | `"cron"`, `"interval"`, or `"once"` |
-| `schedule_value` | TEXT | Cron expr, ms interval, or ISO timestamp |
-| `context_mode` | TEXT | `"group"` or `"isolated"` (default) |
-| `next_run` | TEXT | ISO timestamp — must be computed at insert time |
-| `last_run` | TEXT | null initially |
-| `last_result` | TEXT | null initially |
-| `status` | TEXT | `"active"`, `"paused"`, or `"completed"` |
-| `created_at` | TEXT | ISO timestamp |
-
-## Field Mapping
-
-- `schedule.kind:"cron"` + `schedule.expr` → `schedule_type:"cron"`, `schedule_value:<expr>`
-- `schedule.kind:"every"` + `schedule.everyMs` → `schedule_type:"interval"`, `schedule_value:<ms as string>`
-- `schedule.kind:"at"` + `schedule.at` → `schedule_type:"once"`, `schedule_value:<ISO timestamp>`
-- `payload.message` or `payload.text` → `prompt`
-- `sessionTarget:"isolated"` → `context_mode:"isolated"`, `sessionTarget:"main"` or `"current"` → `context_mode:"group"`
-
-## What Doesn't Map
-
-- `delivery.mode:"webhook"` — NanoClaw has no webhook delivery. Discuss with the user: this could be implemented as a task `script` that runs `curl` to hit the webhook endpoint.
-- `failureAlert` — NanoClaw has no failure alert system. Note this to the user.
-- `wakeMode` — NanoClaw tasks always wake the agent immediately.
-- `payload.model`, `payload.thinking`, `payload.timeoutSeconds` — NanoClaw doesn't support per-task model/thinking config. These are handled by the SDK.
-- `deleteAfterRun` — NanoClaw `"once"` tasks are marked `"completed"` after running, not deleted.
-
-## For Each Enabled Job
-
-1. Show what it does: name, schedule, prompt, delivery mode
-2. Explain any differences (no retry config, no webhook delivery, no failure alerts)
-3. If `delivery.mode:"webhook"`: discuss with the user — a task `script` with `curl` often suffices
-4. Ask if they want to keep this task
-
-## Inserting Tasks
-
-Insert directly into the SQLite database. This requires groups to be registered first (Phase 1). Use the registered group's `folder` and `chat_jid`:
-
-```bash
-pnpm exec tsx -e "
-const Database = require('better-sqlite3');
-const { CronExpressionParser } = require('cron-parser');
-const db = new Database('store/messages.db');
-// Compute next_run for cron tasks:
-// const interval = CronExpressionParser.parse('<expr>', { tz: process.env.TZ || 'UTC' });
-// const nextRun = interval.next().toISOString();
-db.prepare(\`INSERT INTO scheduled_tasks (id, group_folder, chat_jid, prompt, script, schedule_type, schedule_value, context_mode, next_run, status, created_at) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)\`).run(
-  'migrated-<original-id>',
-  '<group_folder>',
-  '<chat_jid>',
-  '<mapped prompt>',
-  null,
-  '<mapped schedule_type>',
-  '<mapped schedule_value>',
-  '<mapped context_mode>',
-  '<computed next_run ISO>',
-  'active',
-  new Date().toISOString()
-);
-db.close();
-"
-```
-
-**Computing `next_run`:**
-- `cron` tasks: use `CronExpressionParser.parse(expr, { tz }).next().toISOString()`
-- `interval` tasks: `new Date(Date.now() + ms).toISOString()`
-- `once` tasks: `next_run` equals `schedule_value`
-
-If groups haven't been registered yet (database doesn't exist), save the task details to `groups/main/openclaw-migration-tasks.md` with the exact SQL payloads, and tell the user: "These tasks will be created after `/setup` registers your groups."