Merge branch 'main' into skill/wiki
This commit is contained in:
gavrielc
100
.claude/skills/migrate-from-openclaw/MIGRATE_CRONS.md
Normal file
100
.claude/skills/migrate-from-openclaw/MIGRATE_CRONS.md
Normal file
@@ -0,0 +1,100 @@
|
||||
# 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
|
||||
npx 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."
|
||||
447
.claude/skills/migrate-from-openclaw/SKILL.md
Normal file
447
.claude/skills/migrate-from-openclaw/SKILL.md
Normal file
@@ -0,0 +1,447 @@
|
||||
---
|
||||
name: migrate-from-openclaw
|
||||
description: Migrate from OpenClaw to NanoClaw. Detects existing OpenClaw installation, extracts identity, channel credentials, scheduled tasks, and other config, then guides interactive migration. Triggers on "migrate from openclaw", "openclaw migration", "import from openclaw".
|
||||
---
|
||||
|
||||
# Migrate from OpenClaw
|
||||
|
||||
Guide the user through migrating their OpenClaw installation to NanoClaw. This is a conversation, not a batch job. Read OpenClaw state, discuss it with the user, make judgment calls together about what to bring over and how.
|
||||
|
||||
**Principle:** Never silently copy data. Read it, explain it, discuss where it belongs in NanoClaw's architecture, show proposed changes before applying. Credentials must be masked when displayed (first 4 + `...` + last 4 characters). Make judgment calls about what's core vs. reference material.
|
||||
|
||||
**UX:** Use `AskUserQuestion` for multiple-choice only. Use plain text for free-form input. Don't dump raw data — summarize and explain conversationally.
|
||||
|
||||
## Migration State File
|
||||
|
||||
Create `migration-state.md` in the project root at the start of Phase 0. Update it after each phase completes. This file is the single source of truth for the migration — if context is compacted or lost, re-read it to recover all decisions and progress.
|
||||
|
||||
Before starting any phase, re-read `migration-state.md` to ensure you have current state.
|
||||
|
||||
Sections to maintain (add data as each phase completes):
|
||||
|
||||
- **Progress** — checkbox list of phases (Phase 0–7)
|
||||
- **Discovery** — STATE_DIR, IDENTITY_NAME, channels, groups (with JID mappings), workspace files, cron job count, MCP servers
|
||||
- **Decisions** — assistant_name, group_model (shared/separate/main-only), main_group (folder + jid)
|
||||
- **Registered Groups** — table: folder, jid, channel, is_main
|
||||
- **Settings Migrated** — timezone, anthropic_credential (masked), sender_allowlist (created/skipped)
|
||||
- **Identity & Memory** — paths of files created, which CLAUDE.md was edited
|
||||
- **Channel Credentials** — table: channel, status, env_var
|
||||
- **Scheduled Tasks** — table: original_id, name, migrated/deferred
|
||||
- **Deferred / Not Applicable** — unsupported channels, discussed customizations, OpenClaw-only features
|
||||
|
||||
Keep it factual and terse — this is for machine recovery after compaction, not human reading. Delete the file at the end of Phase 7 (or offer to keep it as a record).
|
||||
|
||||
## Phase 0: Discovery
|
||||
|
||||
Run the discovery script to find and summarize the OpenClaw installation:
|
||||
|
||||
```bash
|
||||
npx tsx ${CLAUDE_SKILL_DIR}/scripts/discover-openclaw.ts
|
||||
```
|
||||
|
||||
If the user specifies a custom path, pass it: `--state-dir <path>`
|
||||
|
||||
Parse the status block. Key fields: STATUS, STATE_DIR, CHANNELS, WORKSPACE_FILES, DAILY_MEMORY_FILES, SKILL_COUNT, SKILLS, CRON_JOBS, MCP_SERVERS, IDENTITY_NAME, AGENT_COUNT, AGENT_IDS.
|
||||
|
||||
**Sanity-check the output:** The discovery script detects known structures but can silently miss data if OpenClaw's format has changed. Check `CONFIG_TOP_KEYS` and `CONFIG_CHANNEL_KEYS` — if you see keys the script didn't report on (e.g. a channel name not in CHANNELS, or a top-level section like `integrations` or `plugins`), read that section of the config directly with the Read tool. Also check `STATE_DIR_CONTENTS` for directories the script doesn't scan (e.g. unexpected folders alongside `workspace/`, `agents/`, `cron/`).
|
||||
|
||||
**If STATUS=not_found:** Tell the user no OpenClaw installation was detected at the standard locations (`~/.openclaw`, `~/.clawdbot`). Ask if they have a custom path. If not, exit.
|
||||
|
||||
**If STATUS=found:** Present a human-readable summary:
|
||||
|
||||
- "I found your OpenClaw installation at `<STATE_DIR>`."
|
||||
- Identity: name from IDENTITY.md (if found)
|
||||
- Workspace files: which of SOUL.md, USER.md, MEMORY.md, IDENTITY.md exist
|
||||
- Channels: list each, note which NanoClaw supports (whatsapp, telegram, slack, discord) and which it doesn't
|
||||
- Daily memory files: count (if any)
|
||||
- Skills: count and names (from workspace, shared, personal, project locations)
|
||||
- Cron jobs: count and names
|
||||
- MCP servers: count and names
|
||||
- Agents: count (relevant for Phase 1 groups discussion)
|
||||
|
||||
Then explain the key architectural differences. Don't dump a table — paraphrase conversationally:
|
||||
|
||||
- **Container isolation:** NanoClaw runs each agent in an isolated Linux container (Docker or Apple Container). OpenClaw runs everything in one process. This means stronger isolation but also means each group is its own sandbox.
|
||||
- **Group-based memory:** In OpenClaw, all groups under one agent share the same SOUL.md, MEMORY.md, and IDENTITY.md. In NanoClaw, each group has its own filesystem and CLAUDE.md. Shared state goes in `groups/global/CLAUDE.md` (mounted read-only into all non-main containers).
|
||||
- **Channel skills:** In OpenClaw, channels are configured in `openclaw.json`. In NanoClaw, channels are installed as code via skills (`/add-telegram`, `/add-whatsapp`, etc.) and configured through `.env` variables.
|
||||
- **Simpler config:** NanoClaw has no config file — behavior is in the code and `CLAUDE.md` files. Credentials live in `.env` or the OneCLI vault.
|
||||
|
||||
AskUserQuestion: "Ready to start migrating? I'll go through each area one at a time."
|
||||
1. **Yes, let's go** — proceed to Phase 1
|
||||
2. **Tell me more** — explain more about any area they ask about
|
||||
3. **Skip migration** — exit
|
||||
|
||||
## Phase 1: Groups and Architecture
|
||||
|
||||
**This discussion must happen before identity/memory, because the shared-vs-isolated decision determines where files go.**
|
||||
|
||||
If GROUP_COUNT > 0 or AGENT_COUNT > 1, this is a critical conversation. Even with just one group, explain the model difference so the user understands what they're getting into.
|
||||
|
||||
**OpenClaw model:** All groups routed to the same agent share one workspace — the same SOUL.md, MEMORY.md, IDENTITY.md, and tools. When you talk to the bot in your family chat or your work chat, it's the same agent with the same personality and memory. Only the session (conversation history) is separate per group.
|
||||
|
||||
**NanoClaw model:** Each group is a completely separate agent running in its own Linux container. Separate filesystem, separate memory, separate CLAUDE.md. The bot in your family chat and your work chat are different agents that don't know about each other — unless you explicitly share state via `groups/global/CLAUDE.md`, which is mounted read-only into all non-main containers.
|
||||
|
||||
Explain this conversationally. If the user only has one group, it's simple — just note the difference and move on. If they have multiple groups, discuss:
|
||||
|
||||
AskUserQuestion: "In OpenClaw, your groups shared the same personality and memory. In NanoClaw, each group is a fully separate agent. How would you like to handle this?"
|
||||
|
||||
1. **Shared personality (recommended if your groups had the same bot)** — "I'll put the shared personality, identity, and user context in `groups/global/CLAUDE.md`. Every group sees it. Each group can add its own customizations on top."
|
||||
2. **Fully separate** — "Each group gets its own independent personality and memory. Complete isolation between groups."
|
||||
3. **Just main group for now** — "Set up one group now. We can add others later."
|
||||
|
||||
Remember this choice — it determines where identity and memory files go in the next phase.
|
||||
|
||||
### Confirm assistant name
|
||||
|
||||
Before registering groups, confirm the assistant name — it's used for trigger patterns and CLAUDE.md templates.
|
||||
|
||||
IDENTITY_NAME from discovery gives the OpenClaw name. Ask the user: "Your OpenClaw assistant was named `<IDENTITY_NAME>`. Want to keep this name in NanoClaw?" If they want a different name, ask what it should be. If IDENTITY_NAME was empty, ask them to choose a name (default: "Andy").
|
||||
|
||||
The register step's `--assistant-name` flag writes `ASSISTANT_NAME` to `.env` and updates CLAUDE.md templates automatically — no manual `.env` write needed.
|
||||
|
||||
### Registering groups
|
||||
|
||||
The discovery script provides detected groups in the GROUPS field (format: `channel:id(name)=>nanoclaw_jid`). These are extracted from OpenClaw's session store and channel config.
|
||||
|
||||
For each group the user wants to bring over, pre-register it:
|
||||
|
||||
```bash
|
||||
npx tsx setup/index.ts --step register -- --jid "<nanoclaw_jid>" --name "<group_name>" --folder "<channel>_<slug>" --trigger "@<confirmed_name>" --channel <channel> --assistant-name "<confirmed_name>"
|
||||
```
|
||||
|
||||
Only pass `--assistant-name` on the first registration (it updates all CLAUDE.md templates globally).
|
||||
|
||||
Folder naming: `<channel>_<name-slug>` (e.g. `whatsapp_family-chat`, `telegram_dev-team`). Ask the user to confirm each group's name and folder.
|
||||
|
||||
For the first/primary group, add `--is-main --no-trigger-required`. Other groups default to requiring a trigger prefix.
|
||||
|
||||
**Important:** Registration requires the database to exist. If the environment step hasn't been run yet, run it first: `npx tsx setup/index.ts --step environment`. Registration also creates the group folder under `groups/` and copies the CLAUDE.md template.
|
||||
|
||||
Register groups from all channels — including channels NanoClaw doesn't yet support (signal, matrix, etc.). The registration stores the JID and metadata in the database, ready for when that channel is added later. Groups won't receive messages until their channel code is installed, but the registration, group folder, and CLAUDE.md will be ready.
|
||||
|
||||
## Phase 2: Settings from Config
|
||||
|
||||
Before identity/memory, extract settings from `openclaw.json` that map directly to NanoClaw setup. Read the config file with the Read tool (`<STATE_DIR>/openclaw.json` or `clawdbot.json`).
|
||||
|
||||
### Timezone
|
||||
|
||||
Check `agents.defaults.userTimezone` in the config. If present and it's a valid IANA timezone (e.g. `America/New_York`, `Asia/Jerusalem`), write it to `.env` as `TZ=<timezone>`. NanoClaw's setup step 2a reads `TZ` from `.env` (`src/config.ts:84-97`) and will skip the autodetection prompt.
|
||||
|
||||
### Anthropic Credentials
|
||||
|
||||
Check for Anthropic API keys or tokens in OpenClaw's auth system. OpenClaw stores credentials in `<STATE_DIR>/auth-profiles.json` or `<STATE_DIR>/agents/main/agent/auth-profiles.json` with this structure:
|
||||
|
||||
```json
|
||||
{
|
||||
"version": 1,
|
||||
"profiles": {
|
||||
"anthropic:default": {
|
||||
"type": "api_key", // or "token" or "oauth"
|
||||
"provider": "anthropic",
|
||||
"key": "sk-ant-..." // for api_key type
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Profile IDs follow `provider:identifier` format. Look for any profile where `provider` is `"anthropic"`. The credential field depends on the `type`:
|
||||
- `type: "api_key"` → `key` field (or `keyRef` for SecretRef)
|
||||
- `type: "token"` → `token` field (or `tokenRef` for SecretRef)
|
||||
- `type: "oauth"` → `access` field (OAuth access token, may need refresh)
|
||||
|
||||
Also check:
|
||||
1. `<STATE_DIR>/.env` — for `ANTHROPIC_API_KEY` or `CLAUDE_CODE_OAUTH_TOKEN`
|
||||
2. Config `models.providers` — for Anthropic provider entries with `apiKey`
|
||||
|
||||
If found, offer to save to `.env`. This pre-fills the NanoClaw setup credential step (step 4) so the user doesn't need to re-enter it. Use the same masking approach — show first 4 + last 4 characters, write the full value directly.
|
||||
|
||||
**Important:** If the credential uses `keyRef`/`tokenRef` with `source:"exec"` or `source:"file"`, explain that it can't be auto-extracted and the user will need to enter it during setup. For `type: "oauth"` credentials with an expiry in the past, warn the user the token may need to be refreshed during setup.
|
||||
|
||||
### Sender Allowlists
|
||||
|
||||
Read the channel configs for access control settings. OpenClaw stores these per-channel:
|
||||
- `channels.<channel>.allowFrom` — array of allowed sender IDs (E.164 for WhatsApp, numeric IDs for Telegram)
|
||||
- `channels.<channel>.dmPolicy` — `"open"`, `"allowlist"`, `"disabled"`
|
||||
- `channels.<channel>.groupPolicy` — `"open"`, `"allowlist"`, `"disabled"`
|
||||
- `channels.<channel>.groupAllowFrom` — array of allowed group member IDs
|
||||
|
||||
NanoClaw uses `~/.config/nanoclaw/sender-allowlist.json` with this format:
|
||||
```json
|
||||
{
|
||||
"default": { "allow": "*", "mode": "trigger" },
|
||||
"chats": {
|
||||
"<chat-jid>": {
|
||||
"allow": ["sender-id-1", "sender-id-2"],
|
||||
"mode": "trigger"
|
||||
}
|
||||
},
|
||||
"logDenied": true
|
||||
}
|
||||
```
|
||||
|
||||
Fields:
|
||||
- `allow`: `"*"` (all senders) or `string[]` (specific sender IDs)
|
||||
- `mode`: `"trigger"` (messages stored but trigger blocked for non-allowed senders) or `"drop"` (messages silently discarded before storage)
|
||||
- `logDenied`: optional boolean (default `true`), logs denied messages
|
||||
|
||||
If OpenClaw had allowlists configured, show the user what was set and offer to create the NanoClaw equivalent. Map:
|
||||
- `dmPolicy:"allowlist"` + `allowFrom` → per-chat entry with `"allow"` array, `"mode": "trigger"`
|
||||
- `groupPolicy:"allowlist"` + `groupAllowFrom` → per-group entry with `"allow"` array, `"mode": "trigger"`
|
||||
- `dmPolicy:"open"` → `"allow": "*"`
|
||||
- `dmPolicy:"disabled"` → per-chat entry with `"allow": []`, `"mode": "drop"` (or don't register that chat)
|
||||
|
||||
Create the directory and file:
|
||||
```bash
|
||||
mkdir -p ~/.config/nanoclaw
|
||||
```
|
||||
|
||||
Then write the JSON file. If no allowlists were configured, skip this.
|
||||
|
||||
### Container Timeout
|
||||
|
||||
Check `agents.defaults.timeoutSeconds` in the config. This is maximum total agent runtime (wall-clock). NanoClaw's equivalent is `CONTAINER_TIMEOUT` (env var, default 30 min), also configurable per-group via `containerConfig.timeout`. Note: NanoClaw also has a separate `IDLE_TIMEOUT` (max time without output) which resets on activity — OpenClaw has no equivalent.
|
||||
|
||||
If the OpenClaw value differs significantly from 30 minutes, note it for the user. They can set `CONTAINER_TIMEOUT=<ms>` in `.env` after setup.
|
||||
|
||||
## Phase 3: Identity and Memory
|
||||
|
||||
This phase is fully conversational — read files directly and discuss with the user. No script needed.
|
||||
|
||||
**Where files go depends on the Phase 1 (groups) decision:**
|
||||
- **Shared personality:** Core identity goes in `groups/global/CLAUDE.md` (seen by all groups). Group-specific customizations go in each group's own CLAUDE.md.
|
||||
- **Fully separate:** Everything goes in `groups/main/` (or each group's own folder).
|
||||
- **Just main group:** Everything goes in `groups/main/`.
|
||||
|
||||
### Find workspace files
|
||||
|
||||
The STATE_DIR from discovery tells you where OpenClaw lives. Look for workspace files at `<STATE_DIR>/workspace/`. If AGENT_COUNT > 1, also check `<STATE_DIR>/agents/*/workspace/` and ask which agent to migrate.
|
||||
|
||||
Use the Read tool to look at each file found.
|
||||
|
||||
### IDENTITY.md
|
||||
|
||||
Read `<STATE_DIR>/workspace/IDENTITY.md` if it exists. It uses a key:value format (name, emoji, creature, vibe, etc.).
|
||||
|
||||
The assistant name was already confirmed and written to `.env` in Phase 1. Here, focus on the rest of the identity — create an `identity.md` file with the full identity details (emoji, creature, vibe, personality traits, etc.). If shared personality was chosen in Phase 1, put it alongside `groups/global/CLAUDE.md`. Otherwise, put it in `groups/main/`.
|
||||
|
||||
### SOUL.md
|
||||
|
||||
Read `<STATE_DIR>/workspace/SOUL.md` if it exists. Then read `groups/main/CLAUDE.md`.
|
||||
|
||||
CLAUDE.md is always loaded into the agent's context — it's the agent's continuous instructions. Not everything from SOUL.md needs to be there. Discuss with the user what belongs where:
|
||||
|
||||
- **In CLAUDE.md (always loaded):** Core personality traits, communication style, key behavioral rules. Weave these into the existing CLAUDE.md structure — adjust the opening description under the `# <Name>` heading, modify the tone in the Communication section.
|
||||
- **In a separate soul file:** Detailed personality backstory, extended guidelines, creative writing style, philosophical grounding — things the agent can reference when relevant but don't need to consume context tokens on every turn.
|
||||
|
||||
**File placement depends on Phase 1 choice:**
|
||||
- Shared personality → edit `groups/global/CLAUDE.md` for the core traits, create `groups/global/soul.md` for the extended content. All groups will see both.
|
||||
- Separate / main only → edit `groups/main/CLAUDE.md`, create `groups/main/soul.md`.
|
||||
|
||||
Add a reference in the relevant CLAUDE.md: "Your personality and extended behavioral guidelines are in `soul.md`. Refer to it for identity questions or when crafting responses that need your full character."
|
||||
|
||||
Show proposed edits to the user before applying. This is a thoughtful merge, not a copy-paste.
|
||||
|
||||
### USER.md
|
||||
|
||||
Read `<STATE_DIR>/workspace/USER.md` if it exists.
|
||||
|
||||
Create `groups/main/user-context.md` with the user information. Add a reference in CLAUDE.md: "Information about your user is in `user-context.md`. Read it when you need context about who you're talking to."
|
||||
|
||||
Ask if they want any critical user facts (name, timezone, key preferences) directly in CLAUDE.md for always-on awareness.
|
||||
|
||||
### MEMORY.md
|
||||
|
||||
Read `<STATE_DIR>/workspace/MEMORY.md` if it exists.
|
||||
|
||||
Show the contents and discuss what's worth keeping. Some memory entries may be stale or OpenClaw-specific. Create `groups/main/memories.md` for relevant items. Add a reference in CLAUDE.md.
|
||||
|
||||
### Daily memory files (`workspace/memory/*.md`)
|
||||
|
||||
If DAILY_MEMORY_FILES > 0 in the discovery output, OpenClaw accumulated dated memory files (e.g. `2024-01-01.md`). These contain observations, facts, and context gathered over time.
|
||||
|
||||
AskUserQuestion: "You have N daily memory files from OpenClaw. How would you like to handle them?"
|
||||
|
||||
1. **Copy as-is (recommended for many files)** — "I'll create a `daily-memories/` folder in your group directory and copy them over. Your agent can reference them when needed."
|
||||
- Create the folder in the appropriate group directory (per Phase 1 decision)
|
||||
- Copy all `.md` files: `cp -r <workspace>/memory/*.md <group_dir>/daily-memories/`
|
||||
- Add a reference in CLAUDE.md: "Historical daily memory files from your previous system are in `daily-memories/`. Refer to them when you need context about past events or observations."
|
||||
|
||||
2. **Consolidate into memories** — "I'll read through them, extract the durable facts, and add them to your memories file. This reduces clutter but takes longer."
|
||||
- Read each file, extract entries worth keeping (skip transient observations, focus on durable facts about the user, preferences, recurring topics)
|
||||
- Consolidate into `memories.md`
|
||||
- Use sub-agents for large volumes (>10 files)
|
||||
|
||||
3. **Skip** — "Don't bring daily memories over."
|
||||
|
||||
### OpenClaw Skills
|
||||
|
||||
If SKILL_COUNT > 0 in discovery, OpenClaw had custom skills. The SKILL.md format is a shared standard — skills are directly portable.
|
||||
|
||||
The discovery reports skill names and source locations. For each skill, read just the YAML front matter (name + description at the top of SKILL.md) and present a list to the user: skill name, description, source location. Let the user select which ones to bring over.
|
||||
|
||||
For confirmed skills, copy the entire skill directory as-is:
|
||||
|
||||
```bash
|
||||
cp -r <skill_source_dir> container/skills/<skill_name>
|
||||
```
|
||||
|
||||
After all skills are copied, a container rebuild is needed — note this for post-migration: `./container/build.sh`.
|
||||
|
||||
### Config-registered plugins and skills
|
||||
|
||||
If CONFIG_PLUGIN_COUNT > 0 in discovery, OpenClaw had installed plugins/skills with API keys (e.g. `plugins.entries.brave`, `skills.entries.openai-whisper-api`). These are functional tools the agent had access to.
|
||||
|
||||
For each detected plugin, present the name to the user and discuss whether to set it up in NanoClaw. Read the OpenClaw config section to understand what it is, then:
|
||||
|
||||
1. **If NanoClaw has a matching skill** — check the available NanoClaw skills list for an equivalent (e.g. `/add-voice-transcription` for whisper). If found, save the API key to `.env` and invoke that skill.
|
||||
|
||||
2. **If the OpenClaw plugin was an MCP server** — read its config to find the exact package name and command. Install the same MCP server (e.g. `npx -y <exact-package-from-config>`). Don't search for or guess at MCP packages — only install what was explicitly configured.
|
||||
|
||||
3. **If the OpenClaw plugin was a CLI tool** — read the config to identify the exact tool. If it's an npm package, add it to the container's Dockerfile. Add a note to the group's CLAUDE.md that the tool is available and how to invoke it.
|
||||
|
||||
4. **If the plugin wraps an API** — discuss with the user what it did and offer to implement the equivalent: save the API key to `.env`, write a container skill with instructions for using the API, or wire it into the message flow if it's something automatic (e.g. voice transcription).
|
||||
|
||||
5. **If unclear** — discuss with the user what the plugin did and decide together. Don't install unknown packages or search for replacements — that's a supply chain risk.
|
||||
|
||||
For API keys, read the config value directly (don't display raw keys) and write to `.env`. The discovery script reports which plugins have keys but never extracts them.
|
||||
|
||||
### Other files (TOOLS.md, HEARTBEAT.md, BOOTSTRAP.md, AGENTS.md)
|
||||
|
||||
If these exist, briefly mention them and explain:
|
||||
- TOOLS.md: NanoClaw agents have their own tool discovery; this doesn't transfer
|
||||
- HEARTBEAT.md: NanoClaw uses scheduled tasks instead
|
||||
- BOOTSTRAP.md: NanoClaw uses CLAUDE.md and container skills instead
|
||||
- AGENTS.md: Already covered in the Phase 1 groups discussion
|
||||
|
||||
## Phase 4: Channel Credentials
|
||||
|
||||
For each channel found in the discovery results, handle it based on NanoClaw support:
|
||||
|
||||
### Supported channels (whatsapp, telegram, slack, discord)
|
||||
|
||||
Run the credential extraction script with `--write-env .env` so it writes credentials directly to NanoClaw's `.env` file. The script never emits raw credential values to stdout — only masked versions.
|
||||
|
||||
First, run without `--write-env` to preview:
|
||||
|
||||
```bash
|
||||
npx tsx ${CLAUDE_SKILL_DIR}/scripts/extract-channel-credentials.ts --state-dir <STATE_DIR> --channel <name>
|
||||
```
|
||||
|
||||
Parse the status block. Key fields: HAS_CREDENTIAL, CREDENTIAL_MASKED, NANOCLAW_ENV_VAR.
|
||||
|
||||
**If HAS_CREDENTIAL=false but the user expects a credential:** The extraction script may not recognize the config structure. Fall back to reading the channel section of `openclaw.json` directly with the Read tool and look for any field that contains a token or key value. Ask the user to confirm.
|
||||
|
||||
If HAS_CREDENTIAL=true: Show the masked credential (`CREDENTIAL_MASKED`). AskUserQuestion:
|
||||
1. **Use this credential** — run again with `--write-env .env` to save it
|
||||
2. **Enter a new one** — ask in plain text, write to `.env` manually
|
||||
3. **Skip this channel** — don't configure
|
||||
|
||||
If using the credential:
|
||||
|
||||
```bash
|
||||
npx tsx ${CLAUDE_SKILL_DIR}/scripts/extract-channel-credentials.ts --state-dir <STATE_DIR> --channel <name> --write-env .env
|
||||
```
|
||||
|
||||
The script writes the credential directly to `.env` using the correct NanoClaw variable name (e.g. `TELEGRAM_BOT_TOKEN`). Check the status block for `WRITTEN_TO` and `WRITTEN_COUNT` to confirm.
|
||||
|
||||
**Credential destination note:** Credentials are saved to `.env` for now. During `/setup`, the credential step will either keep them in `.env` (Apple Container) or migrate them to the OneCLI vault (Docker). The user doesn't need to worry about this now.
|
||||
|
||||
For Slack: there are two credentials (bot token + app token). The script handles both in one run — check `HAS_CREDENTIAL_2` and `NANOCLAW_ENV_VAR_2` in the status block.
|
||||
|
||||
**WhatsApp special case:** WhatsApp uses QR/pairing-code authentication, not a token. Do not copy auth state from OpenClaw — encryption sessions become stale after copying and messages fail to decrypt. Authentication will be handled during `/setup` via the `/add-whatsapp` skill (takes about 60 seconds with a pairing code). Just note that WhatsApp was configured and move on.
|
||||
|
||||
**Allowlist note:** If the channel had `allowFrom` or group policies, these were already handled in Phase 2 (sender allowlists). Mention that the allowlist file was created earlier.
|
||||
|
||||
### Unsupported channels (signal, matrix, irc, msteams, feishu, etc.)
|
||||
|
||||
Explain briefly: "NanoClaw doesn't have a `<channel>` integration yet, but channels are added over time via skills. Any groups from this channel were already registered in Phase 1 — they'll activate when the channel is added."
|
||||
|
||||
If there are credentials (tokens, keys) for the unsupported channel, offer to save them to `.env` with a descriptive variable name (e.g. `SIGNAL_ACCOUNT`, `MATRIX_ACCESS_TOKEN`) so they're available when the channel is eventually supported.
|
||||
|
||||
Don't invoke channel skills here — just prepare `.env` credentials. Channel code is installed during `/setup`.
|
||||
|
||||
## Phase 5: Scheduled Tasks
|
||||
|
||||
Read `<STATE_DIR>/cron/jobs.json` with the Read tool. If the file doesn't exist or has no jobs, skip this phase.
|
||||
|
||||
If jobs exist, read `${CLAUDE_SKILL_DIR}/MIGRATE_CRONS.md` for the full OpenClaw cron format, NanoClaw table schema, field mapping, and SQL insert template. Follow those instructions for each job.
|
||||
|
||||
## Phase 6: Webhooks, MCP, and Other Config
|
||||
|
||||
Read relevant sections from `<STATE_DIR>/openclaw.json` directly with the Read tool. This phase is fully conversational.
|
||||
|
||||
### MCP Servers
|
||||
|
||||
If MCP_SERVERS was non-empty in discovery, these can be ported. Claude Code supports MCP servers natively. Read the OpenClaw config's `mcp.servers` section to get each server's details (`command`, `args`, `env`, `url`).
|
||||
|
||||
MCP servers in NanoClaw are registered in the agent-runner source code. Before editing, grep for `mcpServers` in `container/agent-runner/src/` to find the current location — it's expected to be in `index.ts` in the `query()` options, but may have moved. For each OpenClaw MCP server the user wants to bring over:
|
||||
|
||||
1. Read its config: command, args, env, url
|
||||
2. **stdio servers** (have `command`): Add an entry to the `mcpServers` object in `container/agent-runner/src/index.ts`. The command runs inside the container, so it needs to be available there (Node.js/npx-based servers work; custom binaries would need to be added to the Dockerfile).
|
||||
3. **HTTP/SSE servers** (have `url`): These work if the URL is accessible from inside the container. Add them the same way.
|
||||
4. **Environment variables**: Any `env` values that reference secrets should be added to `.env` and passed through via `process.env.*` in the mcpServers entry.
|
||||
|
||||
After adding all MCP servers, a container rebuild is needed: `./container/build.sh`
|
||||
|
||||
Show the user each server and ask which to bring over. For servers that need custom binaries not available in the container, note them for manual setup.
|
||||
|
||||
### Webhooks and Endpoints
|
||||
|
||||
If the config has webhook sections (in `cron.webhook`, `cron.failureDestination`, or channel-specific webhooks):
|
||||
- Explain what they were used for
|
||||
- These don't map directly but NanoClaw can be customized to support them
|
||||
- Discuss the use case with the user and propose a solution if it's important to them
|
||||
- For simple webhook notifications: a task script with `curl` often suffices
|
||||
|
||||
### Other Config
|
||||
|
||||
Scan the config for notable sections and briefly mention anything that doesn't carry over:
|
||||
- **Exec approvals / command allowlist:** NanoClaw uses container isolation instead — the agent runs with `--dangerously-skip-permissions` inside a sandboxed container
|
||||
- **Human delay:** Not applicable in NanoClaw's container model
|
||||
- **Compaction:** Handled by Claude Code SDK automatically
|
||||
- **TTS:** Not built into NanoClaw
|
||||
- **Model configuration:** NanoClaw uses whatever Anthropic model the credential provides access to
|
||||
|
||||
Don't belabor these — just mention and move on.
|
||||
|
||||
## Phase 7: Summary
|
||||
|
||||
### Summary
|
||||
|
||||
Print a comprehensive summary:
|
||||
|
||||
**Migrated:**
|
||||
- Assistant name → `.env` ASSISTANT_NAME + CLAUDE.md templates updated
|
||||
- Groups → registered in database, folders created with CLAUDE.md templates
|
||||
- Timezone → `.env` TZ
|
||||
- Anthropic credential → `.env` (for setup to pick up)
|
||||
- Sender allowlists → `~/.config/nanoclaw/sender-allowlist.json`
|
||||
- Personality → CLAUDE.md (core) + `soul.md` (extended), placed per Phase 1 decision (global or per-group)
|
||||
- User context → `user-context.md`
|
||||
- Memories → `memories.md` + daily memory files (copied to `daily-memories/` or consolidated)
|
||||
- OpenClaw skills → copied to `container/skills/`
|
||||
- Channel credentials → `.env` (list which channels)
|
||||
- Scheduled tasks → inserted into database or noted for post-setup
|
||||
- MCP servers → registered in agent-runner
|
||||
|
||||
**Noted for later:**
|
||||
- Channel code installation (happens during `/setup`)
|
||||
- Task creation (if deferred due to no registered group yet)
|
||||
- Container rebuild needed (if skills or MCP servers were added): `./container/build.sh`
|
||||
|
||||
**Not applicable:**
|
||||
- Unsupported channels (list them — groups registered for future)
|
||||
- OpenClaw-specific features (exec approvals, human delay, TTS, model config, session reset policies, etc.)
|
||||
|
||||
**Discussed and deferred:**
|
||||
- List any customizations agreed on but not yet implemented
|
||||
|
||||
Remind: "Run `/setup` next to complete your NanoClaw installation. Channel credentials are already prepared in `.env`. When setup asks which channels to enable, select the ones we configured."
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
**Config parse error:** If `openclaw.json` fails to parse, it may use JSON5 features the parser doesn't handle. Ask the user to check the file for unusual syntax. As a fallback, the agent can read the file directly and work with it manually.
|
||||
|
||||
**Credential not found:** If a channel credential resolves to empty, it may use `source:"exec"` or `source:"file"` SecretRef. These can't be auto-extracted. Ask the user to provide the value directly.
|
||||
|
||||
**Multi-agent complexity:** If the user had many agents with different configs, focus on the primary/default agent first. Additional agents can be set up as separate NanoClaw groups later.
|
||||
@@ -0,0 +1,734 @@
|
||||
/**
|
||||
* Discover an existing OpenClaw installation and emit a structured summary.
|
||||
*
|
||||
* Usage: npx tsx .claude/skills/migrate-from-openclaw/scripts/discover-openclaw.ts [--state-dir <path>]
|
||||
*
|
||||
* Checks (in order): --state-dir arg, $OPENCLAW_STATE_DIR, ~/.openclaw, ~/.clawdbot
|
||||
* Parses openclaw.json (JSON5-tolerant), scans workspace for identity/memory files,
|
||||
* checks cron jobs, MCP servers, and channel credentials.
|
||||
*
|
||||
* Emits a status block on stdout:
|
||||
* === NANOCLAW MIGRATE: DISCOVERY ===
|
||||
* ...
|
||||
* === END ===
|
||||
*/
|
||||
|
||||
import fs from 'fs';
|
||||
import os from 'os';
|
||||
import path from 'path';
|
||||
|
||||
// ---------------------------------------------------------------------------
|
||||
// JSON5-tolerant parser (no dependency)
|
||||
// ---------------------------------------------------------------------------
|
||||
|
||||
function parseJson5(text: string): unknown {
|
||||
// Strip single-line comments (// ...) that aren't inside strings
|
||||
let cleaned = text.replace(
|
||||
/("(?:[^"\\]|\\.)*")|\/\/[^\n]*/g,
|
||||
(match, str) => (str ? str : ''),
|
||||
);
|
||||
// Strip block comments (/* ... */)
|
||||
cleaned = cleaned.replace(
|
||||
/("(?:[^"\\]|\\.)*")|\/\*[\s\S]*?\*\//g,
|
||||
(match, str) => (str ? str : ''),
|
||||
);
|
||||
// Strip trailing commas before } or ]
|
||||
cleaned = cleaned.replace(/,\s*([}\]])/g, '$1');
|
||||
return JSON.parse(cleaned);
|
||||
}
|
||||
|
||||
// ---------------------------------------------------------------------------
|
||||
// Status block emitter (mirrors setup/status.ts convention)
|
||||
// ---------------------------------------------------------------------------
|
||||
|
||||
function emitStatus(fields: Record<string, string | number | boolean>): void {
|
||||
const lines = ['=== NANOCLAW MIGRATE: DISCOVERY ==='];
|
||||
for (const [key, value] of Object.entries(fields)) {
|
||||
lines.push(`${key}: ${value}`);
|
||||
}
|
||||
lines.push('=== END ===');
|
||||
console.log(lines.join('\n'));
|
||||
}
|
||||
|
||||
// ---------------------------------------------------------------------------
|
||||
// CLI arg parsing
|
||||
// ---------------------------------------------------------------------------
|
||||
|
||||
function parseArgs(): { stateDir?: string } {
|
||||
const args = process.argv.slice(2);
|
||||
for (let i = 0; i < args.length; i++) {
|
||||
if (args[i] === '--state-dir' && args[i + 1]) {
|
||||
return { stateDir: args[i + 1] };
|
||||
}
|
||||
}
|
||||
return {};
|
||||
}
|
||||
|
||||
// ---------------------------------------------------------------------------
|
||||
// Path resolution
|
||||
// ---------------------------------------------------------------------------
|
||||
|
||||
function resolveStateDir(explicit?: string): string | null {
|
||||
const home = os.homedir();
|
||||
const candidates: string[] = [];
|
||||
|
||||
if (explicit) {
|
||||
// Expand ~ prefix
|
||||
const expanded = explicit.startsWith('~')
|
||||
? path.join(home, explicit.slice(1))
|
||||
: explicit;
|
||||
candidates.push(expanded);
|
||||
}
|
||||
|
||||
if (process.env.OPENCLAW_STATE_DIR) {
|
||||
candidates.push(process.env.OPENCLAW_STATE_DIR);
|
||||
}
|
||||
|
||||
candidates.push(path.join(home, '.openclaw'));
|
||||
candidates.push(path.join(home, '.clawdbot'));
|
||||
|
||||
for (const dir of candidates) {
|
||||
if (fs.existsSync(dir) && fs.statSync(dir).isDirectory()) {
|
||||
return dir;
|
||||
}
|
||||
}
|
||||
return null;
|
||||
}
|
||||
|
||||
// ---------------------------------------------------------------------------
|
||||
// Config loading
|
||||
// ---------------------------------------------------------------------------
|
||||
|
||||
function loadConfig(
|
||||
stateDir: string,
|
||||
): Record<string, unknown> | null {
|
||||
for (const name of ['openclaw.json', 'clawdbot.json']) {
|
||||
const configPath = path.join(stateDir, name);
|
||||
if (fs.existsSync(configPath)) {
|
||||
try {
|
||||
const raw = fs.readFileSync(configPath, 'utf-8');
|
||||
return parseJson5(raw) as Record<string, unknown>;
|
||||
} catch {
|
||||
// Try next name
|
||||
}
|
||||
}
|
||||
}
|
||||
return null;
|
||||
}
|
||||
|
||||
// ---------------------------------------------------------------------------
|
||||
// Channel detection
|
||||
// ---------------------------------------------------------------------------
|
||||
|
||||
interface ChannelInfo {
|
||||
name: string;
|
||||
hasCreds: boolean;
|
||||
}
|
||||
|
||||
const SUPPORTED_CHANNELS = new Set([
|
||||
'whatsapp',
|
||||
'telegram',
|
||||
'slack',
|
||||
'discord',
|
||||
]);
|
||||
|
||||
// Fields that indicate a credential is present for each channel
|
||||
const CREDENTIAL_FIELDS: Record<string, string[]> = {
|
||||
telegram: ['botToken'],
|
||||
discord: ['token'],
|
||||
slack: ['botToken', 'appToken'],
|
||||
whatsapp: [], // Auth-state based, no token
|
||||
signal: ['account'],
|
||||
imessage: [],
|
||||
matrix: ['homeserverUrl', 'accessToken'],
|
||||
irc: ['server'],
|
||||
msteams: ['appId'],
|
||||
feishu: ['appId'],
|
||||
googlechat: [],
|
||||
mattermost: ['token', 'url'],
|
||||
zalo: [],
|
||||
bluebubbles: ['url'],
|
||||
};
|
||||
|
||||
const ALL_KNOWN_CHANNELS = new Set([
|
||||
'whatsapp', 'telegram', 'slack', 'discord', 'signal',
|
||||
'imessage', 'matrix', 'irc', 'msteams', 'feishu',
|
||||
'googlechat', 'mattermost', 'zalo', 'bluebubbles',
|
||||
]);
|
||||
|
||||
function detectChannels(
|
||||
config: Record<string, unknown>,
|
||||
): ChannelInfo[] {
|
||||
// Check both config.channels.* (newer) and top-level config.* (older/legacy)
|
||||
const channelsSections: Record<string, unknown> = {};
|
||||
|
||||
// Source 1: channels.* (standard location)
|
||||
const nested = config.channels as Record<string, unknown> | undefined;
|
||||
if (nested) {
|
||||
for (const [k, v] of Object.entries(nested)) {
|
||||
if (v && typeof v === 'object') channelsSections[k] = v;
|
||||
}
|
||||
}
|
||||
|
||||
// Source 2: top-level keys matching known channel names (legacy format)
|
||||
for (const key of Object.keys(config)) {
|
||||
if (ALL_KNOWN_CHANNELS.has(key) && !channelsSections[key]) {
|
||||
const v = config[key];
|
||||
if (v && typeof v === 'object') channelsSections[key] = v;
|
||||
}
|
||||
}
|
||||
|
||||
const results: ChannelInfo[] = [];
|
||||
|
||||
for (const [name, section] of Object.entries(channelsSections)) {
|
||||
if (!section || typeof section !== 'object') continue;
|
||||
const ch = section as Record<string, unknown>;
|
||||
|
||||
// Check if any credential field is present and non-empty
|
||||
const credFields = CREDENTIAL_FIELDS[name] ?? [];
|
||||
let hasCreds = false;
|
||||
|
||||
for (const field of credFields) {
|
||||
const val = ch[field];
|
||||
if (val && (typeof val === 'string' || typeof val === 'object')) {
|
||||
hasCreds = true;
|
||||
break;
|
||||
}
|
||||
}
|
||||
|
||||
// Also check accounts for multi-account setups
|
||||
if (!hasCreds && ch.accounts && typeof ch.accounts === 'object') {
|
||||
for (const acct of Object.values(
|
||||
ch.accounts as Record<string, unknown>,
|
||||
)) {
|
||||
if (!acct || typeof acct !== 'object') continue;
|
||||
const a = acct as Record<string, unknown>;
|
||||
for (const field of credFields) {
|
||||
if (
|
||||
a[field] &&
|
||||
(typeof a[field] === 'string' || typeof a[field] === 'object')
|
||||
) {
|
||||
hasCreds = true;
|
||||
break;
|
||||
}
|
||||
}
|
||||
if (hasCreds) break;
|
||||
}
|
||||
}
|
||||
|
||||
// WhatsApp: check for auth state directory instead of token
|
||||
if (name === 'whatsapp' && !hasCreds) {
|
||||
// Will be checked separately via agents directory
|
||||
hasCreds = false;
|
||||
}
|
||||
|
||||
results.push({ name, hasCreds });
|
||||
}
|
||||
|
||||
return results;
|
||||
}
|
||||
|
||||
// ---------------------------------------------------------------------------
|
||||
// Workspace scanning
|
||||
// ---------------------------------------------------------------------------
|
||||
|
||||
const WORKSPACE_FILES = [
|
||||
'SOUL.md',
|
||||
'USER.md',
|
||||
'MEMORY.md',
|
||||
'IDENTITY.md',
|
||||
'TOOLS.md',
|
||||
'HEARTBEAT.md',
|
||||
'BOOTSTRAP.md',
|
||||
'AGENTS.md',
|
||||
];
|
||||
|
||||
function findWorkspace(stateDir: string, config: Record<string, unknown> | null): {
|
||||
dir: string | null;
|
||||
files: string[];
|
||||
} {
|
||||
// Check config-specified workspace path first (agent.workspace or agents.defaults.workspace)
|
||||
const configPaths: string[] = [];
|
||||
if (config) {
|
||||
const agentWs = (config.agent as Record<string, unknown> | undefined)?.workspace as string | undefined;
|
||||
if (agentWs) configPaths.push(agentWs.startsWith('~') ? path.join(os.homedir(), agentWs.slice(1)) : agentWs);
|
||||
const defaultsWs = ((config.agents as Record<string, unknown> | undefined)?.defaults as Record<string, unknown> | undefined)?.workspace as string | undefined;
|
||||
if (defaultsWs) configPaths.push(defaultsWs.startsWith('~') ? path.join(os.homedir(), defaultsWs.slice(1)) : defaultsWs);
|
||||
}
|
||||
|
||||
// Check config-specified paths, then default locations
|
||||
const candidates = [
|
||||
...configPaths,
|
||||
...['workspace', 'workspace.default'].map((n) => path.join(stateDir, n)),
|
||||
];
|
||||
|
||||
for (const ws of candidates) {
|
||||
if (fs.existsSync(ws) && fs.statSync(ws).isDirectory()) {
|
||||
const found = WORKSPACE_FILES.filter((f) =>
|
||||
fs.existsSync(path.join(ws, f)),
|
||||
);
|
||||
if (found.length > 0) {
|
||||
return { dir: ws, files: found };
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
// Check agent-specific workspaces
|
||||
const agentsDir = path.join(stateDir, 'agents');
|
||||
if (fs.existsSync(agentsDir)) {
|
||||
for (const agentId of fs.readdirSync(agentsDir)) {
|
||||
for (const wsName of ['workspace', 'workspace.default']) {
|
||||
const ws = path.join(agentsDir, agentId, wsName);
|
||||
if (fs.existsSync(ws) && fs.statSync(ws).isDirectory()) {
|
||||
const found = WORKSPACE_FILES.filter((f) =>
|
||||
fs.existsSync(path.join(ws, f)),
|
||||
);
|
||||
if (found.length > 0) {
|
||||
return { dir: ws, files: found };
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
return { dir: null, files: [] };
|
||||
}
|
||||
|
||||
// ---------------------------------------------------------------------------
|
||||
// Daily memory file detection
|
||||
// ---------------------------------------------------------------------------
|
||||
|
||||
function countDailyMemoryFiles(workspaceDir: string | null): number {
|
||||
if (!workspaceDir) return 0;
|
||||
const memoryDir = path.join(workspaceDir, 'memory');
|
||||
if (!fs.existsSync(memoryDir) || !fs.statSync(memoryDir).isDirectory()) {
|
||||
return 0;
|
||||
}
|
||||
try {
|
||||
return fs
|
||||
.readdirSync(memoryDir)
|
||||
.filter((f) => f.endsWith('.md'))
|
||||
.length;
|
||||
} catch {
|
||||
return 0;
|
||||
}
|
||||
}
|
||||
|
||||
// ---------------------------------------------------------------------------
|
||||
// Skills detection
|
||||
// ---------------------------------------------------------------------------
|
||||
|
||||
interface SkillInfo {
|
||||
name: string;
|
||||
source: string; // 'workspace' | 'shared' | 'personal' | 'project'
|
||||
path: string;
|
||||
}
|
||||
|
||||
function detectSkills(
|
||||
stateDir: string,
|
||||
workspaceDir: string | null,
|
||||
): SkillInfo[] {
|
||||
const skills: SkillInfo[] = [];
|
||||
const seen = new Set<string>();
|
||||
|
||||
const scanDir = (dir: string, source: string) => {
|
||||
if (!fs.existsSync(dir) || !fs.statSync(dir).isDirectory()) return;
|
||||
try {
|
||||
for (const entry of fs.readdirSync(dir)) {
|
||||
const skillDir = path.join(dir, entry);
|
||||
if (!fs.statSync(skillDir).isDirectory()) continue;
|
||||
// A directory is a skill if it contains SKILL.md
|
||||
if (fs.existsSync(path.join(skillDir, 'SKILL.md'))) {
|
||||
if (seen.has(entry)) continue;
|
||||
seen.add(entry);
|
||||
skills.push({ name: entry, source, path: skillDir });
|
||||
}
|
||||
}
|
||||
} catch {
|
||||
// ignore read errors
|
||||
}
|
||||
};
|
||||
|
||||
// 1. Workspace skills
|
||||
if (workspaceDir) {
|
||||
scanDir(path.join(workspaceDir, 'skills'), 'workspace');
|
||||
// 4. Project-level shared skills
|
||||
scanDir(path.join(workspaceDir, '.agents', 'skills'), 'project');
|
||||
}
|
||||
|
||||
// 2. Managed/shared skills
|
||||
scanDir(path.join(stateDir, 'skills'), 'shared');
|
||||
|
||||
// 3. Personal cross-project skills
|
||||
const personalSkills = path.join(os.homedir(), '.agents', 'skills');
|
||||
scanDir(personalSkills, 'personal');
|
||||
|
||||
return skills;
|
||||
}
|
||||
|
||||
// ---------------------------------------------------------------------------
|
||||
// Identity extraction
|
||||
// ---------------------------------------------------------------------------
|
||||
|
||||
function extractIdentityName(stateDir: string, workspaceDir: string | null): string {
|
||||
if (!workspaceDir) return '';
|
||||
|
||||
const identityPath = path.join(workspaceDir, 'IDENTITY.md');
|
||||
if (!fs.existsSync(identityPath)) return '';
|
||||
|
||||
try {
|
||||
const content = fs.readFileSync(identityPath, 'utf-8');
|
||||
// IDENTITY.md uses key:value format, e.g. "name: Claw"
|
||||
const match = content.match(/^name:\s*(.+)/im);
|
||||
return match ? match[1].trim() : '';
|
||||
} catch {
|
||||
return '';
|
||||
}
|
||||
}
|
||||
|
||||
// ---------------------------------------------------------------------------
|
||||
// Agent detection
|
||||
// ---------------------------------------------------------------------------
|
||||
|
||||
function detectAgents(stateDir: string): string[] {
|
||||
const agentsDir = path.join(stateDir, 'agents');
|
||||
if (!fs.existsSync(agentsDir)) return [];
|
||||
|
||||
try {
|
||||
return fs
|
||||
.readdirSync(agentsDir)
|
||||
.filter((f) => {
|
||||
const p = path.join(agentsDir, f);
|
||||
return fs.statSync(p).isDirectory() && !f.startsWith('.');
|
||||
});
|
||||
} catch {
|
||||
return [];
|
||||
}
|
||||
}
|
||||
|
||||
// ---------------------------------------------------------------------------
|
||||
// Group detection — from session store and channel config
|
||||
// ---------------------------------------------------------------------------
|
||||
|
||||
interface GroupInfo {
|
||||
channel: string;
|
||||
id: string; // Platform-specific ID (WhatsApp JID, Telegram chat ID, etc.)
|
||||
name: string;
|
||||
source: 'session' | 'config';
|
||||
}
|
||||
|
||||
/**
|
||||
* Map OpenClaw session key channel:kind:id to NanoClaw JID format.
|
||||
* OpenClaw keys: "whatsapp:group:120...@g.us", "telegram:group:-10012345"
|
||||
* NanoClaw JIDs: "120...@g.us", "tg:-10012345", "dc:12345", "slack:C12345"
|
||||
*/
|
||||
function toNanoClawJid(channel: string, id: string): string {
|
||||
switch (channel) {
|
||||
case 'whatsapp':
|
||||
return id; // Already in JID format (120...@g.us)
|
||||
case 'telegram':
|
||||
return `tg:${id}`;
|
||||
case 'discord':
|
||||
return `dc:${id}`;
|
||||
case 'slack':
|
||||
return `slack:${id}`;
|
||||
default:
|
||||
return `${channel}:${id}`;
|
||||
}
|
||||
}
|
||||
|
||||
function detectGroups(
|
||||
stateDir: string,
|
||||
config: Record<string, unknown> | null,
|
||||
agents: string[],
|
||||
): GroupInfo[] {
|
||||
const groups: GroupInfo[] = [];
|
||||
const seen = new Set<string>();
|
||||
|
||||
// Source 1: Session store — scan for group session keys
|
||||
for (const agentId of agents) {
|
||||
const sessionsPath = path.join(
|
||||
stateDir,
|
||||
'agents',
|
||||
agentId,
|
||||
'sessions',
|
||||
'sessions.json',
|
||||
);
|
||||
if (!fs.existsSync(sessionsPath)) continue;
|
||||
|
||||
try {
|
||||
const raw = fs.readFileSync(sessionsPath, 'utf-8');
|
||||
const data = JSON.parse(raw) as Record<string, unknown>;
|
||||
|
||||
// Sessions can be stored as an object with session keys, or as
|
||||
// { sessions: { key: entry } } or { entries: [...] }
|
||||
const entries =
|
||||
(data.sessions as Record<string, unknown>) ??
|
||||
(data.entries as Record<string, unknown>) ??
|
||||
data;
|
||||
|
||||
for (const [key, value] of Object.entries(entries)) {
|
||||
// Match session keys like "whatsapp:group:120...@g.us"
|
||||
// or prefixed "agent:main:whatsapp:group:120...@g.us"
|
||||
// Also match DM sessions: "whatsapp:dm:number@s.whatsapp.net"
|
||||
const match = key.match(/(\w+):(group|dm|channel):(.+)$/i);
|
||||
if (!match) continue;
|
||||
|
||||
const [, channel, kind, id] = match;
|
||||
// Skip DM sessions for group detection — they're individual chats
|
||||
if (kind === 'dm') continue;
|
||||
const dedupKey = `${channel}:${id}`;
|
||||
if (seen.has(dedupKey)) continue;
|
||||
seen.add(dedupKey);
|
||||
|
||||
// Try to extract display name from session entry
|
||||
let name = '';
|
||||
if (value && typeof value === 'object') {
|
||||
const entry = value as Record<string, unknown>;
|
||||
name =
|
||||
(entry.displayName as string) ??
|
||||
(entry.label as string) ??
|
||||
(entry.subject as string) ??
|
||||
'';
|
||||
}
|
||||
|
||||
groups.push({
|
||||
channel,
|
||||
id,
|
||||
name: name || id,
|
||||
source: 'session',
|
||||
});
|
||||
}
|
||||
} catch {
|
||||
// Ignore parse errors
|
||||
}
|
||||
}
|
||||
|
||||
// Source 2: Channel config — groups explicitly configured
|
||||
if (config) {
|
||||
const channels =
|
||||
(config.channels as Record<string, unknown> | undefined) ?? {};
|
||||
for (const [channelName, channelSection] of Object.entries(channels)) {
|
||||
if (!channelSection || typeof channelSection !== 'object') continue;
|
||||
const ch = channelSection as Record<string, unknown>;
|
||||
|
||||
// WhatsApp/Telegram: channels.<channel>.groups.<groupId>
|
||||
const configGroups = ch.groups as Record<string, unknown> | undefined;
|
||||
if (configGroups) {
|
||||
for (const groupId of Object.keys(configGroups)) {
|
||||
const dedupKey = `${channelName}:${groupId}`;
|
||||
if (seen.has(dedupKey)) continue;
|
||||
seen.add(dedupKey);
|
||||
groups.push({
|
||||
channel: channelName,
|
||||
id: groupId,
|
||||
name: groupId,
|
||||
source: 'config',
|
||||
});
|
||||
}
|
||||
}
|
||||
|
||||
// Discord: channels.discord.guilds.<guildId>
|
||||
if (channelName === 'discord') {
|
||||
const guilds = ch.guilds as Record<string, unknown> | undefined;
|
||||
if (guilds) {
|
||||
for (const guildId of Object.keys(guilds)) {
|
||||
const dedupKey = `discord:${guildId}`;
|
||||
if (seen.has(dedupKey)) continue;
|
||||
seen.add(dedupKey);
|
||||
groups.push({
|
||||
channel: 'discord',
|
||||
id: guildId,
|
||||
name: guildId,
|
||||
source: 'config',
|
||||
});
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
return groups;
|
||||
}
|
||||
|
||||
// ---------------------------------------------------------------------------
|
||||
// Cron job counting
|
||||
// ---------------------------------------------------------------------------
|
||||
|
||||
function countCronJobs(stateDir: string): {
|
||||
count: number;
|
||||
summaries: string[];
|
||||
} {
|
||||
const jobsPath = path.join(stateDir, 'cron', 'jobs.json');
|
||||
if (!fs.existsSync(jobsPath)) return { count: 0, summaries: [] };
|
||||
|
||||
try {
|
||||
const raw = fs.readFileSync(jobsPath, 'utf-8');
|
||||
const data = JSON.parse(raw) as {
|
||||
jobs?: Array<{ name?: string; enabled?: boolean }>;
|
||||
};
|
||||
const jobs = data.jobs ?? [];
|
||||
const summaries = jobs
|
||||
.filter((j) => j.enabled !== false)
|
||||
.map((j) => j.name || 'unnamed')
|
||||
.slice(0, 10);
|
||||
return { count: jobs.length, summaries };
|
||||
} catch {
|
||||
return { count: 0, summaries: [] };
|
||||
}
|
||||
}
|
||||
|
||||
// ---------------------------------------------------------------------------
|
||||
// Config-registered plugins and skills (with API keys)
|
||||
// ---------------------------------------------------------------------------
|
||||
|
||||
interface ConfigPlugin {
|
||||
name: string;
|
||||
source: 'skills.entries' | 'plugins.entries';
|
||||
hasApiKey: boolean;
|
||||
}
|
||||
|
||||
function detectConfigPlugins(
|
||||
config: Record<string, unknown>,
|
||||
): ConfigPlugin[] {
|
||||
const results: ConfigPlugin[] = [];
|
||||
|
||||
// Check skills.entries (e.g. openai-whisper-api with apiKey)
|
||||
const skills = config.skills as Record<string, unknown> | undefined;
|
||||
const skillEntries = skills?.entries as Record<string, unknown> | undefined;
|
||||
if (skillEntries) {
|
||||
for (const [name, entry] of Object.entries(skillEntries)) {
|
||||
if (!entry || typeof entry !== 'object') continue;
|
||||
const e = entry as Record<string, unknown>;
|
||||
const hasKey = !!(e.apiKey || e.token || e.key);
|
||||
results.push({ name, source: 'skills.entries', hasApiKey: hasKey });
|
||||
}
|
||||
}
|
||||
|
||||
// Check plugins.entries (e.g. brave with config.webSearch.apiKey)
|
||||
const plugins = config.plugins as Record<string, unknown> | undefined;
|
||||
const pluginEntries = plugins?.entries as Record<string, unknown> | undefined;
|
||||
if (pluginEntries) {
|
||||
for (const [name, entry] of Object.entries(pluginEntries)) {
|
||||
if (!entry || typeof entry !== 'object') continue;
|
||||
// Deep-search for apiKey in nested config
|
||||
const hasKey = JSON.stringify(entry).includes('apiKey');
|
||||
results.push({ name, source: 'plugins.entries', hasApiKey: hasKey });
|
||||
}
|
||||
}
|
||||
|
||||
return results;
|
||||
}
|
||||
|
||||
// ---------------------------------------------------------------------------
|
||||
// MCP server detection
|
||||
// ---------------------------------------------------------------------------
|
||||
|
||||
function detectMcpServers(
|
||||
config: Record<string, unknown>,
|
||||
): string[] {
|
||||
const mcp = config.mcp as Record<string, unknown> | undefined;
|
||||
if (!mcp) return [];
|
||||
const servers = mcp.servers as Record<string, unknown> | undefined;
|
||||
if (!servers) return [];
|
||||
return Object.keys(servers);
|
||||
}
|
||||
|
||||
// ---------------------------------------------------------------------------
|
||||
// Main
|
||||
// ---------------------------------------------------------------------------
|
||||
|
||||
function main(): void {
|
||||
const { stateDir: explicitDir } = parseArgs();
|
||||
const stateDir = resolveStateDir(explicitDir);
|
||||
|
||||
if (!stateDir) {
|
||||
emitStatus({ STATUS: 'not_found' });
|
||||
return;
|
||||
}
|
||||
|
||||
const config = loadConfig(stateDir);
|
||||
const channels = config ? detectChannels(config) : [];
|
||||
const { dir: workspaceDir, files: workspaceFiles } =
|
||||
findWorkspace(stateDir, config);
|
||||
const identityName = extractIdentityName(stateDir, workspaceDir);
|
||||
const agents = detectAgents(stateDir);
|
||||
const groups = detectGroups(stateDir, config, agents);
|
||||
const { count: cronCount, summaries: cronSummaries } =
|
||||
countCronJobs(stateDir);
|
||||
const mcpServers = config ? detectMcpServers(config) : [];
|
||||
const dailyMemoryFiles = countDailyMemoryFiles(workspaceDir);
|
||||
const skills = detectSkills(stateDir, workspaceDir);
|
||||
const configPlugins = config ? detectConfigPlugins(config) : [];
|
||||
|
||||
// Format channels as "name(has_creds)" or "name(no_creds)"
|
||||
const channelList = channels
|
||||
.map((c) => `${c.name}(${c.hasCreds ? 'has_creds' : 'no_creds'})`)
|
||||
.join(',');
|
||||
|
||||
// Separate supported vs unsupported
|
||||
const unsupported = channels
|
||||
.filter((c) => !SUPPORTED_CHANNELS.has(c.name))
|
||||
.map((c) => c.name)
|
||||
.join(',');
|
||||
|
||||
// Format groups as "channel:id(name)" — also include NanoClaw JID mapping
|
||||
const groupList = groups
|
||||
.map(
|
||||
(g) =>
|
||||
`${g.channel}:${g.id}(${g.name})=>${toNanoClawJid(g.channel, g.id)}`,
|
||||
)
|
||||
.join('|');
|
||||
|
||||
// Format skills as "name(source)" list
|
||||
const skillList = skills
|
||||
.map((s) => `${s.name}(${s.source})`)
|
||||
.join(',');
|
||||
|
||||
// Dump raw top-level config keys so Claude can see what exists
|
||||
// beyond what this script specifically detects
|
||||
const configTopKeys = config ? Object.keys(config).sort().join(',') : 'none';
|
||||
const configChannelKeys = config?.channels
|
||||
? Object.keys(config.channels as Record<string, unknown>).sort().join(',')
|
||||
: 'none';
|
||||
|
||||
// List files/dirs at the state dir root for manual inspection
|
||||
let stateDirContents = 'unknown';
|
||||
try {
|
||||
stateDirContents = fs
|
||||
.readdirSync(stateDir)
|
||||
.filter((f) => !f.startsWith('.'))
|
||||
.sort()
|
||||
.join(',');
|
||||
} catch {
|
||||
// ignore
|
||||
}
|
||||
|
||||
emitStatus({
|
||||
STATUS: 'found',
|
||||
STATE_DIR: stateDir,
|
||||
CONFIG_FOUND: config !== null,
|
||||
CONFIG_TOP_KEYS: configTopKeys,
|
||||
CONFIG_CHANNEL_KEYS: configChannelKeys,
|
||||
STATE_DIR_CONTENTS: stateDirContents,
|
||||
CHANNELS: channelList || 'none',
|
||||
UNSUPPORTED_CHANNELS: unsupported || 'none',
|
||||
WORKSPACE_DIR: workspaceDir || 'not_found',
|
||||
WORKSPACE_FILES: workspaceFiles.join(',') || 'none',
|
||||
IDENTITY_NAME: identityName || 'unknown',
|
||||
AGENT_COUNT: agents.length,
|
||||
AGENT_IDS: agents.join(',') || 'none',
|
||||
GROUPS: groupList || 'none',
|
||||
GROUP_COUNT: groups.length,
|
||||
DAILY_MEMORY_FILES: dailyMemoryFiles,
|
||||
SKILL_COUNT: skills.length,
|
||||
SKILLS: skillList || 'none',
|
||||
CONFIG_PLUGINS: configPlugins.map((p) => `${p.name}(${p.source}${p.hasApiKey ? ',has_key' : ''})`).join(',') || 'none',
|
||||
CONFIG_PLUGIN_COUNT: configPlugins.length,
|
||||
CRON_JOBS: cronCount,
|
||||
CRON_SUMMARIES: cronSummaries.join('|') || 'none',
|
||||
MCP_SERVERS: mcpServers.join(',') || 'none',
|
||||
});
|
||||
}
|
||||
|
||||
main();
|
||||
@@ -0,0 +1,476 @@
|
||||
/**
|
||||
* Extract a channel credential from an OpenClaw configuration and write it
|
||||
* directly to the NanoClaw .env file.
|
||||
*
|
||||
* Usage: npx tsx .claude/skills/migrate-from-openclaw/scripts/extract-channel-credentials.ts \
|
||||
* --channel telegram --state-dir ~/.openclaw --write-env .env
|
||||
*
|
||||
* Handles OpenClaw SecretRef formats:
|
||||
* - Plain string: "bot-token-value"
|
||||
* - Env template: "${TELEGRAM_BOT_TOKEN}"
|
||||
* - SecretRef object: { source: "env", provider: "default", id: "TELEGRAM_BOT_TOKEN" }
|
||||
*
|
||||
* Also reads <state-dir>/.env for env-based secrets.
|
||||
*
|
||||
* Credential values are NEVER emitted to stdout — only masked versions.
|
||||
* When --write-env is provided, the script writes credentials directly to
|
||||
* the target .env file so the agent never sees raw secrets.
|
||||
*
|
||||
* Emits a status block on stdout:
|
||||
* === NANOCLAW MIGRATE: CREDENTIAL ===
|
||||
* ...
|
||||
* === END ===
|
||||
*/
|
||||
|
||||
import fs from 'fs';
|
||||
import os from 'os';
|
||||
import path from 'path';
|
||||
|
||||
// ---------------------------------------------------------------------------
|
||||
// JSON5-tolerant parser (same as discover script)
|
||||
// ---------------------------------------------------------------------------
|
||||
|
||||
function parseJson5(text: string): unknown {
|
||||
let cleaned = text.replace(
|
||||
/("(?:[^"\\]|\\.)*")|\/\/[^\n]*/g,
|
||||
(match, str) => (str ? str : ''),
|
||||
);
|
||||
cleaned = cleaned.replace(
|
||||
/("(?:[^"\\]|\\.)*")|\/\*[\s\S]*?\*\//g,
|
||||
(match, str) => (str ? str : ''),
|
||||
);
|
||||
cleaned = cleaned.replace(/,\s*([}\]])/g, '$1');
|
||||
return JSON.parse(cleaned);
|
||||
}
|
||||
|
||||
// ---------------------------------------------------------------------------
|
||||
// Inline dotenv parser (reads key=value, skips comments)
|
||||
// ---------------------------------------------------------------------------
|
||||
|
||||
function parseDotenv(filePath: string): Record<string, string> {
|
||||
const env: Record<string, string> = {};
|
||||
if (!fs.existsSync(filePath)) return env;
|
||||
|
||||
const lines = fs.readFileSync(filePath, 'utf-8').split('\n');
|
||||
for (const line of lines) {
|
||||
const trimmed = line.trim();
|
||||
if (!trimmed || trimmed.startsWith('#')) continue;
|
||||
const eqIdx = trimmed.indexOf('=');
|
||||
if (eqIdx === -1) continue;
|
||||
const key = trimmed.slice(0, eqIdx).trim();
|
||||
let value = trimmed.slice(eqIdx + 1).trim();
|
||||
// Strip surrounding quotes
|
||||
if (
|
||||
(value.startsWith('"') && value.endsWith('"')) ||
|
||||
(value.startsWith("'") && value.endsWith("'"))
|
||||
) {
|
||||
value = value.slice(1, -1);
|
||||
}
|
||||
env[key] = value;
|
||||
}
|
||||
return env;
|
||||
}
|
||||
|
||||
// ---------------------------------------------------------------------------
|
||||
// Status block emitter
|
||||
// ---------------------------------------------------------------------------
|
||||
|
||||
function emitStatus(fields: Record<string, string | number | boolean>): void {
|
||||
const lines = ['=== NANOCLAW MIGRATE: CREDENTIAL ==='];
|
||||
for (const [key, value] of Object.entries(fields)) {
|
||||
lines.push(`${key}: ${value}`);
|
||||
}
|
||||
lines.push('=== END ===');
|
||||
console.log(lines.join('\n'));
|
||||
}
|
||||
|
||||
// ---------------------------------------------------------------------------
|
||||
// Credential masking
|
||||
// ---------------------------------------------------------------------------
|
||||
|
||||
function maskCredential(value: string): string {
|
||||
if (value.length < 10) return '****';
|
||||
return `${value.slice(0, 4)}...${value.slice(-4)}`;
|
||||
}
|
||||
|
||||
// ---------------------------------------------------------------------------
|
||||
// SecretRef resolution
|
||||
// ---------------------------------------------------------------------------
|
||||
|
||||
interface SecretRef {
|
||||
source: string;
|
||||
provider?: string;
|
||||
id: string;
|
||||
}
|
||||
|
||||
function resolveSecretInput(
|
||||
value: unknown,
|
||||
dotenvVars: Record<string, string>,
|
||||
): { resolved: string | null; source: string; note?: string } {
|
||||
if (!value) return { resolved: null, source: 'missing' };
|
||||
|
||||
// Plain string
|
||||
if (typeof value === 'string') {
|
||||
// Check for env template: "${VAR_NAME}"
|
||||
const envMatch = value.match(/^\$\{([^}]+)\}$/);
|
||||
if (envMatch) {
|
||||
const envKey = envMatch[1];
|
||||
const envVal =
|
||||
dotenvVars[envKey] ?? process.env[envKey] ?? null;
|
||||
if (envVal) {
|
||||
return { resolved: envVal, source: 'env_template' };
|
||||
}
|
||||
return {
|
||||
resolved: null,
|
||||
source: 'env_template',
|
||||
note: `Environment variable ${envKey} not found`,
|
||||
};
|
||||
}
|
||||
|
||||
// Plain literal value
|
||||
return { resolved: value, source: 'plain' };
|
||||
}
|
||||
|
||||
// SecretRef object
|
||||
if (typeof value === 'object' && value !== null) {
|
||||
const ref = value as SecretRef;
|
||||
if (ref.source === 'env') {
|
||||
const envVal =
|
||||
dotenvVars[ref.id] ?? process.env[ref.id] ?? null;
|
||||
if (envVal) {
|
||||
return { resolved: envVal, source: 'env_ref' };
|
||||
}
|
||||
return {
|
||||
resolved: null,
|
||||
source: 'env_ref',
|
||||
note: `Environment variable ${ref.id} not found`,
|
||||
};
|
||||
}
|
||||
if (ref.source === 'file') {
|
||||
return {
|
||||
resolved: null,
|
||||
source: 'file_ref',
|
||||
note: `File-based secret (${ref.id}) — cannot auto-extract, add manually`,
|
||||
};
|
||||
}
|
||||
if (ref.source === 'exec') {
|
||||
return {
|
||||
resolved: null,
|
||||
source: 'exec_ref',
|
||||
note: `Exec-based secret (${ref.id}) — cannot auto-extract, add manually`,
|
||||
};
|
||||
}
|
||||
}
|
||||
|
||||
return { resolved: null, source: 'unknown' };
|
||||
}
|
||||
|
||||
// ---------------------------------------------------------------------------
|
||||
// Channel credential mapping
|
||||
// ---------------------------------------------------------------------------
|
||||
|
||||
interface ChannelCredentialSpec {
|
||||
// Fields to look for in the channel config
|
||||
fields: string[];
|
||||
// Corresponding NanoClaw env var names
|
||||
envVars: string[];
|
||||
}
|
||||
|
||||
const CHANNEL_SPECS: Record<string, ChannelCredentialSpec> = {
|
||||
telegram: {
|
||||
fields: ['botToken'],
|
||||
envVars: ['TELEGRAM_BOT_TOKEN'],
|
||||
},
|
||||
discord: {
|
||||
fields: ['token'],
|
||||
envVars: ['DISCORD_BOT_TOKEN'],
|
||||
},
|
||||
slack: {
|
||||
fields: ['botToken', 'appToken'],
|
||||
envVars: ['SLACK_BOT_TOKEN', 'SLACK_APP_TOKEN'],
|
||||
},
|
||||
whatsapp: {
|
||||
fields: [], // Auth-state based, no token field
|
||||
envVars: [],
|
||||
},
|
||||
};
|
||||
|
||||
// ---------------------------------------------------------------------------
|
||||
// CLI arg parsing
|
||||
// ---------------------------------------------------------------------------
|
||||
|
||||
function parseArgs(): { channel: string; stateDir: string; writeEnv: string } {
|
||||
const args = process.argv.slice(2);
|
||||
let channel = '';
|
||||
let stateDir = '';
|
||||
let writeEnv = '';
|
||||
|
||||
for (let i = 0; i < args.length; i++) {
|
||||
if (args[i] === '--channel' && args[i + 1]) {
|
||||
channel = args[++i].toLowerCase();
|
||||
}
|
||||
if (args[i] === '--state-dir' && args[i + 1]) {
|
||||
stateDir = args[++i];
|
||||
}
|
||||
if (args[i] === '--write-env' && args[i + 1]) {
|
||||
writeEnv = args[++i];
|
||||
}
|
||||
}
|
||||
|
||||
if (!channel) {
|
||||
console.error('Usage: --channel <name> --state-dir <path> [--write-env <path>]');
|
||||
process.exit(1);
|
||||
}
|
||||
|
||||
// Expand ~ prefix
|
||||
if (stateDir.startsWith('~')) {
|
||||
stateDir = path.join(os.homedir(), stateDir.slice(1));
|
||||
}
|
||||
|
||||
// Default state dir
|
||||
if (!stateDir) {
|
||||
const home = os.homedir();
|
||||
if (fs.existsSync(path.join(home, '.openclaw'))) {
|
||||
stateDir = path.join(home, '.openclaw');
|
||||
} else if (fs.existsSync(path.join(home, '.clawdbot'))) {
|
||||
stateDir = path.join(home, '.clawdbot');
|
||||
} else {
|
||||
console.error(
|
||||
'No OpenClaw directory found. Use --state-dir to specify.',
|
||||
);
|
||||
process.exit(1);
|
||||
}
|
||||
}
|
||||
|
||||
return { channel, stateDir, writeEnv };
|
||||
}
|
||||
|
||||
// ---------------------------------------------------------------------------
|
||||
// .env writer — appends or replaces a KEY=VALUE line
|
||||
// ---------------------------------------------------------------------------
|
||||
|
||||
function writeEnvVar(envPath: string, key: string, value: string): void {
|
||||
let content = '';
|
||||
if (fs.existsSync(envPath)) {
|
||||
content = fs.readFileSync(envPath, 'utf-8');
|
||||
}
|
||||
|
||||
const pattern = new RegExp(`^${key}=.*$`, 'm');
|
||||
const line = `${key}="${value}"`;
|
||||
|
||||
if (pattern.test(content)) {
|
||||
content = content.replace(pattern, line);
|
||||
} else {
|
||||
content = content.trimEnd() + (content ? '\n' : '') + line + '\n';
|
||||
}
|
||||
|
||||
fs.writeFileSync(envPath, content);
|
||||
}
|
||||
|
||||
// ---------------------------------------------------------------------------
|
||||
// Main
|
||||
// ---------------------------------------------------------------------------
|
||||
|
||||
function main(): void {
|
||||
const { channel, stateDir, writeEnv } = parseArgs();
|
||||
const spec = CHANNEL_SPECS[channel];
|
||||
|
||||
// Load dotenv from state dir
|
||||
const dotenvVars = parseDotenv(path.join(stateDir, '.env'));
|
||||
|
||||
// Also check auth-profiles.json for API keys
|
||||
const authProfilesPath = path.join(stateDir, 'auth-profiles.json');
|
||||
let authProfiles: Record<string, unknown> = {};
|
||||
if (fs.existsSync(authProfilesPath)) {
|
||||
try {
|
||||
authProfiles = JSON.parse(
|
||||
fs.readFileSync(authProfilesPath, 'utf-8'),
|
||||
) as Record<string, unknown>;
|
||||
} catch {
|
||||
// Ignore parse errors
|
||||
}
|
||||
}
|
||||
|
||||
// WhatsApp special case: no token, auth-state based.
|
||||
// OpenClaw stores Baileys auth at <stateDir>/credentials/whatsapp/<accountId>/
|
||||
// using useMultiFileAuthState (same as NanoClaw). The files are directly compatible.
|
||||
if (channel === 'whatsapp') {
|
||||
const authPaths = [
|
||||
path.join(stateDir, 'credentials', 'whatsapp', 'default'),
|
||||
path.join(stateDir, 'credentials', 'whatsapp'),
|
||||
path.join(stateDir, 'wa-auth'),
|
||||
];
|
||||
|
||||
// Also scan credentials/whatsapp/ for any account subdirectory
|
||||
const waCredsDir = path.join(stateDir, 'credentials', 'whatsapp');
|
||||
if (fs.existsSync(waCredsDir)) {
|
||||
try {
|
||||
for (const entry of fs.readdirSync(waCredsDir)) {
|
||||
const candidate = path.join(waCredsDir, entry);
|
||||
if (fs.statSync(candidate).isDirectory()) {
|
||||
authPaths.push(candidate);
|
||||
}
|
||||
}
|
||||
} catch {
|
||||
// ignore
|
||||
}
|
||||
}
|
||||
let authStatePath = '';
|
||||
for (const p of authPaths) {
|
||||
// Look for creds.json inside the directory — that confirms valid Baileys auth state
|
||||
if (fs.existsSync(path.join(p, 'creds.json'))) {
|
||||
authStatePath = p;
|
||||
break;
|
||||
}
|
||||
}
|
||||
|
||||
emitStatus({
|
||||
CHANNEL: 'whatsapp',
|
||||
HAS_CREDENTIAL: false,
|
||||
CREDENTIAL_SOURCE: 'auth_state',
|
||||
NOTE: authStatePath
|
||||
? `Baileys auth state found at ${authStatePath}. May not be portable across versions — recommend re-authenticating.`
|
||||
: 'No WhatsApp auth state found. Will need to authenticate during setup.',
|
||||
AUTH_STATE_PATH: authStatePath || 'not_found',
|
||||
});
|
||||
return;
|
||||
}
|
||||
|
||||
// Unknown channel
|
||||
if (!spec) {
|
||||
emitStatus({
|
||||
CHANNEL: channel,
|
||||
HAS_CREDENTIAL: false,
|
||||
NOTE: `Channel "${channel}" is not supported by NanoClaw. Supported: telegram, discord, slack, whatsapp.`,
|
||||
});
|
||||
return;
|
||||
}
|
||||
|
||||
// Load OpenClaw config
|
||||
let config: Record<string, unknown> | null = null;
|
||||
for (const name of ['openclaw.json', 'clawdbot.json']) {
|
||||
const configPath = path.join(stateDir, name);
|
||||
if (fs.existsSync(configPath)) {
|
||||
try {
|
||||
config = parseJson5(
|
||||
fs.readFileSync(configPath, 'utf-8'),
|
||||
) as Record<string, unknown>;
|
||||
break;
|
||||
} catch {
|
||||
// Try next
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
if (!config) {
|
||||
emitStatus({
|
||||
CHANNEL: channel,
|
||||
HAS_CREDENTIAL: false,
|
||||
NOTE: 'Could not load openclaw.json',
|
||||
});
|
||||
return;
|
||||
}
|
||||
|
||||
const channels =
|
||||
(config.channels as Record<string, unknown> | undefined) ?? {};
|
||||
const channelConfig =
|
||||
(channels[channel] as Record<string, unknown> | undefined) ?? {};
|
||||
|
||||
// Try to resolve each credential field
|
||||
const results: Array<{
|
||||
envVar: string;
|
||||
resolved: string | null;
|
||||
masked: string;
|
||||
source: string;
|
||||
note?: string;
|
||||
}> = [];
|
||||
|
||||
for (let i = 0; i < spec.fields.length; i++) {
|
||||
const field = spec.fields[i];
|
||||
const envVar = spec.envVars[i];
|
||||
|
||||
// Check top-level channel config first
|
||||
let rawValue = channelConfig[field];
|
||||
|
||||
// If not found, check first account
|
||||
if (!rawValue && channelConfig.accounts) {
|
||||
const accounts = channelConfig.accounts as Record<string, unknown>;
|
||||
const firstAccount = Object.values(accounts)[0] as
|
||||
| Record<string, unknown>
|
||||
| undefined;
|
||||
if (firstAccount) {
|
||||
rawValue = firstAccount[field];
|
||||
}
|
||||
}
|
||||
|
||||
const { resolved, source, note } = resolveSecretInput(
|
||||
rawValue,
|
||||
dotenvVars,
|
||||
);
|
||||
results.push({
|
||||
envVar,
|
||||
resolved,
|
||||
masked: resolved ? maskCredential(resolved) : '',
|
||||
source,
|
||||
note,
|
||||
});
|
||||
}
|
||||
|
||||
// Emit results for the primary credential
|
||||
const primary = results[0];
|
||||
if (!primary) {
|
||||
emitStatus({
|
||||
CHANNEL: channel,
|
||||
HAS_CREDENTIAL: false,
|
||||
NOTE: `No credential fields defined for ${channel}`,
|
||||
});
|
||||
return;
|
||||
}
|
||||
|
||||
// If --write-env is set and credentials were resolved, write directly to .env.
|
||||
// Credential values never appear in stdout.
|
||||
let written = 0;
|
||||
if (writeEnv) {
|
||||
for (const r of results) {
|
||||
if (r.resolved) {
|
||||
writeEnvVar(writeEnv, r.envVar, r.resolved);
|
||||
written++;
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
const fields: Record<string, string | number | boolean> = {
|
||||
CHANNEL: channel,
|
||||
HAS_CREDENTIAL: !!primary.resolved,
|
||||
CREDENTIAL_SOURCE: primary.source,
|
||||
CREDENTIAL_MASKED: primary.masked || 'none',
|
||||
NANOCLAW_ENV_VAR: primary.envVar,
|
||||
};
|
||||
|
||||
if (writeEnv && written > 0) {
|
||||
fields.WRITTEN_TO = writeEnv;
|
||||
fields.WRITTEN_COUNT = written;
|
||||
}
|
||||
if (primary.note) {
|
||||
fields.NOTE = primary.note;
|
||||
}
|
||||
|
||||
// Additional credentials (e.g. Slack has botToken + appToken)
|
||||
if (results.length > 1) {
|
||||
for (let i = 1; i < results.length; i++) {
|
||||
const extra = results[i];
|
||||
const suffix = `_${i + 1}`;
|
||||
fields[`HAS_CREDENTIAL${suffix}`] = !!extra.resolved;
|
||||
fields[`CREDENTIAL_SOURCE${suffix}`] = extra.source;
|
||||
fields[`CREDENTIAL_MASKED${suffix}`] = extra.masked || 'none';
|
||||
fields[`NANOCLAW_ENV_VAR${suffix}`] = extra.envVar;
|
||||
if (extra.note) {
|
||||
fields[`NOTE${suffix}`] = extra.note;
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
emitStatus(fields);
|
||||
}
|
||||
|
||||
main();
|
||||
484
.claude/skills/migrate-nanoclaw/SKILL.md
Normal file
484
.claude/skills/migrate-nanoclaw/SKILL.md
Normal file
@@ -0,0 +1,484 @@
|
||||
---
|
||||
name: migrate-nanoclaw
|
||||
description: Extracts user customizations from a fork, generates a replayable migration guide, and upgrades to upstream by reapplying customizations on a clean base. Replaces merge-based upgrades with intent-based migration.
|
||||
---
|
||||
|
||||
# Context
|
||||
|
||||
NanoClaw users fork the repo and customize it — changing config values, editing source files, modifying personas, adding skills. When upstream ships updates or refactors, `git merge` produces painful conflicts because the same core files were changed on both sides.
|
||||
|
||||
This skill extracts the user's customizations into a migration guide — capturing both the intent (what they want) and the implementation details (how they did it, with code snippets, API calls, and specific configurations). On upgrade, it checks out clean upstream in a worktree, then reapplies customizations using the guide. No merge conflicts because there's nothing to merge.
|
||||
|
||||
The migration guide is markdown, not structured data. It needs to capture the full range of what a user might customize, with enough implementation detail that a fresh Claude session can reapply it without having seen the original code. Standard changes (config values, simple logic) can be described briefly. Non-standard changes (specific APIs, custom integrations, unusual patterns) need code snippets and precise instructions.
|
||||
|
||||
Two phases: **Extract** (build the migration guide) and **Upgrade** (use it). If a guide already exists, offer to skip to Upgrade.
|
||||
|
||||
# Principles
|
||||
|
||||
- Never proceed with a dirty working tree.
|
||||
- Always create a rollback point (backup branch + tag) before touching anything.
|
||||
- The migration guide is the source of truth, not diffs.
|
||||
- Use a worktree to validate before affecting the live install.
|
||||
- Data directories (`groups/`, `store/`, `data/`, `.env`) are never touched — only code.
|
||||
- Be helpful: offer to do things (stash, commit, stop services) rather than telling the user to do them.
|
||||
- **Use sub-agents for exploration.** Spawn haiku sub-agents to explore the codebase, trace skill merges, diff files, and identify customizations. This keeps the main context focused on the user conversation and decision-making.
|
||||
- **Always use absolute paths in worktrees.** The Bash tool resets the working directory between calls. Never use relative `cd .upgrade-worktree` — always use the full absolute path: `cd /absolute/path/.upgrade-worktree && <command>`. Store the worktree absolute path in a variable at creation time and reference it throughout.
|
||||
- **Balance exploration and asking.** Don't bombard the user with questions when you can figure things out from the code. Don't burn endless tokens exploring when the user could clarify in one sentence. Use sub-agents to explore first, then ask the user targeted questions about things that are ambiguous or where intent isn't clear from the code alone.
|
||||
- **Scale effort to complexity.** Not every migration needs the full process. Assess the scope early and take the lightest path that fits.
|
||||
|
||||
---
|
||||
|
||||
# Phase 1: Extract
|
||||
|
||||
## 1.0 Preflight
|
||||
|
||||
Run `git status --porcelain`. If non-empty, offer to stash or commit for them (AskUserQuestion: "Stash changes" / "Commit changes" / "I'll handle it"). If they want to commit, stage and commit with a descriptive message. If they want to stash, run `git stash push -m "pre-migration stash"`.
|
||||
|
||||
Check remotes with `git remote -v`. If `upstream` is missing, ask for the URL (default: `https://github.com/qwibitai/nanoclaw.git`), add it, then `git fetch upstream --prune`.
|
||||
|
||||
Detect upstream branch: check `git branch -r | grep upstream/` for `main` or `master`. Store as UPSTREAM_BRANCH.
|
||||
|
||||
## 1.1 Assess scope and determine path
|
||||
|
||||
Quickly assess the scale of divergence, check for an existing guide, and determine the right approach — all before asking the user anything.
|
||||
|
||||
```bash
|
||||
BASE=$(git merge-base HEAD upstream/$UPSTREAM_BRANCH)
|
||||
# Divergence stats
|
||||
git rev-list --count $BASE..upstream/$UPSTREAM_BRANCH # upstream commits
|
||||
git rev-list --count $BASE..HEAD # user commits
|
||||
git diff --name-only $BASE..HEAD | wc -l # user changed files
|
||||
git diff --stat $BASE..HEAD | tail -1 # insertions/deletions
|
||||
git diff --name-only $BASE..upstream/$UPSTREAM_BRANCH | wc -l # upstream changed files
|
||||
```
|
||||
|
||||
Check for existing guide: `.nanoclaw-migrations/guide.md` or `.nanoclaw-migrations/index.md`.
|
||||
|
||||
**Determine the tier based on the total diff from base:**
|
||||
|
||||
### Tier 1: Lightweight — suggest `/update-nanoclaw` instead
|
||||
|
||||
Conditions (any of):
|
||||
- Very few upstream changes (< ~5 commits) AND few user changes (< ~3 changed files)
|
||||
- User recently updated/migrated (merge-base is close to upstream HEAD)
|
||||
|
||||
Tell the user the scope is small and suggest `/update-nanoclaw` might be simpler. Let them choose.
|
||||
|
||||
### Tier 2: Standard
|
||||
|
||||
Conditions:
|
||||
- Moderate total diff (3-15 changed files, no large number of new files)
|
||||
- Manageable scope that fits in a single guide file
|
||||
|
||||
### Tier 3: Complex
|
||||
|
||||
Conditions (any of):
|
||||
- Many new files added (indicates many skills applied) — discount files that come purely from skill merges when assessing complexity; a fork with 3 skills and no other changes is simpler than it looks by file count alone
|
||||
- Deep source changes to core files (`src/index.ts`, `src/container-runner.ts`, etc.) beyond what skills introduced
|
||||
- Lots of insertions/deletions in user-authored code (not skill-merged code)
|
||||
- Many skills applied (3+) AND the user confirms or sub-agents find customizations on top of them
|
||||
|
||||
Use the full process: multiple sub-agents in parallel, directory-based guide, migration plan.
|
||||
|
||||
**Now combine the scope assessment with initial user input in one interaction.** Present the scope summary (how many commits, files, which tier) and ask (AskUserQuestion):
|
||||
|
||||
For Tier 1:
|
||||
- **Use /update-nanoclaw** — simpler merge-based approach
|
||||
- **Proceed with full migration** — continue
|
||||
|
||||
For Tier 2/3 (with or without existing guide):
|
||||
- If guide exists and is current: **Skip to upgrade** / **Update guide** (add new changes) / **Re-extract from scratch**
|
||||
- If guide exists but is stale: **Update guide** (recommended) / **Re-extract from scratch** / **Skip to upgrade anyway**
|
||||
- If no guide: **Yes, let me describe my customizations first** / **Just figure it out** / **A bit of both**
|
||||
|
||||
This single interaction replaces what were previously separate steps for scope assessment, user input, and existing guide check.
|
||||
|
||||
## 1.2 Update existing guide (if applicable)
|
||||
|
||||
If the user chose to update an existing guide rather than re-extract:
|
||||
|
||||
1. Read the existing guide
|
||||
2. Find commits made since the guide was generated (compare guide's recorded base hash against current HEAD)
|
||||
3. Spawn a haiku sub-agent to analyze only the new changes:
|
||||
> Diff HEAD against `<guide-recorded-hash>`. For each changed file, summarize what changed and why.
|
||||
4. Present the new changes to the user for confirmation
|
||||
5. Append new customizations to the existing guide, update the header hashes
|
||||
6. Skip to Phase 2
|
||||
|
||||
## 1.3 Explore the codebase
|
||||
|
||||
Spawn a haiku sub-agent (Agent tool, model: haiku) for initial exploration:
|
||||
|
||||
> Explore this NanoClaw fork to identify all changes from the upstream base. Run these commands and report back:
|
||||
>
|
||||
> 1. `git diff --name-only $BASE..HEAD` — all changed files
|
||||
> 2. `git log --oneline $BASE..HEAD` — all commits (look for skill branch merges like `Merge branch 'skill/*'`)
|
||||
> 3. `git branch -r --list 'upstream/skill/*'` — available upstream skill branches
|
||||
> 4. `ls .claude/skills/` — installed skills
|
||||
> 5. For each skill merge found, record the merge commit hash
|
||||
>
|
||||
> Report: (a) list of applied skills with their merge commit hashes, (b) list of all changed files, (c) any custom skill directories that don't match upstream branches.
|
||||
|
||||
From the sub-agent results, identify:
|
||||
- **Which files came purely from skill merges** — these will be reapplied by re-merging skill branches in Phase 2
|
||||
- **Everything else** — all remaining changes are customizations to analyze (whether they're on skill-touched files or not)
|
||||
|
||||
Don't try to distinguish "user modified a skill file" from "user made their own change" at this stage. The sub-agents in 1.4 will look at all non-skill changes together and surface what matters.
|
||||
|
||||
## 1.4 Analyze customizations
|
||||
|
||||
For each applied skill, ask the user in a single batched question (AskUserQuestion, multiSelect):
|
||||
|
||||
> "I found these applied skills. Select any you customized further after applying:"
|
||||
|
||||
Options: one per skill, plus "None — all used as-is".
|
||||
|
||||
Then spawn sub-agents to analyze all non-skill changes. For Tier 2, one or two agents. For Tier 3, run in parallel by area:
|
||||
|
||||
- **Config + build files** — one sub-agent
|
||||
- **Source files** (`src/*.ts`) — one sub-agent
|
||||
- **Skills the user flagged as modified** (or all of them for Tier 3) — one sub-agent per skill, comparing the user's current files against the skill merge commit version:
|
||||
```
|
||||
git diff <merge-commit-hash>..HEAD -- <files-touched-by-skill>
|
||||
```
|
||||
- **Container files** — one sub-agent (if changes exist)
|
||||
|
||||
Each sub-agent task:
|
||||
|
||||
> Read these diffs and the current file contents. For each change:
|
||||
> 1. `git diff $BASE..HEAD -- <file>` (or `git diff <skill-merge-hash>..HEAD -- <file>` for skill-modified files)
|
||||
> 2. Read the full current file for context
|
||||
> 3. Summarize: what changed, what the likely intent is
|
||||
> 4. Assess detail level: could a fresh Claude session reproduce this from intent alone, or does it need specific code snippets, API details, import paths?
|
||||
> 5. For non-standard changes, extract the key code, imports, API calls, and configurations verbatim.
|
||||
|
||||
**Inter-skill conflicts:** If multiple skills are applied, spawn an additional sub-agent to check for interactions between them. Look for:
|
||||
- Duplicate declarations (same variable/constant defined by two skill branches)
|
||||
- Conflicting approaches (one skill throws on missing env var, another provides a fallback)
|
||||
- Shared files modified by multiple skills
|
||||
|
||||
Document any findings in the "Skill Interactions" section of the migration guide so they can be resolved after skill branches are re-merged during upgrade.
|
||||
|
||||
## 1.5 Confirm with user
|
||||
|
||||
After sub-agents report back, compile the findings and present to the user.
|
||||
|
||||
For customizations where the intent is clear (config values, simple modifications): present as a batch for confirmation. Use AskUserQuestion with multiSelect to let the user flag any entries that need correction.
|
||||
|
||||
For customizations where the intent is ambiguous: ask specific questions. Don't ask "what did you do?" — instead ask "I see you added X in this file. Was this for Y or something else?"
|
||||
|
||||
The user can select "Other" on any question to provide their own description.
|
||||
|
||||
## 1.6 Migration plan (Tier 3 only)
|
||||
|
||||
For complex migrations, before writing the guide, create a migration plan:
|
||||
|
||||
- **Order of operations**: which customizations depend on others, which skills must be applied first
|
||||
- **Staging**: whether the migration should happen in stages (e.g. apply skills first, validate, then apply source customizations)
|
||||
- **Risk areas**: customizations that touch files heavily changed by upstream — these may need manual review
|
||||
- **Interactions**: customizations that interact with each other (e.g. a source change that depends on a skill, or two customizations that touch the same file)
|
||||
|
||||
Present the plan to the user for review before proceeding to the guide.
|
||||
|
||||
## 1.7 Write the migration guide
|
||||
|
||||
**Storage:** `.nanoclaw-migrations/guide.md` for Tier 2. `.nanoclaw-migrations/` directory with `index.md` and section files for Tier 3.
|
||||
|
||||
**Verification:** After writing the guide, read it back and verify:
|
||||
- Every referenced file path exists in the current codebase
|
||||
- Code snippets match what's actually in the files
|
||||
- No customizations from the analysis were accidentally omitted
|
||||
|
||||
The guide is structured markdown that a fresh Claude session can follow to reproduce this user's exact setup on a clean upstream checkout.
|
||||
|
||||
Structure:
|
||||
|
||||
```markdown
|
||||
# NanoClaw Migration Guide
|
||||
|
||||
Generated: <timestamp>
|
||||
Base: <BASE hash>
|
||||
HEAD at generation: <HEAD hash>
|
||||
Upstream: <upstream HEAD hash>
|
||||
|
||||
## Migration Plan
|
||||
|
||||
(Tier 3 only — big-picture overview of order, staging, risks)
|
||||
|
||||
## Applied Skills
|
||||
|
||||
List each skill with its branch name. These are reapplied by merging the upstream skill branch.
|
||||
|
||||
- `add-telegram` — branch `skill/telegram`
|
||||
- `add-voice-transcription` — branch `skill/voice-transcription`
|
||||
|
||||
Custom skills (user-created, not from upstream): `.claude/skills/my-custom-skill/` — copy as-is from main tree.
|
||||
|
||||
## Skill Interactions
|
||||
|
||||
(Document known conflicts or interactions between applied skills.
|
||||
When two or more skills modify the same file or depend on shared
|
||||
config, describe the conflict and how to resolve it after merging.
|
||||
Example: skill A and skill B both add a PROXY_BIND_HOST declaration —
|
||||
after merging both, deduplicate. Or: skill A throws if ENV_VAR is
|
||||
missing, but skill B provides a fallback — use the fallback version.)
|
||||
|
||||
## Modifications to Applied Skills
|
||||
|
||||
### <Skill name>: <what was modified>
|
||||
|
||||
**Intent:** ...
|
||||
|
||||
**Files:** ...
|
||||
|
||||
**How to apply:** (after the skill branch has been merged)
|
||||
|
||||
...
|
||||
|
||||
## Customizations
|
||||
|
||||
### <Descriptive title for customization>
|
||||
|
||||
**Intent:** What the user wants and why.
|
||||
|
||||
**Files:** Which files to modify.
|
||||
|
||||
**How to apply:**
|
||||
|
||||
<For standard changes, a brief description is enough.>
|
||||
|
||||
<For non-standard changes, include code snippets, API details,
|
||||
specific values, import paths — everything needed to reproduce
|
||||
without seeing the original diff.>
|
||||
|
||||
### <Next customization...>
|
||||
```
|
||||
|
||||
**Judging detail level:** For each customization, assess whether a fresh Claude session could reproduce it from intent alone:
|
||||
- **Standard changes** (config values, simple logic, well-known patterns): describe the intent and the target. Example: "Change `POLL_INTERVAL` in `src/config.ts` from 2000 to 1000."
|
||||
- **Non-standard changes** (specific API usage, custom integrations, unusual patterns, library-specific configurations): include the actual code snippets, import paths, API endpoints, configuration objects — everything needed to reproduce it without guessing.
|
||||
|
||||
Example entries at different detail levels:
|
||||
|
||||
**Standard (brief):**
|
||||
```markdown
|
||||
### Custom trigger word
|
||||
|
||||
**Intent:** Use `@Bob` instead of the default `@Andy`.
|
||||
|
||||
**Files:** `src/config.ts`
|
||||
|
||||
**How to apply:** Change the default value of `ASSISTANT_NAME` from `'Andy'` to `'Bob'`.
|
||||
```
|
||||
|
||||
**Non-standard (detailed):**
|
||||
```markdown
|
||||
### Spanish translation for outbound messages
|
||||
|
||||
**Intent:** All outbound messages are translated to Spanish before sending. Uses the DeepL API via the `deepl-node` package.
|
||||
|
||||
**Files:** `src/router.ts`, `package.json`
|
||||
|
||||
**How to apply:**
|
||||
|
||||
1. Add dependency: `npm install deepl-node`
|
||||
|
||||
2. In `src/router.ts`, add import at top:
|
||||
```typescript
|
||||
import * as deepl from 'deepl-node';
|
||||
const translator = new deepl.Translator(process.env.DEEPL_API_KEY!);
|
||||
```
|
||||
|
||||
3. In the `formatOutbound` function, before the return statement, add:
|
||||
```typescript
|
||||
const result = await translator.translateText(text, null, 'es');
|
||||
text = result.text;
|
||||
```
|
||||
Note: the function needs to be made async if it isn't already.
|
||||
```
|
||||
|
||||
After writing, offer to commit for the user:
|
||||
```bash
|
||||
git add .nanoclaw-migrations/
|
||||
git commit -m "chore: save migration guide"
|
||||
```
|
||||
|
||||
Ask (AskUserQuestion): "Migration guide saved. Want to upgrade now or later?"
|
||||
- **Upgrade now** — continue to Phase 2
|
||||
- **Later** — stop here
|
||||
|
||||
---
|
||||
|
||||
# Phase 2: Upgrade
|
||||
|
||||
## 2.0 Preflight
|
||||
|
||||
Same checks as 1.0 — clean tree (offer to stash/commit if dirty), upstream configured, fetch latest.
|
||||
|
||||
Read the migration guide. If missing, tell the user you need to extract customizations first and ask if they want to do that now.
|
||||
|
||||
**New-changes guard:** Compare the guide's "HEAD at generation" hash against current HEAD. If there are commits since the guide was generated, warn the user:
|
||||
|
||||
> "You've made changes since the migration guide was generated. These changes won't be included in the upgrade."
|
||||
|
||||
AskUserQuestion:
|
||||
- **Update the guide first** — go to step 1.2 to incorporate new changes
|
||||
- **Proceed anyway** — user accepts that recent changes will be lost
|
||||
- **Abort** — stop
|
||||
|
||||
## 2.1 Safety net
|
||||
|
||||
```bash
|
||||
HASH=$(git rev-parse --short HEAD)
|
||||
TIMESTAMP=$(date +%Y%m%d-%H%M%S)
|
||||
git branch backup/pre-migrate-$HASH-$TIMESTAMP
|
||||
git tag pre-migrate-$HASH-$TIMESTAMP
|
||||
```
|
||||
|
||||
Save the tag name for rollback instructions at the end.
|
||||
|
||||
## 2.2 Preview upstream changes
|
||||
|
||||
```bash
|
||||
BASE=$(git merge-base HEAD upstream/$UPSTREAM_BRANCH)
|
||||
git log --oneline $BASE..upstream/$UPSTREAM_BRANCH
|
||||
git diff $BASE..upstream/$UPSTREAM_BRANCH -- CHANGELOG.md
|
||||
```
|
||||
|
||||
If there are `[BREAKING]` entries, show them and explain how they interact with the user's customizations from the migration guide.
|
||||
|
||||
Ask (AskUserQuestion) to proceed or abort.
|
||||
|
||||
## 2.3 Create upgrade worktree
|
||||
|
||||
```bash
|
||||
PROJECT_ROOT=$(pwd)
|
||||
git worktree add .upgrade-worktree upstream/$UPSTREAM_BRANCH --detach
|
||||
WORKTREE="$PROJECT_ROOT/.upgrade-worktree"
|
||||
```
|
||||
|
||||
Store `$PROJECT_ROOT` and `$WORKTREE` as absolute paths. Use `$WORKTREE` in all subsequent commands — never `cd .upgrade-worktree` with a relative path.
|
||||
|
||||
## 2.4 Reapply skills in worktree
|
||||
|
||||
For each skill listed in the migration guide's "Applied Skills" section:
|
||||
|
||||
1. Check if branch exists: `git branch -r --list "upstream/$branch"`
|
||||
2. If yes, merge it in the worktree:
|
||||
```bash
|
||||
cd "$WORKTREE" && git merge upstream/skill/<name> --no-edit
|
||||
```
|
||||
3. If missing, warn the user (skill may have been removed or renamed upstream).
|
||||
4. If any skill merge conflicts, stop and tell the user — the skill needs updating for the new upstream.
|
||||
|
||||
Copy any custom skills mentioned in the guide from the main tree into the worktree.
|
||||
|
||||
## 2.5 Reapply customizations in worktree
|
||||
|
||||
Work in `.upgrade-worktree/`. Follow each customization section in the migration guide, including "Modifications to Applied Skills."
|
||||
|
||||
For Tier 3 migrations with a migration plan, follow the plan's ordering and staging. If the plan calls for staged validation (e.g. validate after skills, then validate after source changes), do so.
|
||||
|
||||
For each customization:
|
||||
1. Read the "How to apply" instructions from the guide
|
||||
2. Read the target file(s) in the worktree to understand the current upstream version
|
||||
3. Apply the changes as described — use the code snippets and specific instructions from the guide
|
||||
4. If the target file has changed significantly from what the guide expects (function removed, file restructured, API changed), flag it and ask the user what to do
|
||||
5. Verify the file has no syntax errors or broken imports after each change
|
||||
|
||||
For behavior customizations (CLAUDE.md files): copy from the main tree. These are user content, not code.
|
||||
|
||||
## 2.6 Validate in worktree
|
||||
|
||||
```bash
|
||||
cd "$WORKTREE" && npm install && npm run build && npm test
|
||||
```
|
||||
|
||||
If build fails, show the error. Fix only issues caused by the migration. If unclear, ask the user.
|
||||
|
||||
## 2.7 Live test (optional)
|
||||
|
||||
Ask (AskUserQuestion):
|
||||
- **Test live** — stop service, run from worktree against real data, send a test message
|
||||
- **Skip** — trust the build, proceed to swap
|
||||
|
||||
If testing live:
|
||||
|
||||
1. Stop the service (do this directly):
|
||||
```bash
|
||||
launchctl unload ~/Library/LaunchAgents/com.nanoclaw.plist 2>/dev/null || true
|
||||
```
|
||||
|
||||
2. Symlink data into the worktree:
|
||||
```bash
|
||||
ln -s "$PROJECT_ROOT/store" "$WORKTREE/store"
|
||||
ln -s "$PROJECT_ROOT/data" "$WORKTREE/data"
|
||||
ln -s "$PROJECT_ROOT/groups" "$WORKTREE/groups"
|
||||
ln -s "$PROJECT_ROOT/.env" "$WORKTREE/.env"
|
||||
```
|
||||
|
||||
3. Start from worktree: `cd "$WORKTREE" && npm run dev`
|
||||
|
||||
4. Ask the user to send a test message from their phone. Wait for them to confirm it works.
|
||||
|
||||
5. After confirmation, stop the dev server.
|
||||
|
||||
6. Clean up symlinks:
|
||||
```bash
|
||||
rm "$WORKTREE/store" "$WORKTREE/data" "$WORKTREE/groups" "$WORKTREE/.env"
|
||||
```
|
||||
|
||||
## 2.8 Swap into main tree
|
||||
|
||||
The swap must be done carefully — the worktree has the upgraded code, but main needs to point to it cleanly. Use absolute paths throughout.
|
||||
|
||||
```bash
|
||||
# 1. Capture the worktree HEAD before removing it
|
||||
WORKTREE_PATH=$(cd "$PROJECT_ROOT/.upgrade-worktree" && pwd)
|
||||
UPGRADE_COMMIT=$(git -C "$WORKTREE_PATH" rev-parse HEAD)
|
||||
|
||||
# 2. Copy the migration guide out of the worktree before removing it
|
||||
cp -r "$WORKTREE_PATH/.nanoclaw-migrations" /tmp/nanoclaw-migrations-backup 2>/dev/null || true
|
||||
|
||||
# 3. Remove the worktree
|
||||
git worktree remove "$WORKTREE_PATH" --force
|
||||
|
||||
# 4. Point the current branch at the upgraded commit
|
||||
git reset --hard $UPGRADE_COMMIT
|
||||
|
||||
# 5. Restore the migration guide and update its hashes
|
||||
cp -r /tmp/nanoclaw-migrations-backup/* .nanoclaw-migrations/ 2>/dev/null || true
|
||||
rm -rf /tmp/nanoclaw-migrations-backup
|
||||
```
|
||||
|
||||
Update the guide's header hashes to reflect the new state. Offer to commit:
|
||||
```bash
|
||||
git add .nanoclaw-migrations/
|
||||
git commit -m "chore: upgrade to upstream $(git rev-parse --short upstream/$UPSTREAM_BRANCH)"
|
||||
```
|
||||
|
||||
Do NOT use `git checkout -B` to create an intermediate branch — this caused issues in practice. The `git reset --hard` to the upgrade commit is the cleanest path since the backup tag already preserves the pre-upgrade state.
|
||||
|
||||
## 2.9 Post-upgrade
|
||||
|
||||
Run `npm install && npm run build` in the main tree to confirm.
|
||||
|
||||
Restart the service:
|
||||
```bash
|
||||
launchctl load ~/Library/LaunchAgents/com.nanoclaw.plist
|
||||
```
|
||||
|
||||
Show summary:
|
||||
- Previous version (backup tag)
|
||||
- New HEAD
|
||||
- Customizations reapplied (list from guide)
|
||||
- Skills reapplied
|
||||
- Rollback: `git reset --hard <backup-tag>`
|
||||
- Any customizations that needed manual adjustment
|
||||
|
||||
Offer to pop the stash if one was created in preflight: `git stash pop`
|
||||
|
||||
## Diagnostics
|
||||
|
||||
1. Use the Read tool to read `.claude/skills/migrate-nanoclaw/diagnostics.md`.
|
||||
2. Follow every step in that file before finishing.
|
||||
52
.claude/skills/migrate-nanoclaw/diagnostics.md
Normal file
52
.claude/skills/migrate-nanoclaw/diagnostics.md
Normal file
@@ -0,0 +1,52 @@
|
||||
# Diagnostics
|
||||
|
||||
Gather system info:
|
||||
|
||||
```bash
|
||||
node -p "require('./package.json').version"
|
||||
uname -s
|
||||
uname -m
|
||||
node -p "process.versions.node.split('.')[0]"
|
||||
```
|
||||
|
||||
Write `/tmp/nanoclaw-diagnostics.json`. No paths, usernames, hostnames, or IP addresses.
|
||||
|
||||
```json
|
||||
{
|
||||
"api_key": "phc_fx1Hhx9ucz8GuaJC8LVZWO8u03yXZZJJ6ObS4yplnaP",
|
||||
"event": "migrate_complete",
|
||||
"distinct_id": "<uuid>",
|
||||
"properties": {
|
||||
"success": true,
|
||||
"nanoclaw_version": "1.2.43",
|
||||
"os_platform": "darwin",
|
||||
"arch": "arm64",
|
||||
"node_major_version": 22,
|
||||
"migration_phase": "extract|upgrade|both",
|
||||
"tier": 2,
|
||||
"customization_count": 3,
|
||||
"skills_applied_count": 2,
|
||||
"skill_interaction_count": 0,
|
||||
"live_test": false,
|
||||
"breaking_changes_found": false,
|
||||
"error_count": 0
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Show the entire JSON to the user and ask via AskUserQuestion: **Yes** / **No** / **Never ask again**
|
||||
|
||||
**Yes**:
|
||||
```bash
|
||||
curl -s -X POST https://us.i.posthog.com/capture/ -H 'Content-Type: application/json' -d @/tmp/nanoclaw-diagnostics.json
|
||||
rm /tmp/nanoclaw-diagnostics.json
|
||||
```
|
||||
|
||||
**No**: `rm /tmp/nanoclaw-diagnostics.json`
|
||||
|
||||
**Never ask again**:
|
||||
1. Replace contents of `.claude/skills/setup/diagnostics.md` with `# Diagnostics — opted out`
|
||||
2. Replace contents of `.claude/skills/update-nanoclaw/diagnostics.md` with `# Diagnostics — opted out`
|
||||
3. Replace contents of `.claude/skills/migrate-nanoclaw/diagnostics.md` with `# Diagnostics — opted out`
|
||||
4. Remove the diagnostics sections from each corresponding SKILL.md
|
||||
5. `rm /tmp/nanoclaw-diagnostics.json`
|
||||
@@ -70,6 +70,22 @@ Run `npx tsx setup/index.ts --step environment` and parse the status block.
|
||||
- If HAS_REGISTERED_GROUPS=true → note existing config, offer to skip or reconfigure
|
||||
- Record APPLE_CONTAINER and DOCKER values for step 3
|
||||
|
||||
### OpenClaw Migration Detection
|
||||
|
||||
Check for an existing OpenClaw installation:
|
||||
|
||||
```bash
|
||||
ls -d ~/.openclaw 2>/dev/null || ls -d ~/.clawdbot 2>/dev/null
|
||||
```
|
||||
|
||||
If a directory is found, AskUserQuestion:
|
||||
|
||||
1. **Migrate now** — "Import identity, credentials, and settings from OpenClaw before continuing setup."
|
||||
2. **Fresh start** — "Skip migration and set up NanoClaw from scratch."
|
||||
3. **Migrate later** — "Continue setup now, run `/migrate-from-openclaw` anytime later."
|
||||
|
||||
If "Migrate now": invoke `/migrate-from-openclaw`, then return here and continue at step 2a (Timezone).
|
||||
|
||||
## 2a. Timezone
|
||||
|
||||
Run `npx tsx setup/index.ts --step timezone` and parse the status block.
|
||||
|
||||
@@ -9,6 +9,8 @@ uname -m
|
||||
node -p "process.versions.node.split('.')[0]"
|
||||
```
|
||||
|
||||
Check if the user migrated from OpenClaw during this setup session (i.e. `/migrate-from-openclaw` was invoked). If you're unsure (e.g. after context compaction), check for `migration-state.md` in the project root — it exists during and sometimes after migration.
|
||||
|
||||
Write `/tmp/nanoclaw-diagnostics.json`. No paths, usernames, hostnames, or IP addresses.
|
||||
|
||||
```json
|
||||
@@ -23,6 +25,7 @@ Write `/tmp/nanoclaw-diagnostics.json`. No paths, usernames, hostnames, or IP ad
|
||||
"arch": "arm64",
|
||||
"node_major_version": 22,
|
||||
"channels_selected": ["telegram", "whatsapp"],
|
||||
"migrated_from_openclaw": false,
|
||||
"error_count": 0,
|
||||
"failed_step": null
|
||||
}
|
||||
|
||||
@@ -112,6 +112,8 @@ Bucket the upstream changed files:
|
||||
- **Build/config** (`package.json`, `package-lock.json`, `tsconfig*.json`, `container/`, `launchd/`): review needed
|
||||
- **Other**: docs, tests, misc
|
||||
|
||||
**Large drift check:** If the upstream commit count and age suggest the user has a lot of catching up to do, mention that `/migrate-nanoclaw` might be a better fit — it extracts customizations and reapplies them on clean upstream instead of merging. Offer it as an option but don't push.
|
||||
|
||||
Present these buckets to the user and ask them to choose one path using AskUserQuestion:
|
||||
- A) **Full update**: merge all upstream changes
|
||||
- B) **Selective update**: cherry-pick specific upstream commits
|
||||
|
||||
Reference in New Issue
Block a user