Intermediate

// ~/.openclaw/openclaw.json
{
  channels: {
    telegram: {
      enabled: true, // => Activates Telegram channel
      // => Gateway connects on start
      botToken: "${TELEGRAM_BOT_TOKEN}",
      // => From @BotFather on Telegram
      // => Format: "123456789:ABCdefGHIjklMNO..."
      dmPolicy: "pairing", // => "pairing": requires user approval
      // => "open": anyone can DM the bot
      // => "closed": DMs disabled
      allowFrom: [
        "tg:123456789", // => Whitelist by Telegram user ID
        // => Only these users can interact
        "tg:987654321", // => Multiple users supported
      ],
    },
  },
}

openclaw gateway restart                # => Reconnects with Telegram config
                                        # => Output: "Telegram channel connected"
                                        # => Bot now responds to allowed users

// ~/.openclaw/openclaw.json
{
  channels: {
    slack: {
      enabled: true, // => Activates Slack channel
      botToken: "${SLACK_BOT_TOKEN}", // => From Slack App settings
      // => Starts with "xoxb-"
      // => Requires scopes: chat:write, channels:history
      appToken: "${SLACK_APP_TOKEN}", // => Socket mode token
      // => Starts with "xapp-"
      // => Enables WebSocket connection (no public URL needed)
      activation: "mention", // => "mention": responds when @mentioned
      // => "always": responds to every message in channel
      // => "mention" recommended for shared channels
      allowChannels: [
        "#dev-ai", // => Only respond in these channels
        "#ops-alerts", // => Prevents noise in unrelated channels
      ],
    },
  },
}

// ~/.openclaw/openclaw.json
{
  channels: {
    discord: {
      enabled: true, // => Activates Discord channel
      botToken: "${DISCORD_BOT_TOKEN}", // => From Discord Developer Portal
      // => Bot > Token section
      activation: "mention", // => Responds when @mentioned
      // => "always" for dedicated bot channels
      allowGuilds: [
        "1234567890", // => Discord server (guild) ID
        // => Restricts bot to specific servers
      ],
      allowChannels: [
        "ai-assistant", // => Channel names (not IDs) where bot responds
        "dev-help", // => Ignored in other channels even if mentioned
      ],
    },
  },
}

// ~/.openclaw/openclaw.json
{
  channels: {
    whatsapp: {
      enabled: true, // => Activates WhatsApp channel
      provider: "meta-cloud", // => "meta-cloud": Meta's official Cloud API
      // => "whatsapp-web": local browser bridge (unofficial)
      phoneNumberId: "${WA_PHONE_ID}", // => From Meta Business Suite
      accessToken: "${WA_ACCESS_TOKEN}", // => Meta Cloud API access token
      verifyToken: "${WA_VERIFY_TOKEN}", // => Webhook verification token (you choose)
      webhookUrl: "https://your-domain.com/webhook/whatsapp",
      // => Public URL for Meta to send messages to
      // => Requires HTTPS (use ngrok for development)
      allowFrom: [
        "+1234567890", // => Phone numbers allowed to interact
        "+0987654321", // => E.164 format required
      ],
    },
  },
}

// ~/.openclaw/openclaw.json
{
  channels: {
    signal: {
      enabled: true, // => Activates Signal channel
      signalCliBin: "/usr/local/bin/signal-cli",
      // => Path to signal-cli binary
      // => Install: brew install signal-cli (macOS)
      phoneNumber: "+1234567890", // => Signal phone number for the bot
      // => Must be registered with Signal
      allowFrom: [
        "+0987654321", // => Allowed contacts (E.164 format)
      ],
    },
  },
}

# Register signal-cli first (one-time setup):
signal-cli -u +1234567890 register     # => Sends verification SMS
signal-cli -u +1234567890 verify 123456 # => Completes registration
openclaw gateway restart                # => Connects to Signal via signal-cli

// ~/.openclaw/openclaw.json
{
  agents: {
    defaults: {
      model: {
        primary: "anthropic/claude-sonnet-4-6",
        // => Global default: balanced cost/quality
      },
    },
  },
  channels: {
    telegram: {
      enabled: true,
      botToken: "${TELEGRAM_BOT_TOKEN}",
      model: {
        primary: "anthropic/claude-haiku-4-5",
        // => Override: fast and cheap for Telegram
        // => Good for quick queries on mobile
      },
    },
    slack: {
      enabled: true,
      botToken: "${SLACK_BOT_TOKEN}",
      appToken: "${SLACK_APP_TOKEN}",
      model: {
        primary: "anthropic/claude-opus-4-6",
        // => Override: highest quality for Slack
        // => Team channel gets best model
      },
    },
  },
}

// ~/.openclaw/openclaw.json
{
  channels: {
    // Pattern 1: Private assistant (single user)
    telegram: {
      enabled: true,
      botToken: "${TELEGRAM_BOT_TOKEN}",
      dmPolicy: "closed", // => No new DM conversations allowed
      allowFrom: ["tg:MY_USER_ID"], // => Only your Telegram ID
      // => Maximum restriction: one user only
    },
 
    // Pattern 2: Team assistant (approved members)
    slack: {
      enabled: true,
      botToken: "${SLACK_BOT_TOKEN}",
      appToken: "${SLACK_APP_TOKEN}",
      activation: "mention", // => Must @mention to activate
      allowChannels: ["#dev-ai"], // => Only responds in specific channel
      // => Team members in channel can use it
    },
 
    // Pattern 3: Public bot (open access, limited tools)
    discord: {
      enabled: true,
      botToken: "${DISCORD_BOT_TOKEN}",
      activation: "mention", // => Must @mention to activate
      allowGuilds: ["SERVER_ID"], // => Restricted to one server
      // => But anyone in server can use it
    },
  },
 
  // Complement channel access with tool restrictions
  tools: {
    allow: ["web_search", "web_fetch"], // => Safe tools only for open channels
    deny: ["exec", "group:fs"], // => No shell or file access
    // => Prevents abuse from public channels
  },
}

~/.openclaw/workspace/skills/
└── code-review/
    ├── SKILL.md                        # => Main skill instructions
    ├── style-guide.md                  # => Coding standards reference
    ├── review-checklist.md             # => Checklist template
    └── common-issues.md                # => Known anti-patterns database

# ~/.openclaw/workspace/skills/code-review/SKILL.md
 
---
 
name: code_review
description: Reviews code against team coding standards and common issue patterns
 
---
 
# Code Review Skill
 
When reviewing code, reference these files in your workspace:
 
- **style-guide.md**: Team coding standards (naming, formatting, patterns)
- **review-checklist.md**: Step-by-step review process
- **common-issues.md**: Known anti-patterns to flag
 
## Process
 
1. Read the code to review (user provides file or diff)
2. Check against style-guide.md standards
3. Walk through review-checklist.md items
4. Flag any matches from common-issues.md
5. Format findings as actionable review comments # => Agent reads companion files for context # => Files loaded from same skill directory # => Updates to reference files hot-reload

# ~/.openclaw/workspace/skills/deploy/SKILL.md
 
---
 
name: deploy_assistant
description: Assists with deployment tasks across staging and production environments
metadata:
openclaw:
commands: - name: deploy-staging
description: Deploy to staging environment - name: deploy-prod
description: Deploy to production (requires confirmation)
 
---
 
# Deploy Assistant Skill
 
## When /deploy-staging is triggered:
 
1. Run `git status` to check for uncommitted changes
2. Run `npm run build` to create production build
3. Run `npm run deploy:staging` to deploy
4. Report build output and deployment URL # => Staging: no confirmation needed # => Fast feedback loop for testing
 
## When /deploy-prod is triggered:
 
1. Run `git status` to check for uncommitted changes
2. **STOP and ask user for explicit confirmation**: "You are about to deploy to PRODUCTION. Type 'confirm' to proceed."
3. Only after receiving "confirm": run `npm run build && npm run deploy:prod`
4. Report build output, deployment URL, and rollback instructions # => Production: mandatory confirmation gate # => Never auto-deploy to production
 
## Rules
 
- NEVER deploy to production without explicit user confirmation
- NEVER deploy with uncommitted git changes
- Always show the git diff summary before deploying

# ~/.openclaw/workspace/skills/health-monitor/SKILL.md
 
---
 
name: health_monitor
description: Monitors service health endpoints and reports status
metadata:
openclaw:
requires:
tools: ["exec", "web_fetch"]
env: ["MONITOR_TARGETS"] # => Skill requires this env var # => Gateway skips skill if var unset
 
---
 
# Health Monitor Skill
 
Monitor the services listed in $MONITOR_TARGETS environment variable.
 
## Instructions
 
1. Parse $MONITOR_TARGETS as comma-separated URLs
   - Example: "https://api.example.com/health,https://web.example.com/ping"
2. Use web_fetch to check each endpoint
3. Report status for each:
   - ✓ Healthy (200 OK, response < 2s)
   - ⚠ Degraded (200 OK, response > 2s)
   - ✗ Down (non-200 or timeout)
4. If any service is down, recommend checking logs with:
   `exec: docker logs <service-name> --tail 50`

# Set environment variable before starting gateway
export MONITOR_TARGETS="https://api.example.com/health,https://web.example.com/ping"
openclaw gateway restart                # => Gateway resolves env vars
                                        # => health_monitor skill activates
                                        # => $MONITOR_TARGETS available to skill

# ~/.openclaw/workspace/skills/incident-response/SKILL.md
 
---
 
name: incident_response
description: Orchestrates incident response workflow using other skills
metadata:
openclaw:
commands: - name: incident
description: Start incident response workflow
 
---
 
# Incident Response Skill
 
When /incident is triggered with a description of the issue:
 
## Phase 1: Diagnosis
 
Use the **health_monitor** skill to check all service endpoints.
Use the **log_analyzer** skill to scan recent logs for errors. # => References other skills by name # => Agent activates them in sequence # => Each skill runs independently
 
## Phase 2: Communication
 
Use the **message** tool to post incident status to #ops-alerts Slack channel:
 
- Include: affected services, error summary, estimated scope
- Format as incident template # => Cross-channel notification
 
## Phase 3: Documentation
 
Create an incident report file with:
 
- Timeline of events
- Affected services (from Phase 1)
- Error logs (from Phase 1)
- Actions taken
  Save to `incidents/YYYY-MM-DD-incident.md` # => Persistent record for postmortem

# ~/.openclaw/workspace/skills/api-docs/SKILL.md
 
---
 
name: api_docs_generator
description: Generates API documentation in OpenAPI format from code
 
---
 
# API Documentation Generator
 
When generating API documentation:
 
## Output Format Rules
 
- Always output valid YAML (not JSON) # => Consistent format regardless of LLM model
- Use OpenAPI 3.1 specification # => Specific version, not "latest"
- Include descriptions for every endpoint, parameter, and response
- Use examples for all request/response bodies
- Group endpoints by resource (users, orders, products)
 
## Structure Template
 
```yaml
openapi: "3.1.0"
info:
  title: "{service-name} API"
  version: "{semver}"
paths:
  /{resource}:
    get:
      summary: "List {resources}"
      description: "Returns paginated list of {resources}"
      parameters: [...]
      responses:
        "200":
          description: "Successful response"
          content:
            application/json:
              schema: { ... }
              example: { ... }
```

# Sessions are created automatically when conversation starts
openclaw agent -m "Hello"               # => Creates new session
                                        # => Session ID assigned (UUID)
                                        # => Context: just this message
 
# In Telegram/Slack, sessions persist per-user
# User sends: "What is Rust?"
                                        # => Session created or resumed for this user
                                        # => Previous messages in context
 
# List active sessions
openclaw sessions list                  # => Output: table of active sessions
                                        # => Shows: session ID, channel, user, message count
                                        # => Shows: last activity timestamp
 
# View session history
openclaw sessions history <session-id>  # => Shows all messages in session
                                        # => Output: timestamped conversation log
                                        # => Includes tool calls and responses
 
# Clear a session (reset context)
openclaw sessions clear <session-id>    # => Deletes session history
                                        # => Next message starts fresh context
                                        # => Output: "Session cleared"

# In any messaging channel:
/new                                    # => Clears current session history
                                        # => Next message starts with empty context
                                        # => Output: "Session reset. Starting fresh."
 
# Common workflow:
# 1. Discuss Python debugging (messages 1-20)
# 2. /new (reset context)
# 3. Discuss Kubernetes deployment (messages 1-N)
                                        # => Clean context for new topic
                                        # => No Python debugging context bleeding in

// Enable session management tools
{
  tools: {
    allow: [
      "sessions_list", // => List active sessions
      "sessions_history", // => Read session history
      "sessions_send", // => Send to other sessions
    ],
  },
}

# In Telegram conversation:
You: Send a summary of our discussion to my Slack session
                                        # => Agent uses sessions_list to find Slack session
                                        # => Agent uses sessions_send to forward summary
                                        # => Slack receives: "Summary from Telegram: ..."
 
# Use case: incident coordination
You: Tell my Discord session to start monitoring logs
                                        # => Agent sends instruction to Discord session
                                        # => Discord session activates log_analyzer skill

# In conversation:
/verbose on                             # => Enables verbose output for this session
                                        # => Shows tool calls, timing, token usage
                                        # => Useful for debugging skill behavior
 
/trace on                               # => Enables detailed execution trace
                                        # => Shows every internal decision
                                        # => High output volume — use sparingly
 
/think high                             # => Override thinking level for this session
                                        # => Only affects current conversation
                                        # => Does not change global config
 
/verbose off                            # => Disables verbose output
/trace off                              # => Disables trace output

# ~/.openclaw/workspace/workflows/hello.yaml
name:
  hello-workflow # => Workflow identifier
  # => Used in: lobster run hello-workflow
description: A simple workflow that greets and reports system info
 
steps:
  - id: greet # => Step identifier (referenced by other steps)
    run:
      echo "Hello from Lobster!" # => Shell command to execute
      # => Output captured as $greet.stdout
 
  - id: sysinfo # => Second step runs after first completes
    run:
      uname -a # => Captures system information
      # => Output: $sysinfo.stdout
 
  - id: report # => Third step uses previous outputs
    run: |
      echo "Greeting: $greet.stdout"
      echo "System: $sysinfo.stdout"
                                        # => References previous step outputs
                                        # => $step_id.stdout accesses step's stdout

lobster run hello-workflow              # => Executes workflow sequentially
                                        # => Step 1: greet → "Hello from Lobster!"
                                        # => Step 2: sysinfo → "Darwin 24.5.0..."
                                        # => Step 3: report → combines outputs
                                        # => Output: final report

# ~/.openclaw/workspace/workflows/deploy.yaml
name: deploy
description: Deploy application to specified environment
 
args:
  environment: # => Argument name
    type: string # => Type validation (string, number, boolean)
    default: staging # => Default value if not provided
    enum: [staging, production] # => Allowed values (validation)
  branch:
    type: string
    default: main # => Default branch to deploy
  dry_run:
    type: boolean
    default: true # => Safe default: dry run enabled
 
steps:
  - id: validate
    run: |
      echo "Deploying ${branch} to ${environment}"
      echo "Dry run: ${dry_run}"
                                        # => Arguments accessed as ${arg_name}
                                        # => Validated before workflow starts
 
  - id: build
    run:
      npm run build -- --env=${environment}
      # => Build with environment-specific config
 
  - id: deploy
    run: |
      if [ "${dry_run}" = "true" ]; then
        echo "[DRY RUN] Would deploy to ${environment}"
      else
        npm run deploy:${environment}
      fi
                                        # => Conditional execution based on argument

lobster run deploy                      # => Uses defaults: staging, main, dry_run=true
lobster run deploy --environment=production --dry_run=false
                                        # => Override: deploy to production for real
lobster run deploy --branch=feature/new-ui
                                        # => Override: deploy specific branch

# ~/.openclaw/workspace/workflows/weather-advisor.yaml
name: weather-advisor
description: Fetches weather data and generates clothing advice
 
args:
  location:
    default: "New York"
 
steps:
  - id: fetch
    run:
      curl -s "https://wttr.in/${location}?format=j1"
      # => Fetches weather data as JSON
      # => Output stored in $fetch.stdout
      # => Parsed JSON available as $fetch.json
 
  - id: extract
    run: |
      echo '{"temp": "'$(echo '$fetch.json' | jq -r '.current_condition[0].temp_C')'", "desc": "'$(echo '$fetch.json' | jq -r '.current_condition[0].weatherDesc[0].value')'"}'
                                        # => Extracts specific fields from JSON
                                        # => Creates new JSON for next step
    stdin:
      $fetch.json # => Pipes previous step's JSON as stdin
      # => Alternative to $step_id references in run
 
  - id: advise
    pipeline: |
      llm.invoke --prompt "Given this weather data, what should I wear? Be concise."
                                        # => pipeline type: sends to LLM instead of shell
                                        # => LLM receives weather data as context
    stdin: $extract.json # => Structured weather data as LLM input

lobster run weather-advisor --location="Tokyo"
                                        # => Step 1: fetch Tokyo weather JSON
                                        # => Step 2: extract temp and description
                                        # => Step 3: LLM advises based on weather
                                        # => Output: "It's 22°C and sunny. Light jacket..."

# ~/.openclaw/workspace/workflows/database-migration.yaml
name: database-migration
description: Runs database migration with approval gate before production
 
args:
  migration_file:
    type: string
 
steps:
  - id: preview
    run: |
      echo "=== Migration Preview ==="
      cat ${migration_file}
      echo "=== Affected Tables ==="
      grep -i "ALTER\|CREATE\|DROP" ${migration_file} || echo "No DDL statements"
                                        # => Shows what the migration will do
                                        # => No changes applied yet
 
  - id: confirm
    approval: |
      Review the migration above.
      This will modify the PRODUCTION database.
      Type 'approve' to proceed or 'reject' to cancel.
                                        # => approval type: pauses workflow
                                        # => Waits for human input
                                        # => Result: $confirm.approved (boolean)
 
  - id: apply
    run: psql $DATABASE_URL -f ${migration_file}
    when:
      $confirm.approved # => Only runs if human approved
      # => Skipped entirely if rejected
      # => when clause: conditional execution
 
  - id: verify
    run: psql $DATABASE_URL -c "SELECT count(*) FROM pg_stat_activity"
    when: $confirm.approved # => Verification only after successful apply

lobster run database-migration --migration_file=migrations/002_add_index.sql
                                        # => Step 1: preview migration content
                                        # => Step 2: PAUSE — wait for human approval
                                        # => (human types 'approve')
                                        # => Step 3: apply migration to database
                                        # => Step 4: verify database health

# ~/.openclaw/workspace/workflows/ci-check.yaml
name: ci-check
description: Runs CI checks with conditional steps based on file changes
 
steps:
  - id: changes
    run:
      git diff --name-only HEAD~1 # => List files changed in last commit
      # => Output: one file path per line
 
  - id: has_ts
    run:
      echo '$changes.stdout' | grep -q '\.ts$' && echo "true" || echo "false"
      # => Check if TypeScript files changed
      # => Output: "true" or "false"
 
  - id: has_go
    run:
      echo '$changes.stdout' | grep -q '\.go$' && echo "true" || echo "false"
      # => Check if Go files changed
 
  - id: lint_ts
    run: npm run lint # => Run TypeScript linting
    when:
      $has_ts.stdout == "true" # => Only if TS files changed
      # => Skipped otherwise (saves time)
 
  - id: lint_go
    run: golangci-lint run ./... # => Run Go linting
    when: $has_go.stdout == "true" # => Only if Go files changed
 
  - id: test_ts
    run: npm run test # => Run TypeScript tests
    when: $has_ts.stdout == "true"
 
  - id: test_go
    run: go test ./... # => Run Go tests
    when: $has_go.stdout == "true"
 
  - id: report
    run: echo "CI complete. TS=$has_ts.stdout GO=$has_go.stdout"

# ~/.openclaw/workspace/workflows/api-sync.yaml
name: api-sync
description: Syncs data from external API with retry logic
 
steps:
  - id: fetch
    run: curl -sf "https://api.example.com/data"
    retry:
      max_attempts: 3 # => Retry up to 3 times on failure
      delay: 5s # => Wait 5 seconds between retries
      backoff:
        exponential # => 5s, 10s, 20s (exponential backoff)
        # => Alternatives: fixed, linear
    timeout:
      30s # => Kill step if not complete in 30 seconds
      # => Prevents hanging on unresponsive APIs
 
  - id: validate
    run: echo '$fetch.stdout' | jq '.data | length'
    timeout:
      5s # => JSON parsing should be instant
      # => 5s timeout catches malformed data loops
 
  - id: store
    run: echo '$fetch.stdout' > data/latest.json
    retry:
      max_attempts: 2 # => Retry file writes (disk might be busy)
      delay: 1s
      backoff: fixed # => Fixed 1s delay between retries

lobster visualize api-sync              # => Generates Mermaid diagram of workflow
                                        # => Output: mermaid code block
                                        # => Paste into markdown for rendered diagram
 
lobster visualize api-sync --format=dot # => Graphviz DOT format
                                        # => Pipe to: dot -Tpng -o workflow.png
 
lobster visualize api-sync --format=ascii
                                        # => ASCII art for terminal display
                                        # => Output:
                                        # =>   [fetch] → [validate] → [store]
                                        # =>     ↻ retry:3    timeout:5s
 
lobster run api-sync --dry-run          # => Simulates workflow without executing
                                        # => Shows: which steps would run
                                        # => Shows: data flow between steps
                                        # => Shows: conditional branches taken

// Enable subagent tools
{
  tools: {
    allow: ["subagents"], // => Enables subagent spawning
    // => Parent agent can create child agents
  },
}

# In conversation with agent:
You: Research React vs Vue, write a comparison, and test the code examples.
     Use subagents to do this in parallel.
                                        # => Parent agent spawns 3 subagents:
                                        # => Subagent 1: web_search for React vs Vue research
                                        # => Subagent 2: generate comparison code examples
                                        # => Subagent 3: test code examples
                                        # => Parent waits for all to complete
                                        # => Parent combines results into final answer

// ~/.openclaw/openclaw.json
{
  agents: {
    defaults: {
      model: { primary: "anthropic/claude-sonnet-4-6" },
    },
    profiles: {
      researcher: {
        // => Named profile: "researcher"
        model: {
          primary: "anthropic/claude-opus-4-6",
          // => Powerful model for deep analysis
        },
        systemPrompt: "You are a thorough researcher. Always cite sources.",
        tools: {
          allow: ["web_search", "web_fetch", "group:fs"],
          deny: ["exec"], // => No shell access for research
        },
      },
      coder: {
        // => Named profile: "coder"
        model: {
          primary: "anthropic/claude-sonnet-4-6",
          // => Balanced model for code tasks
        },
        systemPrompt: "You are a senior software engineer. Write clean, tested code.",
        tools: {
          allow: ["group:fs", "exec"], // => Full dev access
        },
      },
      ops: {
        // => Named profile: "ops"
        model: {
          primary: "anthropic/claude-haiku-4-5",
          // => Fast model for operational queries
        },
        systemPrompt: "You are a DevOps engineer. Prioritize safety and monitoring.",
        tools: {
          allow: ["exec", "web_fetch", "cron"],
          deny: ["group:fs"], // => No file writes for ops queries
        },
      },
    },
  },
}

openclaw agent --profile=researcher -m "Research Kubernetes vs Nomad"
                                        # => Uses Opus model, research system prompt
                                        # => web_search + web_fetch available, no exec
 
openclaw agent --profile=coder -m "Implement binary search in Go"
                                        # => Uses Sonnet model, coding system prompt
                                        # => Full file system + exec access
 
openclaw agent --profile=ops -m "Check if port 8080 is in use"
                                        # => Uses Haiku model, ops system prompt
                                        # => exec available, no file writes

// Enable coordination tools
{
  tools: {
    allow: [
      "sessions_list", // => Discover other active sessions
      "sessions_history", // => Read other session conversations
      "sessions_send", // => Send messages to other sessions
      "subagents", // => Spawn child agents
    ],
  },
}

# Scenario: Coordinated incident response
# Agent 1 (Telegram, ops profile): detects issue
# Agent 2 (Slack, researcher profile): investigates
# Agent 3 (Discord, coder profile): implements fix
 
# In Telegram (ops agent):
You: Production error rate spiked. Coordinate investigation.
                                        # => Ops agent uses sessions_list to find other agents
                                        # => Sends to Slack researcher: "Investigate error spike"
                                        # => Sends to Discord coder: "Stand by for fix implementation"
                                        # => Ops agent monitors metrics while others work
 
# Slack researcher reports findings back to Telegram
# Discord coder receives findings and implements fix
# All agents share context through sessions_send