vultr/openclaw
1
0
Fork 0
mirror of https://github.com/openclaw/openclaw.git synced 2026-05-06 05:30:42 +00:00
Code Issues Packages Projects Releases Wiki Activity

docs: typography hygiene across 5 pages

Browse Source 
Replaced 80 typography characters (curly quotes, apostrophes, em/en
dashes, non-breaking hyphens) with ASCII equivalents per
docs/CLAUDE.md heading and content hygiene rules.

- docs/plugins/sdk-entrypoints.md: 17 chars
- docs/help/index.md: 17 chars
- docs/concepts/agent-workspace.md: 16 chars
- docs/tools/lobster.md: 15 chars
- docs/tools/exec-approvals.md: 15 chars
This commit is contained in:
Vincent Koc
2026-05-05 20:04:12 -07:00
parent 49c4a13231
commit fafd76c5e6
5 changed files with 78 additions and 78 deletions
Download Patch File Download Diff File Expand all files Collapse all files

32
docs/concepts/agent-workspace.md
View File

@@ -60,40 +60,40 @@ Older installs may have created `~/openclaw`. Keeping multiple workspace directo
These are the standard files OpenClaw expects inside the workspace:
<AccordionGroup>
<Accordion title="AGENTS.md — operating instructions">
<Accordion title="AGENTS.md - operating instructions">
Operating instructions for the agent and how it should use memory. Loaded at the start of every session. Good place for rules, priorities, and "how to behave" details.
</Accordion>
<Accordion title="SOUL.md — persona and tone">
<Accordion title="SOUL.md - persona and tone">
Persona, tone, and boundaries. Loaded every session. Guide: [SOUL.md personality guide](/concepts/soul).
</Accordion>
<Accordion title="USER.md — who the user is">
<Accordion title="USER.md - who the user is">
Who the user is and how to address them. Loaded every session.
</Accordion>
<Accordion title="IDENTITY.md — name, vibe, emoji">
<Accordion title="IDENTITY.md - name, vibe, emoji">
The agent's name, vibe, and emoji. Created/updated during the bootstrap ritual.
</Accordion>
<Accordion title="TOOLS.md — local tool conventions">
<Accordion title="TOOLS.md - local tool conventions">
Notes about your local tools and conventions. Does not control tool availability; it is only guidance.
</Accordion>
<Accordion title="HEARTBEAT.md — heartbeat checklist">
<Accordion title="HEARTBEAT.md - heartbeat checklist">
Optional tiny checklist for heartbeat runs. Keep it short to avoid token burn.
</Accordion>
<Accordion title="BOOT.md — startup checklist">
<Accordion title="BOOT.md - startup checklist">
Optional startup checklist run automatically on gateway restart (when [internal hooks](/automation/hooks) are enabled). Keep it short; use the message tool for outbound sends.
</Accordion>
<Accordion title="BOOTSTRAP.md — first-run ritual">
<Accordion title="BOOTSTRAP.md - first-run ritual">
One-time first-run ritual. Only created for a brand-new workspace. Delete it after the ritual is complete.
</Accordion>
<Accordion title="memory/YYYY-MM-DD.md — daily memory log">
<Accordion title="memory/YYYY-MM-DD.md - daily memory log">
Daily memory log (one file per day). Recommended to read today + yesterday on session start.
</Accordion>
<Accordion title="MEMORY.md — curated long-term memory (optional)">
<Accordion title="MEMORY.md - curated long-term memory (optional)">
Curated long-term memory. Only load in the main, private session (not shared/group contexts). See [Memory](/concepts/memory) for the workflow and automatic memory flush.
</Accordion>
<Accordion title="skills/ — workspace skills (optional)">
<Accordion title="skills/ - workspace skills (optional)">
Workspace-specific skills. Highest-precedence skill location for that workspace. Overrides project agent skills, personal agent skills, managed skills, bundled skills, and `skills.load.extraDirs` when names collide.
</Accordion>
<Accordion title="canvas/ — Canvas UI files (optional)">
<Accordion title="canvas/ - Canvas UI files (optional)">
Canvas UI files for node displays (for example `canvas/index.html`).
</Accordion>
</AccordionGroup>
@@ -224,7 +224,7 @@ Suggested `.gitignore` starter:
## Related
- [Heartbeat](/gateway/heartbeat) — HEARTBEAT.md workspace file
- [Sandboxing](/gateway/sandboxing) — workspace access in sandboxed environments
- [Session](/concepts/session) — session storage paths
- [Standing orders](/automation/standing-orders) — persistent instructions in workspace files
- [Heartbeat](/gateway/heartbeat) - HEARTBEAT.md workspace file
- [Sandboxing](/gateway/sandboxing) - workspace access in sandboxed environments
- [Session](/concepts/session) - session storage paths
- [Standing orders](/automation/standing-orders) - persistent instructions in workspace files

34
docs/help/index.md
View File

@@ -8,32 +8,32 @@ title: "Help"
Quick "get unstuck" path for the most common problems:
- [Troubleshooting](/help/troubleshooting) — symptom-first decision tree
- [Debugging](/help/debugging) — watch mode, raw streams, dev profile
- [Install sanity](/install/node#troubleshooting) — Node / npm / PATH checks
- [Gateway troubleshooting](/gateway/troubleshooting) — gateway-specific issues
- [Doctor](/gateway/doctor) — automated repair + diagnostic bundle
- [Troubleshooting](/help/troubleshooting) - symptom-first decision tree
- [Debugging](/help/debugging) - watch mode, raw streams, dev profile
- [Install sanity](/install/node#troubleshooting) - Node / npm / PATH checks
- [Gateway troubleshooting](/gateway/troubleshooting) - gateway-specific issues
- [Doctor](/gateway/doctor) - automated repair + diagnostic bundle
## FAQ
- [FAQ](/help/faq) — day-to-day concepts and operational questions
- [First-run FAQ](/help/faq-first-run) — install, onboard, auth, subscriptions, early failures
- [Models FAQ](/help/faq-models) — model selection, failover, auth profiles
- [FAQ](/help/faq) - day-to-day concepts and operational questions
- [First-run FAQ](/help/faq-first-run) - install, onboard, auth, subscriptions, early failures
- [Models FAQ](/help/faq-models) - model selection, failover, auth profiles
## Diagnostics
- [Environment variables](/help/environment) — where OpenClaw loads env vars and precedence
- [Diagnostics flags](/diagnostics/flags) — runtime diagnostics and verbose modes
- [Node + tsx crash](/debug/node-issue) — specific Node / tsx runtime crash scenarios
- [Environment variables](/help/environment) - where OpenClaw loads env vars and precedence
- [Diagnostics flags](/diagnostics/flags) - runtime diagnostics and verbose modes
- [Node + tsx crash](/debug/node-issue) - specific Node / tsx runtime crash scenarios
## Testing
- [Testing](/help/testing) — test suites and Docker runners
- [Update and plugin tests](/help/testing-updates-plugins) — package update, migration, and plugin install validation
- [Live tests](/help/testing-live) — network-touching provider and CLI smokes
- [Testing](/help/testing) - test suites and Docker runners
- [Update and plugin tests](/help/testing-updates-plugins) - package update, migration, and plugin install validation
- [Live tests](/help/testing-live) - network-touching provider and CLI smokes
## Community and meta
- [OpenClaw lore](/start/lore) — the story
- [Docs hubs](/start/hubs) — how this documentation is organized
- [Docs directory](/start/docs-directory) — full file map
- [OpenClaw lore](/start/lore) - the story
- [Docs hubs](/start/hubs) - how this documentation is organized
- [Docs directory](/start/docs-directory) - full file map

34
docs/plugins/sdk-entrypoints.md
View File

@@ -71,12 +71,12 @@ export default definePluginEntry({
| Field | Type | Required | Default |
| -------------- | ---------------------------------------------------------------- | -------- | ------------------- |
| `id` | `string` | Yes | — |
| `name` | `string` | Yes | — |
| `description` | `string` | Yes | — |
| `kind` | `string` | No | — |
| `id` | `string` | Yes | - |
| `name` | `string` | Yes | - |
| `description` | `string` | Yes | - |
| `kind` | `string` | No | - |
| `configSchema` | `OpenClawPluginConfigSchema \| () => OpenClawPluginConfigSchema` | No | Empty object schema |
| `register` | `(api: OpenClawPluginApi) => void` | Yes | — |
| `register` | `(api: OpenClawPluginApi) => void` | Yes | - |
- `id` must match your `openclaw.plugin.json` manifest.
- `kind` is for exclusive slots: `"memory"` or `"context-engine"`.
@@ -112,14 +112,14 @@ export default defineChannelPluginEntry({
| Field | Type | Required | Default |
| --------------------- | ---------------------------------------------------------------- | -------- | ------------------- |
| `id` | `string` | Yes | — |
| `name` | `string` | Yes | — |
| `description` | `string` | Yes | — |
| `plugin` | `ChannelPlugin` | Yes | — |
| `id` | `string` | Yes | - |
| `name` | `string` | Yes | - |
| `description` | `string` | Yes | - |
| `plugin` | `ChannelPlugin` | Yes | - |
| `configSchema` | `OpenClawPluginConfigSchema \| () => OpenClawPluginConfigSchema` | No | Empty object schema |
| `setRuntime` | `(runtime: PluginRuntime) => void` | No | — |
| `registerCliMetadata` | `(api: OpenClawPluginApi) => void` | No | — |
| `registerFull` | `(api: OpenClawPluginApi) => void` | No | — |
| `setRuntime` | `(runtime: PluginRuntime) => void` | No | - |
| `registerCliMetadata` | `(api: OpenClawPluginApi) => void` | No | - |
| `registerFull` | `(api: OpenClawPluginApi) => void` | No | - |
- `setRuntime` is called during registration so you can store the runtime reference
(typically via `createPluginRuntimeStore`). It is skipped during CLI metadata
@@ -275,8 +275,8 @@ Use `openclaw plugins inspect <id>` to see a plugin's shape.
## Related
- [SDK Overview](/plugins/sdk-overview) — registration API and subpath reference
- [Runtime Helpers](/plugins/sdk-runtime) — `api.runtime` and `createPluginRuntimeStore`
- [Setup and Config](/plugins/sdk-setup) — manifest, setup entry, deferred loading
- [Channel Plugins](/plugins/sdk-channel-plugins) — building the `ChannelPlugin` object
- [Provider Plugins](/plugins/sdk-provider-plugins) — provider registration and hooks
- [SDK Overview](/plugins/sdk-overview) - registration API and subpath reference
- [Runtime Helpers](/plugins/sdk-runtime) - `api.runtime` and `createPluginRuntimeStore`
- [Setup and Config](/plugins/sdk-setup) - manifest, setup entry, deferred loading
- [Channel Plugins](/plugins/sdk-channel-plugins) - building the `ChannelPlugin` object
- [Provider Plugins](/plugins/sdk-provider-plugins) - provider registration and hooks

30
docs/tools/exec-approvals.md
View File

@@ -18,7 +18,7 @@ skips approvals).
<Note>
Effective policy is the **stricter** of `tools.exec.*` and approvals
defaults; if an approvals field is omitted, the `tools.exec` value is
used. Host exec also uses local approvals state on that machine — a
used. Host exec also uses local approvals state on that machine - a
host-local `ask: "always"` in `~/.openclaw/exec-approvals.json` keeps
prompting even if session or config defaults request `ask: "on-miss"`.
</Note>
@@ -116,18 +116,18 @@ Example schema:
### `exec.security`
<ParamField path="security" type='"deny" | "allowlist" | "full"'>
- `deny` — block all host exec requests.
- `allowlist` — allow only allowlisted commands.
- `full` — allow everything (equivalent to elevated).
- `deny` - block all host exec requests.
- `allowlist` - allow only allowlisted commands.
- `full` - allow everything (equivalent to elevated).
</ParamField>
### `exec.ask`
<ParamField path="ask" type='"off" | "on-miss" | "always"'>
- `off` — never prompt.
- `on-miss` — prompt only when the allowlist does not match.
- `always` — prompt on every command. `allow-always` durable trust does **not** suppress prompts when effective ask mode is `always`.
- `off` - never prompt.
- `on-miss` - prompt only when the allowlist does not match.
- `always` - prompt on every command. `allow-always` durable trust does **not** suppress prompts when effective ask mode is `always`.
</ParamField>
@@ -136,9 +136,9 @@ Example schema:
<ParamField path="askFallback" type='"deny" | "allowlist" | "full"'>
Resolution when a prompt is required but no UI is reachable.
- `deny` — block.
- `allowlist` — allow only if allowlist matches.
- `full` — allow.
- `deny` - block.
- `allowlist` - allow only if allowlist matches.
- `full` - allow.
</ParamField>
@@ -168,7 +168,7 @@ automatically.
## YOLO mode (no-approval)
If you want host exec to run without approval prompts, you must open
**both** policy layers — requested exec policy in OpenClaw config
**both** policy layers - requested exec policy in OpenClaw config
(`tools.exec.*`) **and** host-local approvals policy in
`~/.openclaw/exec-approvals.json`.
@@ -194,7 +194,7 @@ CLI-backed providers that expose their own noninteractive permission mode
can follow this policy. Claude CLI adds
`--permission-mode bypassPermissions` when OpenClaw's requested exec
policy is YOLO. Override that backend behavior with explicit Claude args
under `agents.defaults.cliBackends.claude-cli.args` / `resumeArgs` —
under `agents.defaults.cliBackends.claude-cli.args` / `resumeArgs` -
for example `--permission-mode default`, `acceptEdits`, or
`bypassPermissions`.
@@ -365,7 +365,7 @@ skill bin list. Disable this if you want strict manual allowlists.
For safe bins (the stdin-only fast-path), interpreter binding details, and
how to forward approval prompts to Slack/Discord/Telegram (or run them as
native approval clients), see
[Exec approvals — advanced](/tools/exec-approvals-advanced).
[Exec approvals - advanced](/tools/exec-approvals-advanced).
## Control UI editing
@@ -379,7 +379,7 @@ Nodes must advertise `system.execApprovals.get/set` (macOS app or
headless node host). If a node does not advertise exec approvals yet,
edit its local `~/.openclaw/exec-approvals.json` directly.
CLI: `openclaw approvals` supports gateway or node editing — see
CLI: `openclaw approvals` supports gateway or node editing - see
[Approvals CLI](/cli/approvals).
## Approval flow
@@ -435,7 +435,7 @@ run.
## Related
<CardGroup cols={2}>
<Card title="Exec approvals — advanced" href="/tools/exec-approvals-advanced" icon="gear">
<Card title="Exec approvals - advanced" href="/tools/exec-approvals-advanced" icon="gear">
Safe bins, interpreter binding, and approval forwarding to chat.
</Card>
<Card title="Exec tool" href="/tools/exec" icon="terminal">

26
docs/tools/lobster.md
View File

@@ -26,9 +26,9 @@ Today, complex workflows require many back-and-forth tool calls. Each call costs
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.
- **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.
@@ -39,7 +39,7 @@ If the pipeline pauses for approval, the tool returns a `resumeToken` so you can
## 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.)
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
@@ -148,7 +148,7 @@ steps:
Notes:
- `stdin: $step.stdout` and `stdin: $step.json` pass a prior step’s output.
- `stdin: $step.stdout` and `stdin: $step.json` pass a prior step's output.
- `condition` (or `when`) can gate steps on `$step.approved`.
## Install Lobster
@@ -317,10 +317,10 @@ OpenProse pairs well with Lobster: use `/prose` to orchestrate multi-agent prep,
## Safety
- **Local in-process only** — workflows execute inside the gateway process; 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** — timeouts and output caps enforced by the embedded runner.
- **Local in-process only** - workflows execute inside the gateway process; 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** - timeouts and output caps enforced by the embedded runner.
## Troubleshooting
@@ -336,13 +336,13 @@ OpenProse pairs well with Lobster: use `/prose` to orchestrate multi-agent prep,
## 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.
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)
## Related
- [Automation & Tasks](/automation) — scheduling Lobster workflows
- [Automation Overview](/automation) — all automation mechanisms
- [Tools Overview](/tools) — all available agent tools
- [Automation & Tasks](/automation) - scheduling Lobster workflows
- [Automation Overview](/automation) - all automation mechanisms
- [Tools Overview](/tools) - all available agent tools