* refactor: migrate setup from bash scripts to cross-platform Node.js modules Replace 9 bash scripts + qr-auth.html with a two-phase setup system: a bash bootstrap (setup.sh) for Node.js/npm verification, and TypeScript modules (src/setup/) for everything else. Resolves cross-platform issues: sed -i replaced with fs operations, sqlite3 CLI replaced with better-sqlite3, browser opening made cross-platform, service management supports launchd/ systemd/WSL nohup fallback, SQL injection prevented with parameterized queries. Add Linux systemctl equivalents alongside macOS launchctl commands in 8 skill files and CLAUDE.md. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * fix: setup migration issues — pairing code, systemd fallback, nohup escaping - Emit WhatsApp pairing code immediately when received, before polling for auth completion. Previously the code was only shown in the final status block after auth succeeded — a catch-22 since the user needs the code to authenticate. (whatsapp-auth.ts) - Add systemd user session pre-check before attempting to write the user-level service unit. Falls back to nohup wrapper when user-level systemd is unavailable (e.g. su session without login/D-Bus). (service.ts) - Rewrite nohup wrapper template using array join instead of template literal to fix shell variable escaping (\\$ → $). (service.ts) Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * fix: detect stale docker group and kill orphaned processes on Linux systemd * fix: remove redundant shell option from execSync to fix TS2769 execSync already runs in a shell by default; the explicit `shell: true` caused a type error with @types/node which expects string, not boolean. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * feat: hide QR browser auth option on headless Linux Emit IS_HEADLESS from environment step and condition SKILL.md to only show pairing code + QR terminal when no display server is available (headless Linux without WSL). WSL is excluded from the headless gate because browser opening works via Windows interop. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
3.9 KiB
3.9 KiB
name, description
| name | description |
|---|---|
| customize | Add new capabilities or modify NanoClaw behavior. Use when user wants to add channels (Telegram, Slack, email input), change triggers, add integrations, modify the router, or make any other customizations. This is an interactive skill that asks questions to understand what the user wants. |
NanoClaw Customization
This skill helps users add capabilities or modify behavior. Use AskUserQuestion to understand what they want before making changes.
Workflow
- Understand the request - Ask clarifying questions
- Plan the changes - Identify files to modify
- Implement - Make changes directly to the code
- Test guidance - Tell user how to verify
Key Files
| File | Purpose |
|---|---|
src/index.ts |
Orchestrator: state, message loop, agent invocation |
src/channels/whatsapp.ts |
WhatsApp connection, auth, send/receive |
src/ipc.ts |
IPC watcher and task processing |
src/router.ts |
Message formatting and outbound routing |
src/types.ts |
TypeScript interfaces (includes Channel) |
src/config.ts |
Assistant name, trigger pattern, directories |
src/db.ts |
Database initialization and queries |
src/whatsapp-auth.ts |
Standalone WhatsApp authentication script |
groups/CLAUDE.md |
Global memory/persona |
Common Customization Patterns
Adding a New Input Channel (e.g., Telegram, Slack, Email)
Questions to ask:
- Which channel? (Telegram, Slack, Discord, email, SMS, etc.)
- Same trigger word or different?
- Same memory hierarchy or separate?
- Should messages from this channel go to existing groups or new ones?
Implementation pattern:
- Create
src/channels/{name}.tsimplementing theChannelinterface fromsrc/types.ts(seesrc/channels/whatsapp.tsfor reference) - Add the channel instance to
main()insrc/index.tsand wire callbacks (onMessage,onChatMetadata) - Messages are stored via the
onMessagecallback; routing is automatic viaownsJid()
Adding a New MCP Integration
Questions to ask:
- What service? (Calendar, Notion, database, etc.)
- What operations needed? (read, write, both)
- Which groups should have access?
Implementation:
- Add MCP server config to the container settings (see
src/container-runner.tsfor how MCP servers are mounted) - Document available tools in
groups/CLAUDE.md
Changing Assistant Behavior
Questions to ask:
- What aspect? (name, trigger, persona, response style)
- Apply to all groups or specific ones?
Simple changes → edit src/config.ts
Persona changes → edit groups/CLAUDE.md
Per-group behavior → edit specific group's CLAUDE.md
Adding New Commands
Questions to ask:
- What should the command do?
- Available in all groups or main only?
- Does it need new MCP tools?
Implementation:
- Commands are handled by the agent naturally — add instructions to
groups/CLAUDE.mdor the group'sCLAUDE.md - For trigger-level routing changes, modify
processGroupMessages()insrc/index.ts
Changing Deployment
Questions to ask:
- Target platform? (Linux server, Docker, different Mac)
- Service manager? (systemd, Docker, supervisord)
Implementation:
- Create appropriate service files
- Update paths in config
- Provide setup instructions
After Changes
Always tell the user:
# Rebuild and restart
npm run build
# macOS:
launchctl unload ~/Library/LaunchAgents/com.nanoclaw.plist
launchctl load ~/Library/LaunchAgents/com.nanoclaw.plist
# Linux:
# systemctl --user restart nanoclaw
Example Interaction
User: "Add Telegram as an input channel"
- Ask: "Should Telegram use the same @Andy trigger, or a different one?"
- Ask: "Should Telegram messages create separate conversation contexts, or share with WhatsApp groups?"
- Create
src/channels/telegram.tsimplementing theChannelinterface (seesrc/channels/whatsapp.ts) - Add the channel to
main()insrc/index.ts - Tell user how to authenticate and test