@openparachute/agent 0.1.2 → 0.2.0

package/.claude/skills/add-github/SKILL.md

@@ -1,148 +0,0 @@
----
-name: add-github
-description: Add GitHub channel integration via Chat SDK. PR and issue comment threads as conversations.
----
-
-# Add GitHub Channel
-
-Adds GitHub support via the Chat SDK bridge. The agent participates in PR and issue comment threads.
-
-## Prerequisites
-
-You need a **dedicated GitHub bot account** (not your personal account). The adapter uses this account to post replies and filters out its own messages to avoid loops. Create a free GitHub account for your bot (e.g. `my-org-bot`), then invite it as a collaborator with write access to the repos you want monitored.
-
-## Install
-
-NanoClaw doesn't ship channels in trunk. This skill copies the GitHub adapter in from the `channels` branch.
-
-### Pre-flight (idempotent)
-
-Skip to **Credentials** if all of these are already in place:
-
-- `src/channels/github.ts` exists
-- `src/channels/index.ts` contains `import './github.js';`
-- `@chat-adapter/github` is listed in `package.json` dependencies
-
-Otherwise continue. Every step below is safe to re-run.
-
-### 1. Fetch the channels branch
-
-```bash
-git fetch origin channels
-```
-
-### 2. Copy the adapter
-
-```bash
-git show origin/channels:src/channels/github.ts > src/channels/github.ts
-```
-
-### 3. Append the self-registration import
-
-Append to `src/channels/index.ts` (skip if the line is already present):
-
-```typescript
-import './github.js';
-```
-
-### 4. Install the adapter package (pinned)
-
-```bash
-pnpm install @chat-adapter/github@4.26.0
-```
-
-### 5. Build
-
-```bash
-pnpm run build
-```
-
-## Credentials
-
-### 1. Create a Personal Access Token for the bot account
-
-Log in as your **bot account**, then:
-
-1. Go to [Settings > Developer Settings > Personal Access Tokens](https://github.com/settings/tokens)
-2. Create a **Fine-grained token** with:
-   - Repository access: select the repos you want the bot to monitor
-   - Permissions: **Pull requests** (Read & Write), **Issues** (Read & Write)
-3. Copy the token
-
-### 2. Set up a webhook on each repo
-
-On each repo (logged in as the repo owner/admin):
-
-1. Go to **Settings** > **Webhooks** > **Add webhook**
-2. Payload URL: `https://your-domain/webhook/github` (the shared webhook server, default port 3000)
-3. Content type: `application/json`
-4. Secret: generate a random string (e.g. `openssl rand -hex 20`)
-5. Events: select **Issue comments** and **Pull request review comments**
-
-### 3. Configure environment
-
-Add to `.env`:
-
-```bash
-GITHUB_TOKEN=github_pat_...
-GITHUB_WEBHOOK_SECRET=your-webhook-secret
-GITHUB_BOT_USERNAME=your-bot-username
-```
-
-`GITHUB_BOT_USERNAME` must match the bot account's GitHub username exactly. This is used for @-mention detection — the agent responds when someone writes `@your-bot-username` in a PR or issue comment.
-
-Sync to container: `mkdir -p data/env && cp .env data/env/env`
-
-## Wiring
-
-Ask the user: **Is this a private or public repo?**
-
-- **Private repo** — use `unknown_sender_policy: 'public'`. Only collaborators can comment anyway, so it's safe to let all comments through.
-- **Public repo** — use `unknown_sender_policy: 'strict'`. Only registered members can trigger the agent, preventing strangers from consuming agent resources. Add trusted collaborators as members (see below).
-
-Run `/manage-channels` to wire the GitHub channel to an agent group, or insert manually:
-
-```sql
--- Create messaging group (one per repo)
-INSERT INTO messaging_groups (id, channel_type, platform_id, name, is_group, unknown_sender_policy, created_at)
-VALUES ('mg-github-myrepo', 'github', 'github:owner/repo', 'owner/repo', 1, '<policy>', datetime('now'));
-
--- Wire to agent group
-INSERT INTO messaging_group_agents (id, messaging_group_id, agent_group_id, trigger_rules, response_scope, session_mode, priority, created_at)
-VALUES ('mga-github-myrepo', 'mg-github-myrepo', '<your-agent-group-id>', '', 'all', 'per-thread', 10, datetime('now'));
-```
-
-Replace `<policy>` with `public` or `strict` based on the user's choice above.
-
-### Adding members (for strict mode)
-
-When using `strict`, add each GitHub user who should be able to trigger the agent:
-
-```sql
--- Add user (kind = 'github', id = 'github:<numeric-user-id>')
-INSERT OR IGNORE INTO users (id, kind, display_name, created_at)
-VALUES ('github:<user-id>', 'github', '<username>', datetime('now'));
-
--- Grant membership to the agent group
-INSERT OR IGNORE INTO agent_group_members (user_id, agent_group_id)
-VALUES ('github:<user-id>', '<agent-group-id>');
-```
-
-To find a GitHub user's numeric ID: `gh api users/<username> --jq .id`
-
-Use `per-thread` session mode so each PR/issue gets its own agent session.
-
-## Next Steps
-
-If you're in the middle of `/setup`, return to the setup flow now.
-
-Otherwise, restart the service (`systemctl --user restart nanoclaw` or `launchctl kickstart -k gui/$(id -u)/com.nanoclaw`) to pick up the new channel.
-
-## Channel Info
-
-- **type**: `github`
-- **terminology**: GitHub has "repositories" containing "pull requests" and "issues." Each PR or issue comment thread is a separate conversation.
-- **how-to-find-id**: The platform ID is `github:owner/repo` (e.g. `github:acme/backend`). Each PR/issue becomes its own thread automatically.
-- **supports-threads**: yes (PR and issue comment threads are native conversations)
-- **typical-use**: Webhook-driven — the agent receives PR and issue comment events and responds in comment threads when @-mentioned. After the first mention, the thread is subscribed and the agent responds to all follow-up comments.
-- **default-isolation**: Use `per-thread` session mode. Each PR or issue gets its own isolated agent session. Typically wire to a dedicated agent group if the repo contains sensitive code.

package/.claude/skills/add-github/VERIFY.md

@@ -1,3 +0,0 @@
-# Verify GitHub Channel
-
-@mention the bot in a PR comment or issue comment. The bot should respond within a few seconds.

package/.claude/skills/add-gmail-tool/SKILL.md

@@ -1,229 +0,0 @@
----
-name: add-gmail-tool
-description: Add Gmail as an MCP tool (read, search, send, label, draft) using OneCLI-managed OAuth. The agent gets Gmail tools in every enabled group; OneCLI injects real tokens at request time so no raw credentials are ever in the container or on disk in usable form.
----
-
-# Add Gmail Tool (OneCLI-native)
-
-This skill wires the [`@gongrzhe/server-gmail-autoauth-mcp`](https://www.npmjs.com/package/@gongrzhe/server-gmail-autoauth-mcp) stdio MCP server into selected agent groups. The MCP server reads stub credentials containing the `onecli-managed` placeholder; the OneCLI gateway intercepts outbound calls to `gmail.googleapis.com` and injects the real OAuth bearer from its vault.
-
-Tools exposed (from `gmail-mcp@1.1.11`, surfaced to the agent as `mcp__gmail__<name>`): `search_emails`, `read_email`, `send_email`, `draft_email`, `delete_email`, `modify_email`, `batch_modify_emails`, `batch_delete_emails`, `download_attachment`, `list_email_labels`, `create_label`, `update_label`, `delete_label`, `get_or_create_label`, `list_filters`, `get_filter`, `create_filter`, `create_filter_from_template`, `delete_filter`.
-
-**Why this pattern:** v2's invariant is that containers never receive raw API keys — OneCLI is the sole credential path (see CHANGELOG v2.0.0). The stub-file pattern satisfies this: the container sees `"onecli-managed"` placeholders, the gateway swaps them in flight.
-
-## Phase 1: Pre-flight
-
-### Verify OneCLI has Gmail connected
-
-```bash
-onecli apps get --provider gmail
-```
-
-Expected: `"connection": { "status": "connected" }` with scopes including `gmail.readonly`, `gmail.modify`, `gmail.send`.
-
-If not connected, tell the user:
-
-> Open the OneCLI web UI at http://127.0.0.1:10254, go to Apps → Gmail, and click Connect. Sign in with the Google account you want the agent to act as.
-
-### Verify stub credentials exist
-
-```bash
-ls -la ~/.gmail-mcp/gcp-oauth.keys.json ~/.gmail-mcp/credentials.json 2>&1
-```
-
-If both exist and contain `"onecli-managed"`:
-
-```bash
-grep -l onecli-managed ~/.gmail-mcp/gcp-oauth.keys.json ~/.gmail-mcp/credentials.json
-```
-
-...skip to Phase 2.
-
-If either file exists but does **not** contain `onecli-managed`, **STOP** and tell the user — these are real OAuth credentials from a previous non-OneCLI install. Back them up, then delete before proceeding. The OneCLI migration normally handles this; if it didn't, something is wrong.
-
-If both files are absent, write them now:
-
-```bash
-mkdir -p ~/.gmail-mcp
-cat > ~/.gmail-mcp/gcp-oauth.keys.json <<'EOF'
-{
-  "installed": {
-    "client_id": "onecli-managed.apps.googleusercontent.com",
-    "client_secret": "onecli-managed",
-    "redirect_uris": ["http://localhost:3000/oauth2callback"]
-  }
-}
-EOF
-cat > ~/.gmail-mcp/credentials.json <<'EOF'
-{
-  "access_token": "onecli-managed",
-  "refresh_token": "onecli-managed",
-  "token_type": "Bearer",
-  "expiry_date": 99999999999999,
-  "scope": "https://www.googleapis.com/auth/gmail.readonly https://www.googleapis.com/auth/gmail.modify https://www.googleapis.com/auth/gmail.send"
-}
-EOF
-chmod 600 ~/.gmail-mcp/gcp-oauth.keys.json ~/.gmail-mcp/credentials.json
-```
-
-### Verify mount allowlist covers the path
-
-```bash
-cat ~/.config/nanoclaw/mount-allowlist.json
-```
-
-`~/.gmail-mcp` must sit under an `allowedRoots` entry (e.g. `/home/<user>`). If it doesn't, tell the user to run `/manage-mounts` first or add their home directory.
-
-### Check agent secret-mode
-
-For each target agent group, confirm OneCLI will inject Gmail secrets into its container. Find the OneCLI agent ID that matches the group's `agentGroupId`:
-
-```bash
-onecli agents list
-```
-
-If that agent's `secretMode` is `all`, you're done — Gmail secrets (identified by OneCLI's Gmail hostPattern) will auto-inject. If it's `selective`, explicitly assign the Gmail secrets:
-
-```bash
-onecli secrets list     # find Gmail secret IDs (OneCLI creates one per connected app)
-onecli agents set-secrets --id <agent-id> --secret-ids <gmail-secret-id>
-```
-
-## Phase 2: Apply Code Changes
-
-### Check if already applied
-
-```bash
-grep -q 'GMAIL_MCP_VERSION' container/Dockerfile && \
-grep -q "mcp__gmail__\*" container/agent-runner/src/providers/claude.ts && \
-echo "ALREADY APPLIED — skip to Phase 3"
-```
-
-### Add MCP server to Dockerfile
-
-Edit `container/Dockerfile`. Find the pinned-version ARG block:
-
-```dockerfile
-ARG CLAUDE_CODE_VERSION=2.1.116
-ARG AGENT_BROWSER_VERSION=latest
-ARG VERCEL_VERSION=latest
-ARG BUN_VERSION=1.3.12
-```
-
-Add a new line:
-
-```dockerfile
-ARG GMAIL_MCP_VERSION=1.1.11
-```
-
-Then find the last pnpm global-install `RUN` block (the one that installs `@anthropic-ai/claude-code`) and add a new block after it, before `# ---- Entrypoint`:
-
-```dockerfile
-RUN --mount=type=cache,target=/root/.cache/pnpm \
-    pnpm install -g \
-        "@gongrzhe/server-gmail-autoauth-mcp@${GMAIL_MCP_VERSION}" \
-        "zod-to-json-schema@3.22.5"
-```
-
-Pinned version matters — `minimumReleaseAge` in `pnpm-workspace.yaml` gates trunk installs, and CLAUDE.md requires a fixed ARG version for all Node CLIs installed into the image.
-
-**Why the `zod-to-json-schema` pin:** `@gongrzhe/server-gmail-autoauth-mcp@1.1.11` has loose deps (`zod-to-json-schema: ^3.22.1`, `zod: ^3.22.4`). pnpm resolves `zod-to-json-schema` to the latest 3.25.x, which imports `zod/v3` — a subpath that only exists in `zod>=3.25`. But `zod` resolves to `3.24.x` (highest satisfying `^3.22.4` without breaking peer ranges). Result: `ERR_PACKAGE_PATH_NOT_EXPORTED` at import time. Pinning `zod-to-json-schema` to a pre-v3-subpath version avoids it. Re-check if you bump `GMAIL_MCP_VERSION`.
-
-### Add tools to allowlist
-
-Edit `container/agent-runner/src/providers/claude.ts`. Find `'mcp__nanoclaw__*',` in `TOOL_ALLOWLIST` and add `'mcp__gmail__*',` after it.
-
-### Rebuild the container image
-
-```bash
-./container/build.sh
-```
-
-Must complete cleanly. The new `pnpm install -g` layer is ~60s first time (cached on rebuild).
-
-## Phase 3: Wire Per-Agent-Group
-
-For each agent group that should have Gmail (ask the user — typically their personal DM and CLI agents, sometimes shared household agents), edit `groups/<folder>/container.json` to add the mount and MCP server.
-
-Merge these into the group's `container.json`:
-
-```jsonc
-{
-  "mcpServers": {
-    "gmail": {
-      "command": "gmail-mcp",
-      "args": [],
-      "env": {
-        "GMAIL_OAUTH_PATH": "/workspace/extra/.gmail-mcp/gcp-oauth.keys.json",
-        "GMAIL_CREDENTIALS_PATH": "/workspace/extra/.gmail-mcp/credentials.json"
-      }
-    }
-  },
-  "additionalMounts": [
-    {
-      "hostPath": "/home/<user>/.gmail-mcp",
-      "containerPath": ".gmail-mcp",
-      "readonly": false
-    }
-  ]
-}
-```
-
-Substitute `<user>` with the host user's home (use `echo $HOME`, don't assume `~` will expand — `container-runner.ts` does expand `~` via `expandPath`, but an explicit absolute path is clearer and matches what `/manage-mounts` writes).
-
-**Why the container path is relative:** `mount-security` rejects absolute `containerPath` values. Additional mounts are prefixed with `/workspace/extra/`, so `containerPath: ".gmail-mcp"` lands at `/workspace/extra/.gmail-mcp`. The MCP server's `GMAIL_OAUTH_PATH` / `GMAIL_CREDENTIALS_PATH` env vars point at that absolute location inside the container.
-
-## Phase 4: Build and Restart
-
-```bash
-pnpm run build
-systemctl --user restart nanoclaw  # Linux
-# launchctl kickstart -k gui/$(id -u)/com.nanoclaw   # macOS
-```
-
-## Phase 5: Verify
-
-### Test from the wired agent
-
-Tell the user:
-
-> In your `<agent-name>` chat, send: **"list my gmail labels"** or **"search my inbox for invoices from last month"**.
->
-> The agent should use `mcp__gmail__list_labels` / `mcp__gmail__search`. The first call may take a second or two while the MCP server starts and OneCLI does the token exchange.
-
-### Check logs if the tool isn't working
-
-```bash
-tail -100 logs/nanoclaw.log logs/nanoclaw.error.log | grep -iE 'gmail|mcp'
-# Per-container logs — session-scoped:
-ls data/v2-sessions/*/stderr.log | head
-```
-
-Common signals:
-- `command not found: gmail-mcp` → image wasn't rebuilt or PATH doesn't include `/pnpm` (should — `ENV PATH="$PNPM_HOME:$PATH"` in Dockerfile).
-- `ENOENT: no such file or directory, open '/workspace/extra/.gmail-mcp/credentials.json'` → mount is missing. Check `~/.config/nanoclaw/mount-allowlist.json` includes a parent of `~/.gmail-mcp`.
-- `401 Unauthorized` from `gmail.googleapis.com` → OneCLI isn't injecting. Check the agent's secret mode (`onecli agents secrets --id <agent-id>`) and that the Gmail app is connected (`onecli apps get --provider gmail`).
-- Agent says "I don't have Gmail tools" → `mcp__gmail__*` wasn't added to `TOOL_ALLOWLIST`, or the agent-runner wasn't rebuilt (image cache — run `./container/build.sh` again with `--no-cache` if suspicious).
-
-## Removal
-
-1. Delete the `"gmail"` entry from `mcpServers` and the `.gmail-mcp` entry from `additionalMounts` in each group's `container.json`.
-2. Remove `'mcp__gmail__*'` from `TOOL_ALLOWLIST` in `container/agent-runner/src/providers/claude.ts`.
-3. Remove the `GMAIL_MCP_VERSION` ARG and the `pnpm install -g @gongrzhe/server-gmail-autoauth-mcp` block from `container/Dockerfile`.
-4. `pnpm run build && ./container/build.sh && systemctl --user restart nanoclaw`.
-5. (Optional) `rm -rf ~/.gmail-mcp/` if no other host-side tool needs the stubs.
-6. (Optional) Disconnect Gmail in OneCLI: `onecli apps disconnect --provider gmail`.
-
-## Notes
-
-- **Stub format is OneCLI-prescribed.** The `access_token: "onecli-managed"` pattern with `expiry_date: 99999999999999` tells the Google auth client the token is valid; OneCLI intercepts the outgoing Gmail API call and rewrites `Authorization: Bearer onecli-managed` to the real token. `expiry_date: 0` (refresh-interception) is an alternative the OneCLI docs describe — both work but OneCLI's own `migrate` command writes the far-future variant, which is what this skill assumes.
-- **Scopes are set at OAuth connect time.** If the agent needs scopes beyond what's currently connected (e.g. the user later wants `calendar.readonly` for combined email/calendar workflows), disconnect and reconnect Gmail in the OneCLI web UI with the expanded scope set.
-- **This is tool-only.** Inbound email as a channel (emails trigger the agent) is a separate piece of work — it needs a `src/channels/gmail.ts` adapter that polls the inbox and routes to a messaging group. The pre-v2 qwibitai skill had this; it has not been ported to v2's channel architecture as of v2.0.0.
-
-## Credits & references
-
-- **MCP server:** [`@gongrzhe/server-gmail-autoauth-mcp`](https://github.com/GongRzhe/Gmail-MCP-Server) by GongRzhe — MIT-licensed.
-- **OneCLI credential stubs:** pattern documented at `https://onecli.sh/docs/guides/credential-stubs/gmail.md`.
-- **Skill pattern:** modeled on [`add-atomic-chat-tool`](../add-atomic-chat-tool/SKILL.md) and [`add-vercel`](../add-vercel/SKILL.md).
-- **Addresses:** [issue #1500](https://github.com/qwibitai/nanoclaw/issues/1500) (proxy Gmail/Calendar OAuth tokens through credential proxy) for the Gmail side.
-- **Related PRs:** [#1810](https://github.com/qwibitai/nanoclaw/pull/1810) (pre-install Gmail/Notion MCP) overlaps on the "install the MCP server in the image" idea but bundles many unrelated changes; this skill is the focused OneCLI-native version.

package/.claude/skills/add-imessage/REMOVE.md

@@ -1,6 +0,0 @@
-# Remove iMessage Channel
-
-1. Comment out `import './imessage.js'` in `src/channels/index.ts`
-2. Remove iMessage env vars (`IMESSAGE_ENABLED`, `IMESSAGE_LOCAL`, `IMESSAGE_SERVER_URL`, `IMESSAGE_API_KEY`) from `.env`
-3. `pnpm uninstall chat-adapter-imessage`
-4. Rebuild and restart

package/.claude/skills/add-imessage/SKILL.md

@@ -1,113 +0,0 @@
----
-name: add-imessage
-description: Add iMessage channel integration via Chat SDK. Local (macOS) or remote (Photon API) mode.
----
-
-# Add iMessage Channel
-
-Adds iMessage support via the Chat SDK bridge. Two modes: local (macOS with Full Disk Access) or remote (Photon API).
-
-## Install
-
-NanoClaw doesn't ship channels in trunk. This skill copies the iMessage adapter in from the `channels` branch.
-
-### Pre-flight (idempotent)
-
-Skip to **Credentials** if all of these are already in place:
-
-- `src/channels/imessage.ts` exists
-- `src/channels/index.ts` contains `import './imessage.js';`
-- `chat-adapter-imessage` is listed in `package.json` dependencies
-
-Otherwise continue. Every step below is safe to re-run.
-
-### 1. Fetch the channels branch
-
-```bash
-git fetch origin channels
-```
-
-### 2. Copy the adapter
-
-```bash
-git show origin/channels:src/channels/imessage.ts > src/channels/imessage.ts
-```
-
-### 3. Append the self-registration import
-
-Append to `src/channels/index.ts` (skip if the line is already present):
-
-```typescript
-import './imessage.js';
-```
-
-### 4. Install the adapter package (pinned)
-
-```bash
-pnpm install chat-adapter-imessage@0.1.1
-```
-
-### 5. Build
-
-```bash
-pnpm run build
-```
-
-## Credentials
-
-### Local Mode (macOS)
-
-Requirements: macOS with Full Disk Access granted to the Node.js binary.
-
-The Node binary path is buried deep (e.g. `~/.nvm/versions/node/v22.x.x/bin/node`). To make it easy, open the folder in Finder so the user can drag the file into System Settings:
-
-```bash
-open "$(dirname "$(which node)")"
-```
-
-Then tell the user:
-
-1. Open **System Settings** > **Privacy & Security** > **Full Disk Access**
-2. Click **+**, then drag the `node` file from the Finder window that just opened
-3. Toggle it on
-
-Stop and wait for the user to confirm before continuing.
-
-### Remote Mode (Photon API)
-
-1. Set up a [Photon](https://photon.im) account
-2. Get your server URL and API key
-
-### Configure environment
-
-**Local mode** -- add to `.env`:
-
-```bash
-IMESSAGE_ENABLED=true
-IMESSAGE_LOCAL=true
-```
-
-**Remote mode** -- add to `.env`:
-
-```bash
-IMESSAGE_LOCAL=false
-IMESSAGE_SERVER_URL=https://your-photon-server.com
-IMESSAGE_API_KEY=your-api-key
-```
-
-Sync to container: `mkdir -p data/env && cp .env data/env/env`
-
-## Next Steps
-
-If you're in the middle of `/setup`, return to the setup flow now.
-
-Otherwise, run `/manage-channels` to wire this channel to an agent group.
-
-## Channel Info
-
-- **type**: `imessage`
-- **terminology**: iMessage has "conversations." Each conversation is with a contact identified by phone number or email address. Group chats are also supported.
-- **how-to-find-id**: The platform ID is the contact's phone number (e.g. `+15551234567`) or email address. For group chats, the ID is assigned by iMessage internally.
-- **supports-threads**: no
-- **typical-use**: Interactive 1:1 chat — personal messaging
-- **default-isolation**: Same agent group if you're the only person messaging the bot across iMessage and other channels. Separate agent group if different contacts should have information isolation.

package/.claude/skills/add-imessage/VERIFY.md

@@ -1,3 +0,0 @@
-# Verify iMessage Channel
-
-Send an iMessage to the account running NanoClaw. The bot should respond within a few seconds.

package/.claude/skills/add-karpathy-llm-wiki/SKILL.md

@@ -1,110 +0,0 @@
----
-name: add-karpathy-llm-wiki
-description: Add a persistent wiki knowledge base to a NanoClaw group. Based on Karpathy's LLM Wiki pattern. Triggers on "add wiki", "wiki", "knowledge base", "llm wiki", "karpathy wiki".
----
-
-# Add Karpathy LLM Wiki
-
-Set up a persistent wiki knowledge base on NanoClaw, based on Karpathy's LLM Wiki pattern.
-
-## Step 1: Read the pattern
-
-Read `${CLAUDE_SKILL_DIR}/llm-wiki.md` — this is the full LLM Wiki idea as written by Karpathy. Understand it thoroughly before proceeding. Summarize the core idea to the user briefly, then discuss what they want to build.
-
-## Step 2: Choose a group
-
-AskUserQuestion: "Which group should have the wiki?"
-
-1. **Main group** — add to your existing main chat
-2. **Dedicated group** — create a new group just for the wiki
-3. **Other** — pick an existing group
-
-If dedicated: ask which channel and chat, then register with `pnpm exec tsx setup/index.ts --step register`.
-
-## Step 3: Design collaboratively
-
-Discuss with the user based on the pattern:
-- What's the wiki's domain or topic?
-- What kinds of sources will they add? (URLs, PDFs, images, voice notes, books, transcripts)
-- Do they want the full three-layer architecture or a lighter version?
-- Any specific conventions they care about? (The pattern intentionally leaves this open.)
-
-Based on this discussion, create three things:
-
-### 3a. Directory structure
-
-Create `wiki/` and `sources/` directories in the group folder. Create initial `index.md` and `log.md` per the pattern's Indexing and Logging section. Adapt to the user's domain.
-
-### 3b. Container skill
-
-Create a `container/skills/wiki/SKILL.md` tailored to this user's wiki. This is the schema layer from the pattern — it tells the agent how to maintain the wiki. Base it on the pattern's Operations section (ingest, query, lint) and the conventions you agreed on with the user. Don't over-prescribe — the pattern says "your LLM figures out the rest."
-
-### 3c. Group CLAUDE.md
-
-Edit the group's CLAUDE.md to add a wiki section. This is critical — it's what turns the agent into a wiki maintainer. It should:
-
-- Explain the wiki system concisely: what it is, the three layers (sources, wiki, schema), the three operations (ingest, query, lint)
-- Index the key files and folders (`wiki/`, `sources/`, `wiki/index.md`, `wiki/log.md`)
-- Point to the container skill for detailed workflow
-- **Ingest discipline:** Be very explicit that when the user provides multiple files or points at a folder with many files, the agent MUST process them one at a time. For each file: read it, discuss takeaways, create/update all wiki pages (summary, entities, concepts, cross-references, index, log), and completely finish with that file before moving to the next. Never batch-read all files and then process them together — this produces shallow, generic pages instead of the deep integration the pattern requires.
-
-## Step 4: Source handling capabilities
-
-Based on the source types the user plans to ingest (discussed in Step 3), check whether the agent can already handle those formats — some are supported natively, others need a skill (e.g. `/add-image-vision`, `/add-pdf-reader`, `/add-voice-transcription`). If a needed capability isn't installed, check if there's an available skill for it and help the user get it set up.
-
-### URL handling note
-
-claude has built-in `WebFetch`, but it returns a summary, not the full document. For wiki ingestion of a URL where the full text matters, the container skill and CLAUDE.md should instruct claude to use bash commands to download full files instead. For example:
-
-```bash
-curl -sLo sources/filename.pdf "<url>"
-```
-
-If the document is a webpage, then claude can use fetch or `agent-browser` to open the page and extract full text if available. The container skill and CLAUDE.md should note this so claude gets full content for sources rather than summaries.
-
-
-## Step 5: Optional lint schedule
-
-AskUserQuestion: "Want periodic wiki health checks?"
-
-1. **Weekly**
-2. **Monthly**
-3. **Skip** — lint manually
-
-If yes, create a NanoClaw scheduled task that runs in the wiki group. This is NOT a Claude Code cron job — it's a NanoClaw group task that runs in the agent container. Insert it into the SQLite database:
-
-```bash
-pnpm exec tsx -e "
-const Database = require('better-sqlite3');
-const { CronExpressionParser } = require('cron-parser');
-const db = new Database('store/messages.db');
-const interval = CronExpressionParser.parse('<cron-expr>', { tz: process.env.TZ || 'UTC' });
-const nextRun = interval.next().toISOString();
-db.prepare('INSERT INTO scheduled_tasks (id, group_folder, chat_jid, prompt, schedule_type, schedule_value, context_mode, next_run, status, created_at) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?)').run(
-  'wiki-lint',
-  '<group_folder>',
-  '<chat_jid>',
-  'Run a wiki lint pass per the wiki container skill. Check for contradictions, orphan pages, stale content, missing cross-references, and gaps. Report findings and offer to fix issues.',
-  'cron',
-  '<cron-expr>',
-  'group',
-  nextRun,
-  'active',
-  new Date().toISOString()
-);
-db.close();
-"
-```
-
-Use the group's `folder` and `chat_jid` from the registered groups table. Cron expressions: `0 10 * * 0` (weekly Sunday 10am) or `0 10 1 * *` (monthly 1st at 10am).
-
-## Step 6: Build and restart
-
-```bash
-pnpm run build
-./container/build.sh
-launchctl kickstart -k gui/$(id -u)/com.nanoclaw  # macOS
-# Linux: systemctl --user restart nanoclaw
-```
-
-Tell the user to test by sending a source to the wiki group.