Initial commit: OpenClaw Skill Collection

6 custom skills (assign-task, dispatch-webhook, daily-briefing,
task-capture, qmd-brain, tts-voice) with technical documentation.
Compatible with Claude Code, OpenClaw, Codex CLI, and OpenCode.

openclaw-knowhow-skill/docs/tools/agent-send.md

@@ -0,0 +1,24 @@
+# Agent Send Documentation
+
+## Overview
+
+The `openclaw agent` command executes a single agent turn without requiring an inbound chat message. It runs through the Gateway by default; add `--local` to force the embedded runtime on the current machine.
+
+## Key Capabilities
+
+**Session Management:**
+The command supports three approaches for session selection: targeting via `--to`, reusing existing sessions with `--session-id`, or directly addressing configured agents using `--agent`.
+
+**Output Formats:**
+By default, the command prints reply text and media URLs. Using `--json` flag generates structured payload with metadata instead.
+
+**Delivery Options:**
+Optional delivery back to a channel with `--deliver` + `--channel` enables routing responses to WhatsApp, Telegram, Discord, Google Chat, Slack, Signal, or iMessage.
+
+## Notable Flags
+
+The command supports thinking levels (`off|minimal|low|medium|high|xhigh`), verbose output control, custom timeouts, and fallback behavior: If the Gateway is unreachable, the CLI falls back to the embedded local run.
+
+## Practical Usage
+
+Common scenarios include status updates to contacts, log summarization for specific agents, and inbox analysis within existing sessions—all executable from the command line with optional message delivery to configured channels.

openclaw-knowhow-skill/docs/tools/apply-patch.md

@@ -0,0 +1,26 @@
+# apply_patch Tool Documentation
+
+## Overview
+The `apply_patch` tool enables file changes using a structured patch format with support for multi-file or multi-hunk edits where a single `edit` call would be brittle.
+
+## Core Functionality
+This tool processes a single input string containing one or more file operations, structured with `*** Begin Patch` and `*** End Patch` markers.
+
+## Supported Operations
+- **Add File**: Introduces new files with `*** Add File: path/to/file.txt`
+- **Update File**: Modifies existing files with `*** Update File: src/app.ts`
+- **Delete File**: Removes files with `*** Delete File: obsolete.txt`
+- **Rename Files**: Uses `*** Move to:` within update hunks
+
+## Key Parameters
+The tool requires a single `input` parameter containing the complete patch contents with appropriate delimiters.
+
+## Important Constraints
+- Paths resolve relative to workspace root
+- Currently experimental and disabled by default
+- Requires activation via `tools.exec.applyPatch.enabled`
+- OpenAI-exclusive support (including Codex)
+- Configuration available under `tools.exec` namespace only
+
+## Special Markers
+`*** End of File` designates EOF-only insertions when necessary.

openclaw-knowhow-skill/docs/tools/browser-linux-troubleshooting.md

@@ -0,0 +1,27 @@
+# Browser Troubleshooting Documentation
+
+## Overview
+
+This documentation addresses Chrome DevTools Protocol (CDP) launch failures on Linux systems, particularly Ubuntu, where snap-packaged Chromium creates AppArmor confinement issues preventing OpenClaw from properly spawning browser processes.
+
+## Key Problem
+
+The default Ubuntu Chromium installation is a snap wrapper rather than a native binary. As the docs note, `apt install chromium` provides a stub package that redirects to snap rather than an actual browser executable.
+
+## Recommended Solutions
+
+**Primary approach:** Install the official Google Chrome `.deb` package from Google's repositories, which bypasses snap sandboxing entirely. Configuration requires setting the `executablePath` to `/usr/bin/google-chrome-stable` in `~/.openclaw/openclaw.json`.
+
+**Alternative approach:** Configure OpenClaw's `attachOnly` mode to connect to a manually-launched Chromium instance running on port 18800, bypassing automatic browser startup. A systemd user service can automate this manual launch process.
+
+## Configuration Reference
+
+The documentation provides a configuration table with four key browser options:
+- `browser.enabled` (default: true)
+- `browser.executablePath` (auto-detected)
+- `browser.headless` (default: false)
+- `browser.noSandbox` (default: false)
+
+## Verification
+
+Users can verify functionality via curl commands checking the browser status endpoint and testing tab functionality at `http://127.0.0.1:18791/`.

openclaw-knowhow-skill/docs/tools/browser-login.md

@@ -0,0 +1,19 @@
+# Browser Login Documentation
+
+## Key Recommendations
+
+The documentation emphasizes that **manual login is the recommended approach** when sites require authentication. Rather than providing credentials to the model, users should sign in manually in the host browser profile (the openclaw browser), as automated logins frequently trigger security defenses.
+
+## Chrome Profile Details
+
+OpenClaw operates through a dedicated Chrome profile called `openclaw` with distinctive orange-tinted styling, kept separate from personal browser profiles. Users can access it either by requesting the agent to launch the browser or through command-line tools.
+
+## X/Twitter Best Practices
+
+For social media interactions, the guidance suggests using the CLI-based bird tool for reading and searching content, while reserving the host browser for posting activities that require authentication.
+
+## Sandboxing Configuration
+
+When agents operate in sandboxed environments, bot detection risks increase. The documentation provides configuration options to enable host browser control, allowing agents to access the main browser while maintaining sandboxing for other functions.
+
+The core principle throughout: **prioritize host browser access over automated credentials** to avoid triggering anti-bot systems.

openclaw-knowhow-skill/docs/tools/browser.md

@@ -0,0 +1,48 @@
+# Browser (OpenClaw-managed) Documentation
+
+## Overview
+
+OpenClaw operates a dedicated, isolated browser profile separate from your personal browsing. The system supports multiple browser profiles including "openclaw" (managed), "chrome" (extension relay), and remote CDP configurations.
+
+## Key Features
+
+**Isolation & Control:**
+A separate browser profile named openclaw (orange accent by default) with deterministic tab management, agent actions like clicking and typing, plus snapshots and screenshots.
+
+**Profile Options:**
+- `openclaw`: managed, isolated instance
+- `chrome`: extension relay to your system browser
+- Remote CDP: browser running elsewhere
+
+## Quick Start
+
+Basic commands include starting the browser, opening URLs, and capturing snapshots:
+```bash
+openclaw browser --browser-profile openclaw start
+openclaw browser open https://example.com
+openclaw browser snapshot
+```
+
+## Configuration
+
+Browser settings reside in `~/.openclaw/openclaw.json`. Key options include enabling/disabling, setting default profiles, choosing executable paths, and configuring multiple profiles with different CDP ports.
+
+## Snapshot & Action System
+
+Two snapshot styles exist:
+- **AI snapshots** (numeric refs like `12`): `openclaw browser snapshot`
+- **Role snapshots** (role refs like `e12`): `openclaw browser snapshot --interactive`
+
+Actions use refs from snapshots: `openclaw browser click 12` or `openclaw browser type e12 "text"`
+
+## Extension Relay Setup
+
+Users can control existing Chrome tabs via the OpenClaw extension without launching a separate browser instance, requiring the extension installation and activation on desired tabs.
+
+## Security Considerations
+
+Browser control is loopback-only; access flows through the Gateway's auth or node pairing. Remote CDP URLs should use HTTPS where possible and tokens should be managed via environment variables rather than config files.
+
+## Debugging & Advanced Features
+
+Tools include console logging, error tracking, network request inspection, tracing, and JavaScript evaluation within page context—all accessible via CLI commands.

openclaw-knowhow-skill/docs/tools/chrome-extension.md

@@ -0,0 +1,33 @@
+# Chrome Extension Documentation
+
+## Overview
+
+The OpenClaw Chrome extension enables agent control of existing Chrome tabs through a browser relay system rather than launching a separate profile.
+
+## Core Architecture
+
+The system consists of three components:
+
+1. **Browser control service**: API endpoint the agent calls via Gateway
+2. **Local relay server**: Bridges control server and extension (default: `http://127.0.0.1:18792`)
+3. **Chrome MV3 extension**: Attaches to active tabs using `chrome.debugger` and pipes CDP messages
+
+## Installation Steps
+
+Users install the extension via CLI command, retrieve its path, then manually load it unpacked in Chrome's developer mode and pin it for convenience.
+
+## Operating the Extension
+
+The built-in `chrome` profile targets the extension relay by default. Users can create custom profiles with different names and ports as needed. The extension controls only explicitly attached tabs—it doesn't automatically target whatever tab is visible.
+
+## Status Indicators
+
+The toolbar badge displays connection status: "ON" indicates attachment, "…" shows connecting state, and "!" signals relay unreachability (typically meaning the browser relay server isn't running locally).
+
+## Gateway Configurations
+
+**Local setups** (Gateway on same machine as Chrome) require minimal configuration—the relay auto-starts. **Remote setups** (Gateway elsewhere) require running a node host on the Chrome machine.
+
+## Security Considerations
+
+The documentation emphasizes this grants significant access: When attached, the model can click/type/navigate in that tab, read page content, access whatever the tab's logged-in session can access. Recommendations include using dedicated Chrome profiles, maintaining tailnet-only access, and avoiding public port exposure.

openclaw-knowhow-skill/docs/tools/clawhub.md

@@ -0,0 +1,25 @@
+# ClawHub Documentation
+
+## Overview
+ClawHub functions as a public skill registry for OpenClaw, offering free access to shared, reusable skills. The platform enables users to discover, install, and publish capabilities through a web interface or CLI.
+
+## Core Functionality
+A skill comprises a folder with a `SKILL.md` file (plus supporting text files). The registry manages versioned bundles, making them searchable through embeddings-powered discovery rather than keyword-only approaches.
+
+## Key Features
+- Semantic search across skill repositories
+- Semantic versioning with changelog tracking
+- Community engagement through stars and comments
+- Moderation systems including reporting mechanisms
+
+## Publishing Requirements
+New publishers must maintain GitHub accounts active for at least one week before uploading. This threshold helps mitigate malicious uploads while remaining accessible to legitimate contributors.
+
+## Installation
+Users can quickly set up the CLI via npm or pnpm, then search for and install skills using straightforward commands like `clawhub search "calendar"` and `clawhub install <skill-slug>`.
+
+## Security Measures
+The platform implements automated protections: skills receiving more than three distinct reports are hidden by default, and moderators can manage content visibility and enforce user restrictions when abuse occurs.
+
+## Local Integration
+ClawHub installs skills into `./skills` directories by default, with workspace configurations providing fallback locations. OpenClaw loads these skills in subsequent sessions automatically.

openclaw-knowhow-skill/docs/tools/elevated.md

@@ -0,0 +1,28 @@
+# Elevated Mode Documentation
+
+## Overview
+
+The Elevated Mode feature (`/elevated` or `/elev` directives) controls execution behavior for sandboxed agents. `/elevated on` runs on the gateway host while maintaining exec approvals, whereas `/elevated full` does the same but auto-approves executions.
+
+## Key Functionality
+
+**Core behaviors:**
+- `on`/`ask`: Gateway host execution with approval checks intact
+- `full`: Gateway host execution with automatic approval bypass
+- `off`: Disables elevated mode
+- These directives only affect sandboxed agents; unsandboxed agents already execute on the host
+
+**Important limitation:** Only changes behavior when the agent is sandboxed; otherwise exec already runs on the host.
+
+## Access Control
+
+Elevated mode availability is determined by multiple gates:
+- Global feature flag: `tools.elevated.enabled`
+- Per-provider allowlists under `tools.elevated.allowFrom`
+- Per-agent restrictions through `agents.list[].tools.elevated`
+
+Discord has a fallback: if no Discord allowlist is specified, the DM allowlist applies automatically.
+
+## Usage Methods
+
+Users can set elevated mode by sending directive-only messages, check current status with `/elevated:`, or apply directives inline within messages for single-use application.

openclaw-knowhow-skill/docs/tools/exec.md

@@ -0,0 +1,38 @@
+# Exec Tool Documentation
+
+## Overview
+
+The Exec Tool allows agents to execute shell commands in a workspace, supporting both foreground and background execution modes through the `process` parameter.
+
+## Key Parameters
+
+The tool accepts several configuration options:
+
+- **command** (required): The shell command to execute
+- **workdir**: Working directory (defaults to current)
+- **env**: Environment variable overrides
+- **yieldMs**: auto-background after delay (default 10000ms)
+- **background**: Immediate background execution option
+- **timeout**: Command termination threshold (default 1800 seconds)
+- **pty**: Pseudo-terminal mode for TTY-dependent applications
+- **host**: Execution location—sandbox, gateway, or node
+- **security**: Enforcement mode with deny, allowlist, or full options
+- **ask**: Approval prompts controlled via on-miss, always, or off settings
+
+## Execution Hosts
+
+The tool supports three execution contexts:
+
+1. **Sandbox** (default): Container-based execution
+2. **Gateway**: Host machine execution with approval controls
+3. **Node**: Remote paired device execution
+
+## Important Security Notes
+
+Sandboxing is **off by default** and `host=sandbox` runs directly on the gateway host (no container) and **does not require approvals**.
+
+To enforce approval requirements, configure `host=gateway` with appropriate security policies via `~/.openclaw/exec-approvals.json`.
+
+## Session Management
+
+The `/exec` command sets per-session defaults for host, security, approval mode, and node binding without writing permanent configuration changes.

openclaw-knowhow-skill/docs/tools/index.md

@@ -0,0 +1,53 @@
+# OpenClaw Tools Documentation
+
+## Overview
+
+OpenClaw provides first-class agent tools for browser automation, canvas rendering, node management, and scheduled tasks. These replace legacy `openclaw-*` skills with typed implementations that don't require shell execution.
+
+## Tool Access Control
+
+### Global Configuration
+Tools can be restricted via `tools.allow` and `tools.deny` in `openclaw.json`. Matching is case-insensitive, wildcards are supported, and deny rules take precedence.
+
+### Tool Profiles
+Base allowlists can be set with `tools.profile`:
+- **minimal**: session status only
+- **coding**: filesystem, runtime, sessions, memory, and image analysis
+- **messaging**: messaging channels and session management
+- **full**: unrestricted access
+
+### Provider-Specific Policies
+The `tools.byProvider` configuration narrows tool access for particular providers or model versions without affecting global settings.
+
+### Tool Groups
+Shorthand groups simplify policy configuration:
+- `group:runtime` (exec, bash, process)
+- `group:fs` (file operations)
+- `group:sessions` (session management)
+- `group:memory` (memory tools)
+- `group:web` (web search and fetch)
+- `group:ui` (browser and canvas)
+- `group:automation` (cron and gateway)
+- `group:messaging` (message delivery)
+
+## Core Tools
+
+**exec**: Execute shell commands with configurable timeout, background execution, and elevated privileges when allowed.
+
+**process**: Manage background sessions with polling, logging, and termination.
+
+**web_search / web_fetch**: Query the web and extract readable content from URLs.
+
+**browser**: Control a dedicated browser instance for UI automation, screenshots, and PDF generation.
+
+**canvas**: Render and interact with node canvas presentations.
+
+**nodes**: Discover paired nodes and capture camera/screen media with user consent.
+
+**message**: Send communications across Discord, Slack, Teams, WhatsApp, and other platforms.
+
+**cron**: Schedule and manage gateway jobs.
+
+## Safety Practices
+
+Direct system execution should only occur with explicit user consent. Media capture (camera/screen) requires foreground access and user approval.

openclaw-knowhow-skill/docs/tools/llm-task.md

@@ -0,0 +1,107 @@
+# LLM Task
+
+`llm-task` is an **optional plugin tool** that runs a JSON-only LLM task and
+returns structured output (optionally validated against JSON Schema).
+
+This is ideal for workflow engines like Lobster: you can add a single LLM step
+without writing custom OpenClaw code for each workflow.
+
+## Enable the plugin
+
+1. Enable the plugin:
+
+```json
+{
+  "plugins": {
+    "entries": {
+      "llm-task": { "enabled": true }
+    }
+  }
+}
+```
+
+2. Allowlist the tool (it is registered with `optional: true`):
+
+```json
+{
+  "agents": {
+    "list": [
+      {
+        "id": "main",
+        "tools": { "allow": ["llm-task"] }
+      }
+    ]
+  }
+}
+```
+
+## Config (optional)
+
+```json
+{
+  "plugins": {
+    "entries": {
+      "llm-task": {
+        "enabled": true,
+        "config": {
+          "defaultProvider": "openai-codex",
+          "defaultModel": "gpt-5.2",
+          "defaultAuthProfileId": "main",
+          "allowedModels": ["openai-codex/gpt-5.2"],
+          "maxTokens": 800,
+          "timeoutMs": 30000
+        }
+      }
+    }
+  }
+}
+```
+
+`allowedModels` is an allowlist of `provider/model` strings. If set, any request
+outside the list is rejected.
+
+## Tool parameters
+
+* `prompt` (string, required)
+* `input` (any, optional)
+* `schema` (object, optional JSON Schema)
+* `provider` (string, optional)
+* `model` (string, optional)
+* `authProfileId` (string, optional)
+* `temperature` (number, optional)
+* `maxTokens` (number, optional)
+* `timeoutMs` (number, optional)
+
+## Output
+
+Returns `details.json` containing the parsed JSON (and validates against
+`schema` when provided).
+
+## Example: Lobster workflow step
+
+```lobster
+openclaw.invoke --tool llm-task --action json --args-json '{
+  "prompt": "Given the input email, return intent and draft.",
+  "input": {
+    "subject": "Hello",
+    "body": "Can you help?"
+  },
+  "schema": {
+    "type": "object",
+    "properties": {
+      "intent": { "type": "string" },
+      "draft": { "type": "string" }
+    },
+    "required": ["intent", "draft"],
+    "additionalProperties": false
+  }
+}'
+```
+
+## Safety notes
+
+* The tool is **JSON-only** and instructs the model to output only JSON (no
+  code fences, no commentary).
+* No tools are exposed to the model for this run.
+* Treat output as untrusted unless you validate with `schema`.
+* Put approvals before any side-effecting step (send, post, exec).

openclaw-knowhow-skill/docs/tools/lobster.md

@@ -0,0 +1,335 @@
+# Lobster
+
+> Typed workflow runtime for OpenClaw — composable pipelines with approval gates.
+
+Lobster is a workflow shell that lets OpenClaw run multi-step tool sequences as a single, deterministic operation with explicit approval checkpoints.
+
+## Hook
+
+Your assistant can build the tools that manage itself. Ask for a workflow, and 30 minutes later you have a CLI plus pipelines that run as one call. Lobster is the missing piece: deterministic pipelines, explicit approvals, and resumable state.
+
+## Why
+
+Today, complex workflows require many back-and-forth tool calls. Each call costs tokens, and the LLM has to orchestrate every step. Lobster moves that orchestration into a typed runtime:
+
+* **One call instead of many**: OpenClaw runs one Lobster tool call and gets a structured result.
+* **Approvals built in**: Side effects (send email, post comment) halt the workflow until explicitly approved.
+* **Resumable**: Halted workflows return a token; approve and resume without re-running everything.
+
+## Why a DSL instead of plain programs?
+
+Lobster is intentionally small. The goal is not "a new language," it's a predictable, AI-friendly pipeline spec with first-class approvals and resume tokens.
+
+* **Approve/resume is built in**: A normal program can prompt a human, but it can't *pause and resume* with a durable token without you inventing that runtime yourself.
+* **Determinism + auditability**: Pipelines are data, so they're easy to log, diff, replay, and review.
+* **Constrained surface for AI**: A tiny grammar + JSON piping reduces "creative" code paths and makes validation realistic.
+* **Safety policy baked in**: Timeouts, output caps, sandbox checks, and allowlists are enforced by the runtime, not each script.
+* **Still programmable**: Each step can call any CLI or script. If you want JS/TS, generate `.lobster` files from code.
+
+## How it works
+
+OpenClaw launches the local `lobster` CLI in **tool mode** and parses a JSON envelope from stdout.
+If the pipeline pauses for approval, the tool returns a `resumeToken` so you can continue later.
+
+## Pattern: small CLI + JSON pipes + approvals
+
+Build tiny commands that speak JSON, then chain them into a single Lobster call. (Example command names below — swap in your own.)
+
+```bash
+inbox list --json
+inbox categorize --json
+inbox apply --json
+```
+
+```json
+{
+  "action": "run",
+  "pipeline": "exec --json --shell 'inbox list --json' | exec --stdin json --shell 'inbox categorize --json' | exec --stdin json --shell 'inbox apply --json' | approve --preview-from-stdin --limit 5 --prompt 'Apply changes?'",
+  "timeoutMs": 30000
+}
+```
+
+If the pipeline requests approval, resume with the token:
+
+```json
+{
+  "action": "resume",
+  "token": "<resumeToken>",
+  "approve": true
+}
+```
+
+AI triggers the workflow; Lobster executes the steps. Approval gates keep side effects explicit and auditable.
+
+Example: map input items into tool calls:
+
+```bash
+gog.gmail.search --query 'newer_than:1d' \
+  | openclaw.invoke --tool message --action send --each --item-key message --args-json '{"provider":"telegram","to":"..."}'
+```
+
+## JSON-only LLM steps (llm-task)
+
+For workflows that need a **structured LLM step**, enable the optional
+`llm-task` plugin tool and call it from Lobster. This keeps the workflow
+deterministic while still letting you classify/summarize/draft with a model.
+
+Enable the tool:
+
+```json
+{
+  "plugins": {
+    "entries": {
+      "llm-task": { "enabled": true }
+    }
+  },
+  "agents": {
+    "list": [
+      {
+        "id": "main",
+        "tools": { "allow": ["llm-task"] }
+      }
+    ]
+  }
+}
+```
+
+Use it in a pipeline:
+
+```lobster
+openclaw.invoke --tool llm-task --action json --args-json '{
+  "prompt": "Given the input email, return intent and draft.",
+  "input": { "subject": "Hello", "body": "Can you help?" },
+  "schema": {
+    "type": "object",
+    "properties": {
+      "intent": { "type": "string" },
+      "draft": { "type": "string" }
+    },
+    "required": ["intent", "draft"],
+    "additionalProperties": false
+  }
+}'
+```
+
+See [LLM Task](/tools/llm-task) for details and configuration options.
+
+## Workflow files (.lobster)
+
+Lobster can run YAML/JSON workflow files with `name`, `args`, `steps`, `env`, `condition`, and `approval` fields. In OpenClaw tool calls, set `pipeline` to the file path.
+
+```yaml
+name: inbox-triage
+args:
+  tag:
+    default: "family"
+steps:
+  - id: collect
+    command: inbox list --json
+  - id: categorize
+    command: inbox categorize --json
+    stdin: $collect.stdout
+  - id: approve
+    command: inbox apply --approve
+    stdin: $categorize.stdout
+    approval: required
+  - id: execute
+    command: inbox apply --execute
+    stdin: $categorize.stdout
+    condition: $approve.approved
+```
+
+Notes:
+
+* `stdin: $step.stdout` and `stdin: $step.json` pass a prior step's output.
+* `condition` (or `when`) can gate steps on `$step.approved`.
+
+## Install Lobster
+
+Install the Lobster CLI on the **same host** that runs the OpenClaw Gateway (see the [Lobster repo](https://github.com/openclaw/lobster)), and ensure `lobster` is on `PATH`.
+If you want to use a custom binary location, pass an **absolute** `lobsterPath` in the tool call.
+
+## Enable the tool
+
+Lobster is an **optional** plugin tool (not enabled by default).
+
+Recommended (additive, safe):
+
+```json
+{
+  "tools": {
+    "alsoAllow": ["lobster"]
+  }
+}
+```
+
+Or per-agent:
+
+```json
+{
+  "agents": {
+    "list": [
+      {
+        "id": "main",
+        "tools": {
+          "alsoAllow": ["lobster"]
+        }
+      }
+    ]
+  }
+}
+```
+
+Avoid using `tools.allow: ["lobster"]` unless you intend to run in restrictive allowlist mode.
+
+Note: allowlists are opt-in for optional plugins. If your allowlist only names
+plugin tools (like `lobster`), OpenClaw keeps core tools enabled. To restrict core
+tools, include the core tools or groups you want in the allowlist too.
+
+## Example: Email triage
+
+Without Lobster:
+
+```
+User: "Check my email and draft replies"
+→ openclaw calls gmail.list
+→ LLM summarizes
+→ User: "draft replies to #2 and #5"
+→ LLM drafts
+→ User: "send #2"
+→ openclaw calls gmail.send
+(repeat daily, no memory of what was triaged)
+```
+
+With Lobster:
+
+```json
+{
+  "action": "run",
+  "pipeline": "email.triage --limit 20",
+  "timeoutMs": 30000
+}
+```
+
+Returns a JSON envelope (truncated):
+
+```json
+{
+  "ok": true,
+  "status": "needs_approval",
+  "output": [{ "summary": "5 need replies, 2 need action" }],
+  "requiresApproval": {
+    "type": "approval_request",
+    "prompt": "Send 2 draft replies?",
+    "items": [],
+    "resumeToken": "..."
+  }
+}
+```
+
+User approves → resume:
+
+```json
+{
+  "action": "resume",
+  "token": "<resumeToken>",
+  "approve": true
+}
+```
+
+One workflow. Deterministic. Safe.
+
+## Tool parameters
+
+### `run`
+
+Run a pipeline in tool mode.
+
+```json
+{
+  "action": "run",
+  "pipeline": "gog.gmail.search --query 'newer_than:1d' | email.triage",
+  "cwd": "/path/to/workspace",
+  "timeoutMs": 30000,
+  "maxStdoutBytes": 512000
+}
+```
+
+Run a workflow file with args:
+
+```json
+{
+  "action": "run",
+  "pipeline": "/path/to/inbox-triage.lobster",
+  "argsJson": "{\"tag\":\"family\"}"
+}
+```
+
+### `resume`
+
+Continue a halted workflow after approval.
+
+```json
+{
+  "action": "resume",
+  "token": "<resumeToken>",
+  "approve": true
+}
+```
+
+### Optional inputs
+
+* `lobsterPath`: Absolute path to the Lobster binary (omit to use `PATH`).
+* `cwd`: Working directory for the pipeline (defaults to the current process working directory).
+* `timeoutMs`: Kill the subprocess if it exceeds this duration (default: 20000).
+* `maxStdoutBytes`: Kill the subprocess if stdout exceeds this size (default: 512000).
+* `argsJson`: JSON string passed to `lobster run --args-json` (workflow files only).
+
+## Output envelope
+
+Lobster returns a JSON envelope with one of three statuses:
+
+* `ok` → finished successfully
+* `needs_approval` → paused; `requiresApproval.resumeToken` is required to resume
+* `cancelled` → explicitly denied or cancelled
+
+The tool surfaces the envelope in both `content` (pretty JSON) and `details` (raw object).
+
+## Approvals
+
+If `requiresApproval` is present, inspect the prompt and decide:
+
+* `approve: true` → resume and continue side effects
+* `approve: false` → cancel and finalize the workflow
+
+Use `approve --preview-from-stdin --limit N` to attach a JSON preview to approval requests without custom jq/heredoc glue. Resume tokens are now compact: Lobster stores workflow resume state under its state dir and hands back a small token key.
+
+## OpenProse
+
+OpenProse pairs well with Lobster: use `/prose` to orchestrate multi-agent prep, then run a Lobster pipeline for deterministic approvals. If a Prose program needs Lobster, allow the `lobster` tool for sub-agents via `tools.subagents.tools`. See [OpenProse](/prose).
+
+## Safety
+
+* **Local subprocess only** — no network calls from the plugin itself.
+* **No secrets** — Lobster doesn't manage OAuth; it calls OpenClaw tools that do.
+* **Sandbox-aware** — disabled when the tool context is sandboxed.
+* **Hardened** — `lobsterPath` must be absolute if specified; timeouts and output caps enforced.
+
+## Troubleshooting
+
+* **`lobster subprocess timed out`** → increase `timeoutMs`, or split a long pipeline.
+* **`lobster output exceeded maxStdoutBytes`** → raise `maxStdoutBytes` or reduce output size.
+* **`lobster returned invalid JSON`** → ensure the pipeline runs in tool mode and prints only JSON.
+* **`lobster failed (code …)`** → run the same pipeline in a terminal to inspect stderr.
+
+## Learn more
+
+* [Plugins](/plugin)
+* [Plugin tool authoring](/plugins/agent-tools)
+
+## Case study: community workflows
+
+One public example: a "second brain" CLI + Lobster pipelines that manage three Markdown vaults (personal, partner, shared). The CLI emits JSON for stats, inbox listings, and stale scans; Lobster chains those commands into workflows like `weekly-review`, `inbox-triage`, `memory-consolidation`, and `shared-task-sync`, each with approval gates. AI handles judgment (categorization) when available and falls back to deterministic rules when not.
+
+* Thread: [https://x.com/plattenschieber/status/2014508656335770033](https://x.com/plattenschieber/status/2014508656335770033)
+* Repo: [https://github.com/bloomedai/brain-cli](https://github.com/bloomedai/brain-cli)

openclaw-knowhow-skill/docs/tools/reactions.md

@@ -0,0 +1,19 @@
+# Reactions Documentation
+
+## Shared Reaction Semantics
+
+The documentation outlines core requirements for reaction functionality across messaging platforms:
+
+- **Required parameter**: The `emoji` field must be included when adding reactions
+- **Removal mechanism**: Setting `emoji=""` removes the bot's reactions (where supported)
+- **Targeted removal**: The `remove: true` flag deletes specific emoji reactions (requires `emoji` to be specified)
+
+## Platform-Specific Implementation Notes
+
+Different channels have distinct behaviors for reaction management:
+
+- **Discord/Slack**: An empty `emoji` value clears all bot reactions; `remove: true` eliminates only the targeted emoji
+- **Google Chat**: Empty `emoji` removes all app reactions; `remove: true` targets individual emoji removal
+- **Telegram**: Empty `emoji` clears bot reactions; `remove: true` requires a non-empty `emoji` for validation purposes
+- **WhatsApp**: Empty `emoji` removes the bot reaction, with `remove: true` functioning equivalently but still requiring an `emoji` value
+- **Signal**: Reaction notifications generate system events when the configuration setting `channels.signal.reactionNotifications` is enabled

openclaw-knowhow-skill/docs/tools/skills-config.md

@@ -0,0 +1,21 @@
+# Skills Config Documentation
+
+## Overview
+
+The Skills Config documentation describes how to manage skill-related settings in OpenClaw through the `~/.openclaw/openclaw.json` file under the `skills` key.
+
+## Key Configuration Areas
+
+**Bundled Skills Management**: The `allowBundled` parameter functions as an allowlist for pre-included skills. When configured, it restricts which bundled skills are available while leaving managed and workspace skills unaffected.
+
+**Skill Loading**: The system supports watching skill directories for changes with configurable debounce timing. You can specify additional directories beyond defaults through `load.extraDirs`.
+
+**Installation Preferences**: Configuration options let you choose between package managers (npm, pnpm, yarn, bun) and select Homebrew as the preferred installer when available.
+
+**Per-Skill Configuration**: Individual skills can be toggled on/off, assigned API keys, and have custom environment variables injected during agent runs.
+
+## Important Consideration for Sandboxed Environments
+
+When running in sandboxed mode with Docker, skill processes don't automatically inherit the host's environment variables. You'll need to either configure environment variables at the sandbox level (`agents.defaults.sandbox.docker.env`) or include them in a custom sandbox image.
+
+Changes to skills are picked up on the next agent turn when the watcher is enabled.

openclaw-knowhow-skill/docs/tools/skills.md

@@ -0,0 +1,34 @@
+# Skills Documentation
+
+## Overview
+
+OpenClaw employs AgentSkills-compatible skill folders to teach the agent how to use tools with a three-tier loading system prioritizing workspace skills over managed skills and bundled options.
+
+## Loading Hierarchy
+
+Skills are sourced from three locations in precedence order:
+
+1. Workspace-specific directories (`<workspace>/skills`)
+2. Machine-level managed folders (`~/.openclaw/skills`)
+3. Application bundled skills (lowest priority)
+
+Additional directories can be configured via `skills.load.extraDirs` in the OpenClaw configuration file.
+
+## Multi-Agent Considerations
+
+In systems with multiple agents, each workspace maintains its own per-agent skills collection, while shared skills live in ~/.openclaw/skills (managed/local) and are visible to all agents on the same machine.
+
+## Skill Format Requirements
+
+Skills must include a `SKILL.md` file with YAML frontmatter containing:
+- `name`: skill identifier
+- `description`: functionality summary
+- Optional `metadata` as single-line JSON for gating/configuration
+
+## Security Practices
+
+The documentation emphasizes treating third-party skills as untrusted code. Read them before enabling and recommends sandboxed execution for risky operations. Secrets injected via environment variables affect the host process only during that agent turn.
+
+## Discovery & Installation
+
+ClawHub (clawhub.com) serves as the public skills registry, enabling installation, updates, and synchronization through command-line interface tools.

openclaw-knowhow-skill/docs/tools/slash-commands.md

@@ -0,0 +1,25 @@
+# Slash Commands Documentation
+
+## Overview
+
+The system handles commands through the Gateway, with two main categories:
+
+**Commands** are standalone `/...` messages, while **Directives** like `/think`, `/verbose`, and `/model` are stripped before the model processes the message. Directives persist when sent alone but function as inline hints within regular messages.
+
+## Key Configuration
+
+The default settings enable text commands (`commands.text: true`) while disabling bash operations (`commands.bash: false`). Authorization requires `commands.useAccessGroups: true` by default, restricting directives to approved senders.
+
+## Main Command Categories
+
+**Universal commands** include `/help`, `/commands`, `/skill`, `/status`, and `/whoami`. Model-related operations use `/model` for selection and `/queue` for processing preferences.
+
+**Bash operations** require explicit enablement and use the syntax `! <cmd>` or `/bash <cmd>`. **Configuration management** relies on `/config` and `/debug` for persistent and temporary overrides respectively, both restricted to the owner.
+
+## Directives and Shortcuts
+
+Directives modify behavior dynamically: `/think` adjusts reasoning depth, `/verbose` increases output detail, and `/elevated on|off|ask|full` manages permission levels. Inline shortcuts like `/status` work within regular messages and bypass normal processing queues for authorized users.
+
+## Platform-Specific Notes
+
+Discord reserves the `/tts` command name, using `/voice` natively instead. Slack requires individual slash command setup per built-in command when native support is enabled. Telegram and Slack provide button menus for command arguments.

openclaw-knowhow-skill/docs/tools/thinking.md

@@ -0,0 +1,66 @@
+# Thinking Levels
+
+## What it does
+
+* Inline directive in any inbound body: `/t <level>`, `/think:<level>`, or `/thinking <level>`.
+* Levels (aliases): `off | minimal | low | medium | high | xhigh` (GPT-5.2 + Codex models only)
+  * minimal → "think"
+  * low → "think hard"
+  * medium → "think harder"
+  * high → "ultrathink" (max budget)
+  * xhigh → "ultrathink+" (GPT-5.2 + Codex models only)
+  * `highest`, `max` map to `high`.
+* Provider notes:
+  * Z.AI (`zai/*`) only supports binary thinking (`on`/`off`). Any non-`off` level is treated as `on` (mapped to `low`).
+
+## Resolution order
+
+1. Inline directive on the message (applies only to that message).
+2. Session override (set by sending a directive-only message).
+3. Global default (`agents.defaults.thinkingDefault` in config).
+4. Fallback: low for reasoning-capable models; off otherwise.
+
+## Setting a session default
+
+* Send a message that is **only** the directive (whitespace allowed), e.g. `/think:medium` or `/t high`.
+* That sticks for the current session (per-sender by default); cleared by `/think:off` or session idle reset.
+* Confirmation reply is sent (`Thinking level set to high.` / `Thinking disabled.`). If the level is invalid (e.g. `/thinking big`), the command is rejected with a hint and the session state is left unchanged.
+* Send `/think` (or `/think:`) with no argument to see the current thinking level.
+
+## Application by agent
+
+* **Embedded Pi**: the resolved level is passed to the in-process Pi agent runtime.
+
+## Verbose directives (/verbose or /v)
+
+* Levels: `on` (minimal) | `full` | `off` (default).
+* Directive-only message toggles session verbose and replies `Verbose logging enabled.` / `Verbose logging disabled.`; invalid levels return a hint without changing state.
+* `/verbose off` stores an explicit session override; clear it via the Sessions UI by choosing `inherit`.
+* Inline directive affects only that message; session/global defaults apply otherwise.
+* Send `/verbose` (or `/verbose:`) with no argument to see the current verbose level.
+* When verbose is on, agents that emit structured tool results (Pi, other JSON agents) send each tool call back as its own metadata-only message, prefixed with `<emoji> <tool-name>: <arg>` when available (path/command). These tool summaries are sent as soon as each tool starts (separate bubbles), not as streaming deltas.
+* When verbose is `full`, tool outputs are also forwarded after completion (separate bubble, truncated to a safe length). If you toggle `/verbose on|full|off` while a run is in-flight, subsequent tool bubbles honor the new setting.
+
+## Reasoning visibility (/reasoning)
+
+* Levels: `on|off|stream`.
+* Directive-only message toggles whether thinking blocks are shown in replies.
+* When enabled, reasoning is sent as a **separate message** prefixed with `Reasoning:`.
+* `stream` (Telegram only): streams reasoning into the Telegram draft bubble while the reply is generating, then sends the final answer without reasoning.
+* Alias: `/reason`.
+* Send `/reasoning` (or `/reasoning:`) with no argument to see the current reasoning level.
+
+## Related
+
+* Elevated mode docs live in [Elevated mode](/tools/elevated).
+
+## Heartbeats
+
+* Heartbeat probe body is the configured heartbeat prompt (default: `Read HEARTBEAT.md if it exists (workspace context). Follow it strictly. Do not infer or repeat old tasks from prior chats. If nothing needs attention, reply HEARTBEAT_OK.`). Inline directives in a heartbeat message apply as usual (but avoid changing session defaults from heartbeats).
+* Heartbeat delivery defaults to the final payload only. To also send the separate `Reasoning:` message (when available), set `agents.defaults.heartbeat.includeReasoning: true` or per-agent `agents.list[].heartbeat.includeReasoning: true`.
+
+## Web chat UI
+
+* The web chat thinking selector mirrors the session's stored level from the inbound session store/config when the page loads.
+* Picking another level applies only to the next message (`thinkingOnce`); after sending, the selector snaps back to the stored session level.
+* To change the session default, send a `/think:<level>` directive (as before); the selector will reflect it after the next reload.

openclaw-knowhow-skill/docs/tools/web.md

@@ -0,0 +1,28 @@
+# Web Tools Documentation
+
+OpenClaw provides two lightweight web utilities for agent tasks:
+
+## Core Tools
+
+**web_search** enables querying the internet through either Brave Search API or Perplexity Sonar. The default Brave provider returns structured results (title, URL, snippet) while Perplexity offers AI-synthesized answers with citations from real-time web search.
+
+**web_fetch** performs HTTP retrieval and converts HTML to readable markdown or plain text format. It notably does **not** execute JavaScript, making it unsuitable for dynamic content sites requiring browser automation.
+
+## Provider Comparison
+
+The two search options present distinct tradeoffs:
+
+- **Brave** (default): Fast structured output, free tier availability, but traditional search format
+- **Perplexity**: Synthesized responses with source attribution, though requiring separate API access
+
+Configuration specifies your chosen provider through the `tools.web.search.provider` setting.
+
+## Setup Requirements
+
+For Brave, users must create a Brave Search API account at [https://brave.com/search/api/](https://brave.com/search/api/) and select the Data for Search plan. Keys can be stored via `openclaw configure` or environment variables.
+
+Perplexity requires credentials from either direct Perplexity accounts or OpenRouter, which supports crypto, prepaid, or credit card payment options.
+
+## Technical Capabilities
+
+Both tools cache results for 15 minutes by default. web_fetch supports Firecrawl as an optional fallback extractor and respects standard web restrictions like blocking private hostnames.