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/agents/agent-loop.md

@@ -0,0 +1,29 @@
+# Agent Loop Documentation - OpenClaw
+
+## Overview
+
+The Agent Loop in OpenClaw represents a complete agent execution cycle, encompassing message intake through final reply persistence. An agentic loop is the full run of an agent: intake, context assembly, model inference, tool execution, streaming replies, and persistence.
+
+## Key Components
+
+**Entry Points:**
+The system accepts agent requests via Gateway RPC (`agent` and `agent.wait` commands) and CLI.
+
+**Execution Flow:**
+The process involves parameter validation, session resolution, metadata persistence, and model inference through the pi-agent-core runtime, which handles serialization and event streaming.
+
+**Queueing System:**
+Runs are serialized per-session to prevent concurrency issues. Runs are serialized per session key (session lane) and optionally through a global lane.
+
+## Extension Mechanisms
+
+OpenClaw provides two hook systems for customization:
+
+1. **Internal Gateway Hooks** - Event-driven scripts for commands and lifecycle events (bootstrap, commands)
+2. **Plugin Hooks** - Extension points including `before_agent_start`, `agent_end`, tool call interception, and message lifecycle events
+
+## Operational Details
+
+- **Timeout defaults:** 30 seconds for `agent.wait`; 600 seconds for agent runtime
+- **Streaming:** Assistant deltas and tool events are emitted as separate streams
+- **Reply handling:** Payloads are assembled from assistant text, tool summaries, and reasoning, with suppression of duplicate messaging tool outputs

openclaw-knowhow-skill/docs/agents/agent-workspace.md

@@ -0,0 +1,28 @@
+# Agent Workspace Documentation
+
+## Overview
+The agent workspace functions as the agent's primary working directory for file operations and contextual memory. It's distinct from `~/.openclaw/`, which handles configuration, credentials, and sessions.
+
+## Key Points
+
+**Location & Configuration**
+The default workspace resides at `~/.openclaw/workspace`. Users can customize this path via the `openclaw.json` configuration file or by setting the `OPENCLAW_PROFILE` environment variable.
+
+**Important Security Note**
+The workspace isn't a hard sandbox by default. While tools resolve relative paths within it, absolute paths can access other host directories unless sandboxing is explicitly enabled through `agents.defaults.sandbox`.
+
+**Standard Files**
+The workspace contains several bootstrap files including:
+- `AGENTS.md` - operating guidelines and behavioral rules
+- `SOUL.md` - persona and boundaries
+- `USER.md` - user identification details
+- `IDENTITY.md` - agent name and identity markers
+- `memory/` directory - daily logs organized by date
+
+## Backup Strategy
+
+Documentation recommends maintaining a **private git repository** for workspace backup. Critical reminders include:
+
+Even in a private repo, avoid storing secrets in the workspace: API keys, OAuth tokens, passwords, or private credentials.
+
+This protective measure ensures sensitive information remains separate from version control while preserving essential memory structures through regular commits.

openclaw-knowhow-skill/docs/agents/agent.md

@@ -0,0 +1,28 @@
+# Agent Runtime Documentation
+
+## Overview
+OpenClaw operates a single embedded agent runtime based on pi-mono, utilizing a workspace directory as the primary working environment for tools and contextual operations.
+
+## Key Components
+
+**Workspace Structure**: The system requires a designated workspace (`agents.defaults.workspace`) serving as the sole working directory. The setup process creates `~/.openclaw/openclaw.json` and initializes necessary files.
+
+**Bootstrap Files**: On initial session startup, OpenClaw injects several user-editable files:
+- `AGENTS.md` - operational guidelines
+- `SOUL.md` - personality definition
+- `TOOLS.md` - tool usage documentation
+- `IDENTITY.md` - agent identification
+- `USER.md` - user preferences
+- `BOOTSTRAP.md` - first-run setup (removed after completion)
+
+## Tools & Skills
+
+Core tools for file operations are built-in and always available. Skills load from three locations with workspace taking precedence: bundled skills, managed local skills, and workspace-specific skills.
+
+## Session Management
+
+Session transcripts are stored as JSONL at `~/.openclaw/agents/<agentId>/sessions/` with stable, OpenClaw-assigned session identifiers.
+
+## Configuration
+
+Model references require `provider/model` formatting. Minimum configuration includes workspace path and WhatsApp channel allowlist settings.

openclaw-knowhow-skill/docs/agents/multi-agent.md

@@ -0,0 +1,32 @@
+# Multi-Agent Routing Documentation
+
+## Core Concept
+
+OpenClaw supports running multiple isolated agents (separate workspace + `agentDir` + sessions), plus multiple channel accounts within a single Gateway instance. Messages are routed to appropriate agents via bindings.
+
+## What Defines an Agent
+
+An agent comprises:
+- Its own workspace (files, configuration documents, notes)
+- Dedicated state directory (`agentDir`) for auth and configuration
+- Isolated session store for chat history
+
+Auth profiles are per-agent. Each agent reads from its own dedicated `auth-profiles.json` location, preventing credential sharing unless explicitly copied.
+
+## Key Path Structure
+
+- Config: `~/.openclaw/openclaw.json`
+- Workspace: `~/.openclaw/workspace` (or agent-specific variant)
+- Sessions: `~/.openclaw/agents/<agentId>/sessions`
+
+## Routing Mechanism
+
+Bindings follow deterministic matching with most-specific wins priority. Priority follows this order: peer match, `guildId`, `teamId`, `accountId`, channel-level match, then fallback to default agent.
+
+## Multi-Account Scenarios
+
+Users can route different WhatsApp accounts to separate agents, or split a single account's DMs across multiple agents by matching sender E.164 identifiers with `peer.kind: "dm"`.
+
+## Security Features
+
+As of v2026.1.6, agents support per-agent sandbox modes and tool restrictions. Different permissions per agent enable security isolation while maintaining flexibility across your Gateway deployment.

openclaw-knowhow-skill/docs/agents/subagents.md

@@ -0,0 +1,46 @@
+# Sub-Agents Documentation
+
+## Overview
+
+Sub-agents are background agent processes spawned from a parent agent run. They execute in isolated sessions and report results back to the requesting chat channel upon completion.
+
+## Key Commands
+
+The `/subagents` slash command manages sub-agent runs:
+- `list`: View all active sub-agents
+- `stop`: Terminate specific or all sub-agents
+- `log`: Access execution logs with optional filters
+- `info`: Display run metadata and session details
+- `send`: Transmit messages to running sub-agents
+
+## Spawning Sub-Agents
+
+The `sessions_spawn` tool initiates sub-agent runs with these parameters:
+- `task` (required): The work assignment
+- `label`, `agentId`, `model`, `thinking`: Optional configuration overrides
+- `runTimeoutSeconds`: Execution time limit
+- `cleanup`: Archive behavior (`delete` or `keep`)
+
+## Design Principles
+
+Sub-agents do not get session tools by default, maintaining security boundaries. They cannot spawn their own sub-agents, preventing cascade complexity. Each maintains separate token accounting for cost management.
+
+## Session Management
+
+Sub-agent sessions use the format `agent:<agentId>:subagent:<uuid>`. Authentication resolves through the target agent's configuration, with main agent profiles available as fallbacks. Sessions auto-archive after 60 minutes by default.
+
+## Announce Mechanism
+
+Upon completion, sub-agents report results through an announce step. These messages include:
+- Status (success, error, timeout, unknown)
+- Result summary from the announce step
+- Error details and contextual notes
+- Runtime metrics and token usage statistics
+
+## Tool Restrictions
+
+By default, sub-agents cannot access session-specific tools like `sessions_list`, `sessions_history`, `sessions_send`, or `sessions_spawn`. Administrators can customize allowed tools through configuration.
+
+## Concurrency & Performance
+
+Sub-agents operate on a dedicated queue lane with configurable maximum concurrent runs (default: 8). Each maintains independent context and resource usage for cost optimization on heavy workloads.