ac-openclaw

Imported from souliane/skills (ac-openclaw/SKILL.md). Install upstream with npx skills add souliane/skills --skill ac-openclaw. Copyright stays with the author.

Bootstrap OpenClaw

Interactive, step-by-step guide to install OpenClaw — a self-hosted personal AI assistant that connects to your messaging apps (Signal, WhatsApp, Telegram, Discord, Slack, and 20+ more).

OpenClaw is MIT-licensed and developed in the open at github.com/openclaw/openclaw.

Versions

When running this skill: Web-search for latest versions first. OpenClaw releases daily. signal-cli and Node.js update less frequently.

signal-cli < 0.14.5 is a silent, write-only outage — never install one. Below the floor, inbound 1:1 messages are dropped with no error the user would notice, while outbound sending keeps working perfectly. The assistant looks alive and answers cron jobs; it just never hears you. Verify signal-cli --version after install and send yourself an inbound message as an end-to-end check — an outbound-only test cannot detect this.

Installing

npm i openclaw@2.0 fails — no 2.x exists on npm. The "2.0" branding sits on top of the CalVer scheme; the installable version is 2026.8.1.

Install with the scripts flag on npm >= 11.16 — without it the bundled plugins are silently skipped:

npm i -g openclaw@2026.8.1 --allow-scripts=openclaw   # npm >= 11.16
npm i -g openclaw@2026.8.1                            # npm <= 11.15 — the flag does not exist

Upgrading an existing instance has its own blockers (config validates fail-closed, Signal is a separate plugin, an OpenRouter key triggers an uninstallable plugin). Follow references/upgrading.md rather than running npm i -g on a live box.

Dependencies

Standalone. No dependencies on other skills.

Example Values — Always Use Placeholders (Non-Negotiable)

When authoring documentation, troubleshooting entries, command examples, or config snippets in this skill, never paste a real phone number, email, UUID, token, hostname, file path, or other personally identifying value from a live system — even as "throwaway context" to illustrate a bug. Copy-paste from a live VPS or a real pass entry is how real values end up in examples.

Use well-known placeholders instead:

Before merging any change to this skill (or to any reference under references/), grep the diff for the Streisand-effect and PII patterns in rules/SKILL.md § "Leak Remediation — Silent Scrubs" and retro/SKILL.md § "Privacy Scan". If a real value slipped into an example, rewrite to a placeholder before push — do NOT ship the diff and scrub later. Post-merge remediation on a public repo is irreversible and amplifies the leak.

Why OpenClaw (vs. ChatGPT / Gemini directly)

Talking to OpenClaw on Signal feels the same as messaging ChatGPT — until you configure what makes it different:

To get value beyond "just another chatbot", configure at least one of:

• Press Review — daily aggregated tech/AI news digest delivered to your messaging channel. Ships ready-to-use with this skill (60-second install, see references/press-review.md).
• Heartbeat — proactive monitoring (email triage, calendar reminders)
• Cron jobs — scheduled automation (weekly backup reports, daily standup prompts, etc.)
• Multi-agent routing — different personalities for different contacts (references/multi-agent-routing.md)
• Tool integrations — Gmail, Calendar, GitHub, Obsidian, Home Assistant

Without these, OpenClaw is indeed just a passthrough to an LLM API. The value is in the integrations and automation.

When NOT to Use

• User wants to install a different AI assistant (not OpenClaw)
• User already has OpenClaw running and needs help with a routine configuration change (docs.openclaw.ai is faster). Upgrades of an existing instance are in scope — see references/upgrading.md
• User wants a managed/hosted OpenClaw (point them to ClawHost or similar)

Compatibility

This skill is designed to work with any AI coding agent:

• Use the agent's native interactive questioning mechanism (e.g., AskUserQuestion in Claude Code, inline prompts in Codex/Copilot/Gemini CLI/Cursor).

The key rule is: ask one question at a time, wait for the answer, then proceed.

Workflow Overview

 1. Gather requirements (server, model, channels, security)
 2. Plan (present full plan, get approval)
 3. Provision server (or confirm local machine)
 4. Harden OS
 5. Install OpenClaw
 6. Configure model provider
 7. Set up secure remote access (Tailscale or Caddy)
 8. Connect messaging channels
 9. Post-install hardening & verification
10. Social media integrations (optional)
11. Additional integrations & next steps
11a. Press Review — daily news digest (optional, 60-second install)
12. Wrap up + suggest retrospective to self-improve this skill

Cardinal rule: Ask ONE question at a time. Never dump a wall of questions. Wait for the user's answer before proceeding.

Phase 1: Gather Requirements

Ask these questions one at a time, in order. Use the agent's native interactive questioning tool. Provide sensible defaults based on cached data in references/.

1.1 Where will OpenClaw run?

Where will OpenClaw be installed?

a) Remote VPS (I'll provision a new server)          [DEFAULT]
b) Remote VPS (I already have a server — I'll give SSH access)
c) This machine (the one running the AI agent)

• If (a): proceed to 1.2 (server provider).

• If (b): ask for SSH connection details. Password MUST be stored in pass (the standard Unix password manager). Never accept copy-pasted passwords in chat. Guide:

  # User stores the password:
  pass insert servers/openclaw-vps
  # Agent retrieves it when needed:
  pass show servers/openclaw-vps

  Then ask for: hostname/IP, SSH port (default 22), username (default root).

• If (c): confirm OS (uname -a), skip server provisioning, go to Phase 3.

1.2 Server provider

Which VPS provider? (or will you use a local machine?)

a) No preference — recommend one for my requirements          [DEFAULT]
b) A provider I already have an account with (I'll name it)
c) Local machine (skip provisioning)

This skill is provider-agnostic. Do not open with a hardcoded shortlist — the right box depends on the sizing answer in § 1.4 and on jurisdiction, and the market moves monthly.

• Always web-search for current pricing before recommending anything: "<provider> VPS pricing <year>", then fetch each candidate's number from the vendor's own page. A cached price is a lead, not a quote.
• Read references/provider-selection.md first. It carries the durable method (normalize VAT before comparing; existence ≠ availability; read the CPU from the vendor's announcement, not the plan name; latency is almost never the axis; decide jurisdiction before price) and re-verify every price against the vendor's own page.
• references/hetzner-servers.md is one cached provider among several, not the default. Use it if the user picks Hetzner; it is still accurate for the CAX line, subject to the availability check below.
• If the user names a provider not covered by either reference, research it dynamically and apply the same method.
• If local machine: skip to 1.4.

1.3 Server location

Where do you live? (determines closest datacenter for low latency)

Do NOT present a hardcoded list of datacenters. Instead:

• If the provider was already determined (1.2), web-search for their available regions and present the closest options to the user's location.
• If the provider has cached data in references/ (Hetzner, or the snapshot in references/provider-selection.md), use that as a starting point and re-verify.
• For any other provider, research dynamically.
• Latency is almost never the decisive axis for a messaging assistant — see references/provider-selection.md § 5. If the user is operating under a data-processing agreement, jurisdiction outranks distance; settle that first (§ 6 there).

1.4 Model strategy

This is critical — it determines server sizing. Present the cost comparison FIRST, then ask.

Key insight: for a personal messaging bot, paid API is almost always cheaper AND better than self-hosting a model. Make this case clearly:

This table sizes the ASSISTANT ONLY — it is not the size of the box. See § 1.4a before recommending anything. If the host will also run agent orchestration, this table will undersize it, and the failure mode is an OOM killer picking victims months later.

WARNING: The "Server RAM" column for local models is the MINIMUM for the model to load. In practice, Ollama needs significantly more RAM for the KV cache during inference — an 8B model with OpenClaw's full context window (system prompt + SOUL.md + conversation history) can require ~20 GB, not the ~5-6 GB that model weights alone suggest. Always budget 2-3x the model weight size for actual inference.

Bottom line: the smallest 4 GB box plus a free-tier or low-single-digit-dollars API gives you frontier-quality models for less than a mediocre local model on an expensive server. Self-hosting only makes sense for privacy absolutists or offline use.

Reference: See OpenClaw Deploy Cost Guide for detailed cost breakdowns.

Free tiers move constantly — fetch each candidate's current limits from the vendor's own page before recommending one. Two things decide whether a free tier is usable for a personal messaging bot:

• Requests per day — a personal bot sends tens to low hundreds of turns a day. A daily cap in the hundreds is comfortable; a cap in the tens is not.
• Requests per minute — a single-digit RPM limit throttles a normal back-and-forth conversation and is unusable regardless of how generous the daily cap looks.

Google's Gemini Flash line is the usual candidate that clears both bars. Verify rather than assume, and treat a paid tier at a few dollars a month as the fallback — it is cheaper than sizing a server for a local model.

Then ask:

For a personal messaging bot, a paid API on a small cheap server gives
better quality for less money than self-hosting a model on a big server.

How will you provide the AI model?

a) BYOK — API Key only (cheapest server, best models)          [DEFAULT]
   → a free tier that clears the RPM/RPD bars above, or paid at ~$1-5/mo
b) BYOK + local Ollama fallback (needs more RAM for fallback)
   → Best of both but server costs more
c) Local model only (needs expensive server, lower quality)
   → Only recommended for privacy/offline requirements

If local model chosen: The sizing table above shows minimum RAM for weights only. For actual inference with OpenClaw's context, multiply by 2-3x. Web-search for current Ollama memory requirements before recommending a server size.

If using OpenRouter (BYOK or credits) — cost-safety, set at configuration time: OpenRouter routes each model across many providers at very different prices and, by default, falls back to a provider you did not pick — including a pay-per-token one billed to your credits — if your chosen provider fails. Set two guardrails up front, not after a surprise bill: (1) pin routing with provider: {"only": [<slugs>], "sort": "price"} under models.providers.openrouter.params.provider so a failure errors out instead of escalating to a pricier provider; (2) set a per-key spend cap at openrouter.ai/settings/keys (keys have no limit by default; the cap can reset daily/weekly/monthly, and an "Include BYOK in limit" toggle decides whether your own-key usage counts toward it) — the one guardrail that holds no matter how the routing is configured. For full-precision weights, also add a quantizations allow-list to the same provider block (see troubleshooting). Full details + the BYOK "Always use for this provider" gotcha live in references/troubleshooting-and-maintenance.md (§ "OpenRouter credits can drain").

Provider resize note: When recommending a server size, inform the user whether the provider supports upgrade/downgrade without reinstalling. This reduces decision anxiety — the user isn't locked in. For Hetzner: "Hetzner supports both upgrades and downgrades from the console or CLI. It requires a brief restart (~1 minute) but no data loss or reinstallation. You can start with CAX21 and downgrade to CAX11 later if you don't need the RAM." For other providers: web-search for their resize policy.

Instance availability note: A provider will publish current prices for a plan it cannot sell you — existence is not availability, and ARM lines are the usual offender. Before recommending a server type + location, read the provider's availability set rather than its catalogue (with hcloud: hcloud server-type describe cax21, and compare supported vs available on the datacenter). Then:

1. Try another datacenter in the same country (e.g., fsn1 instead of nbg1 — both in Germany, negligible latency difference)
2. Use the next closest region (e.g., Helsinki for a European user — adds ~20-30ms, imperceptible for a messaging bot)
3. If capacity has never appeared, pick a different plan — do not park the install behind a restock

On (3): an entire ARM line has been observed listed and priced but unavailable in every datacenter, with a stock watcher polling every 30 minutes for four months and never once firing. A stock watcher that has never fired is a "no", not "waiting". Full detail in references/provider-selection.md § 3.

Confirmation step (when local model + small server): If the user chose option (b) or (c) and the server has ≤ 8 GB RAM, explicitly confirm the specific model before moving on. Example for 4 GB:

On CAX11 (4 GB RAM), the only local model that fits is Qwen 3 4B (~3 GB).
It handles basic Q&A but has limited reasoning — serviceable as a fallback
when your BYOK provider is down or rate-limited.

Install Ollama with Qwen 3 4B as your local fallback? (yes/no)
If no: we can skip Ollama or upgrade the server (CAX21 = 8 GB, ~7-8 EUR/mo → 8B models).

Do NOT silently move on after the user picks a model strategy. The user must confirm what will actually be installed.

1.4a Size the HOST, not the assistant

The § 1.4 table sizes OpenClaw itself (~1.5 GB resident for a BYOK gateway). That is the whole box only if the box does nothing else. Sizing a shared host from the assistant's footprint is what undersized a real server — ask before you recommend:

Will anything else run on this box alongside OpenClaw?

a) Nothing — OpenClaw only                                    [DEFAULT]
b) Agent orchestration / CI-shaped work (test suites, builds,
   headless browsers) triggered by me or by the assistant
c) Other services I'll describe

If (b): budget 3–6 GB per concurrent job and size for PEAK CONCURRENCY. The jobs that actually eat a box:

Two agents each running a build and a browser is 16–20 GB before the assistant, the OS, and Docker. A 4 GB box that is "right" for the assistant is wrong for the host by a factor of five. Ask for the maximum number of jobs the user expects to run at once, multiply, then add the § 1.4 figure and ~1–2 GB for OS + Docker.

Measure, don't assume — and read the victims

If the user already has a box (§ 1.1b) or is resizing one, get the evidence before quoting a size:

sudo journalctl -k --grep="Out of memory" --since "30 days ago" | tail -30

Read the victim lines, not just the count. The process the kernel kills is usually not the one that filled the memory. A small always-on component — the gateway, a health check — dies because something bursty next to it exhausted the box. Sizing against that victim buys a machine tuned for the wrong workload entirely. Work out what was allocating at the time of each kill, and size for that instead.

More RAM makes a kill rarer; it does not choose who dies

OOM priority is a separate decision from capacity, and it must be made explicitly. Protect the always-on gateway and nominate the bursty consumer as the victim:

# /etc/systemd/system/openclaw.service.d/oom.conf — protect the gateway
[Service]
OOMScoreAdjust=-500

# the orchestration/CI service — make it the preferred victim, and throttle it first
[Service]
OOMScoreAdjust=500
MemoryHigh=<n>G     # soft-throttle before the kernel has to kill anything
MemoryMax=<n>G

A POSITIVE OOMScoreAdjust makes a process the PREFERRED VICTIM. The sign is easy to get backwards — a value of 800 on the gateway itself has been found in the wild, which tells the kernel to kill the assistant first, ahead of whatever is actually consuming the RAM. Protect with a negative value; sacrifice with a positive one.

Configure this even on a generously sized box. On any box the OOM killer eventually chooses — this is how you choose for it.

1.5 OpenClaw capabilities — tool use

This question affects server sizing (Docker overhead) and security (sandboxing). Ask it before channels and security.

What will you use OpenClaw for?

a) Chat only — text conversations via messaging apps              [DEFAULT]
   → No special requirements.

b) Chat + tools — shell commands, code execution, file operations
   → Docker sandboxing strongly recommended for safety.
   → Adds ~200-500 MB RAM overhead (tight on 4 GB with Ollama).

c) Chat + tools + agents — autonomous multi-step tasks
   → Docker sandboxing required. More RAM headroom recommended.

If (b) or (c): Flag the RAM constraint if using Ollama on a small server. Docker daemon + containers consume ~200-500 MB. On CAX11 (4 GB) already running Ollama (~3 GB), sandboxing may not fit — warn the user and suggest either dropping Ollama or upgrading the server.

Carry the answer forward to § 1.7 (security) — Docker sandboxing recommendation adapts based on tool-use intent.

1.6 Which messaging channels?

These are for private two-way chat with your assistant (like texting a friend). Not social media posting.

Which messaging channel do you want to connect?

Recommended (ranked by privacy):
a) Signal          — E2E encrypted, open source                          [DEFAULT]
   ⚠️ Requires a DEDICATED phone number (registering de-auths your main Signal app)
b) Telegram        — easiest setup (bot token from @BotFather), no phone needed
c) WhatsApp        — E2E encrypted, needs real mobile number, Meta-owned
d) Matrix          — E2E encrypted, self-hosted, decentralized (plugin)

Also available:
e) Discord         (bot token + gateway intents, no E2E)
f) Slack           (workspace app, no E2E)
g) iMessage        (BlueBubbles, macOS server required)
h) IRC, Microsoft Teams, Google Chat, LINE, Mattermost, and more (plugins)

Which one? (start with one, you can add more later)

Suggest starting with ONE channel. Get it working first, then add more if needed.

For each selected channel, the skill will guide setup in Phase 8. See references/channel-setup.md for cached setup details.

1.7 Security preferences

Principle: default to maximum security. Present the most secure setup as the default. If a security measure doesn't fit the user's situation (e.g., RAM constraints), explain clearly why you're suggesting to disable it, what the trade-offs are, and what risk the user accepts.

Present the full default security stack:

Here's what will be enabled by default:

- UFW firewall (only ports 22, 80, 443)
- Fail2Ban for SSH brute-force protection
- SSH key-only auth (password auth disabled)
- Unattended security updates
- OpenClaw bound to localhost + reverse proxy for remote access
- Non-root user for OpenClaw
- Docker sandboxing for tool execution (isolates shell/code in containers)
- Custom SSH port (2222) to reduce bot noise

Any of these you'd like to change? (or Enter to proceed with all defaults)

Then adapt based on context — explain trade-offs honestly when suggesting a downgrade:

• If chat-only (§ 1.5a): "Docker sandboxing is included by default, but since you chose chat-only (no tools/code execution), there's nothing to sandbox right now. Removing it saves ~200-500 MB RAM and reduces complexity. You can always add it later if you enable tools. Want to skip Docker sandboxing for now?"

• If tools/agents (§ 1.5b/c) on a small server with Ollama: "Docker sandboxing is critical for your setup — it prevents a misbehaving tool or prompt injection from damaging your server. However, on CAX11 (4 GB) with Ollama already using ~3 GB, Docker's ~200-500 MB overhead makes it very tight. Options: (a) keep sandboxing and drop Ollama, (b) keep both and risk OOM under load, (c) upgrade to CAX21 (8 GB, ~7-8 EUR/mo) to fit everything comfortably. Which do you prefer?"

• If tools/agents on a server with enough RAM: Keep Docker sandboxing enabled, no downgrade needed.

Additional options (only if user asks):

• Disk encryption (LUKS) — strongest data-at-rest protection, but adds complexity: requires dropbear-initramfs for remote unlock after every reboot. Recommend only for high-sensitivity data.

1.8 Remote access to the web dashboard

The user needs to know how they'll access the OpenClaw dashboard from their phone/laptop. This choice affects the plan (domain needed? Cloudflare account? Tailscale on all devices?). Ask it now, execute it in Phase 7.

Set-and-forget guarantee: Reassure the user that whichever method they choose, it runs as a systemd service. Once installed, the server just runs — no manual reverse proxy, no SSH tunnel each time, no port forwarding. Open a URL and you're in.

How do you want to access the OpenClaw web dashboard from your phone/laptop?
All options run as permanent background services — once set up, there's
nothing to do. Just open the URL.

a) Cloudflare Tunnel + Zero Trust (recommended)
   → Access from any browser/phone, no app install needed
   → Free. Requires a domain name + Cloudflare account
   → Auth via Google/GitHub/email OTP before reaching the dashboard

b) Tailscale Serve (most secure)
   → Private mesh network, zero public exposure
   → Free. BUT: requires Tailscale app on EVERY device (laptop, phone)
   → ⚠️ May conflict with existing VPNs (WireGuard, etc.) — ask the user first
   → Best if you're already a Tailscale user or have no other VPN

c) Caddy reverse proxy + password (simplest)
   → Direct HTTPS with Let's Encrypt, password-protected
   → Requires a domain name. No extra accounts needed
   → Less secure: password-only auth, exposed to internet

If the user chose Tailscale, immediately ask about existing VPNs:

Do you have any other VPN running on your devices (WireGuard, OpenVPN,
corporate VPN, etc.)?

Tailscale can conflict with other VPNs — especially WireGuard-based ones.
They compete for the macOS/iOS network extension slot and may block each
other's traffic. On Linux/Android it's less problematic.

If yes: you'll need to avoid running both simultaneously. Toggle one off
before using the other. If that's a dealbreaker, consider Cloudflare
Tunnel (option a) instead — it doesn't require a VPN app on your devices.

Carry the answer forward to Phase 7 for execution.

Phase 2: Present the Plan

Enter plan mode if not already active (Phase 1 is read-only questions — plan mode should be active from the start). After gathering all answers, present a complete plan:

## Installation Plan

**Server:** <provider> <instance type> (<vCPU>, <RAM>, <SSD>) in <location>
**OS:** Ubuntu 24.04 LTS (<arch>)
**Model:** <BYOK provider or Ollama model>
**Capabilities:** <chat-only / tools / tools + agents>
**Channels:** <chosen channel(s)>
**Security:** UFW + Fail2Ban + SSH keys + unattended-upgrades <+ Docker sandboxing if tools>
**Remote access:** <chosen method from § 1.8> (runs as systemd service — set and forget)
**Estimated cost:** <server cost/mo> + <API usage if BYOK>

Steps:
1. Provision server (or connect to existing / confirm local)
2. Initial OS setup (user, SSH keys, firewall)
3. Install Node.js 24 + OpenClaw
4. Configure model provider
5. Set up secure remote access
6. Connect messaging channel(s)
7. Run security audit
8. Test end-to-end

Proceed? (yes/no)

Exit plan mode for user approval. If the user wants changes, re-enter plan mode, adjust, and re-present.

Phases 3–12: Installation & Configuration

Detailed step-by-step instructions for each phase live in reference files. Load them as you reach each phase — don't front-load everything into context.

Upgrading an existing instance is not one of these phases — it has its own runbook (pre-flight, upgrade, config migration, verification, rollback) in references/upgrading.md.

Key rules for all phases:

• Fetch OpenClaw docs before Phase 5 (see § When Using This Skill below)
• Store every generated secret in pass immediately — gateway tokens, API keys, passwords
• Set gateway.mode and allowedOrigins before starting the gateway (Phase 5.3)
• Warn about device pairing before the user opens the dashboard (Phase 5.5)
• Always recommend dedicated prepaid SIM for Signal — never use a personal number

Troubleshooting, Common Mistakes & Sources

See references/troubleshooting-and-maintenance.md for common mistakes, troubleshooting quick reference, offline/online usage guidance, and source URLs.