Terminal Helper — a runbook for OpenClaw exec

This skill is not a “generic terminal tips” template.
It’s a concrete runbook for how to use OpenClaw’s exec tool effectively in a real workspace (like your /Users/.../clawd workspace), with attention to:

• - sandbox vs host execution
• predictable working directories
• long-running processes
• permissions on macOS (Peekaboo, screen recording, UI automation)
• avoiding “accidental shell scripting” disasters

OpenClaw skills are loaded from bundled skills, ~/.openclaw/skills, and <workspace>/skills with workspace taking precedence. :contentReference[oaicite:12]{index=12}

Operating principles (what I will do every time)

1) State the intent + the exact command before running it

Before calling exec, I will say:

• - what the command is intended to do
• what directory it will run in
• what files it might read/write
• what output I expect (so we can spot anomalies)

2) Default to read-only exploration

When debugging or orienting:

• - pwd, ls -la, git status, rg, cat, head, INLINECODE11
• only escalate to writes/installs after we know what’s going on

3) Prefer sandboxed execution for untrusted or high-churn work

Use the sandbox for:

• - tests, builds, dependency installs
• exploring unknown repos
• running scripts from third-party sources

Important nuance:
If a session is sandboxed, the sandbox does not inherit host process.env.
Global env and skills.entries.<skill>.env/apiKey apply to host runs only; sandbox env must be set separately. :contentReference[oaicite:13]{index=13}

4) Explicit confirmation for anything risky

I will require the user to confirm before:

• - deleting or overwriting files
• installing system-level packages
• touching ~/.ssh, keychains, browser profiles
• changing network/system settings
• running privileged commands (sudo, launchctl changes)

Execution patterns (the “how”)

A) Choose a working directory deliberately

When diagnosing OpenClaw itself, I’ll work inside your workspace (example: /Users/proman/clawd) and be explicit about it.

Typical commands:

• - check skills:

- ls -la ./skills
- find ./skills -maxdepth 2 -name SKILL.md -print

• - check git state:

- git status (if the workspace is a git repo)

• - verify binaries:

- INLINECODE20

B) Keep commands single-purpose

Prefer multiple small commands over one “do everything” pipeline. This makes it easier to review and safer to approve.

C) Long-running commands: background + poll

When supported, run with a short yield and then poll a process session.

Examples you can adapt:

• - start a long build:

- exec: make test (with a short yield)

• - poll until completion:

- process: poll (using the returned session id)

(Exact parameter names depend on your tool surface, but the pattern is: yield → poll.)

Practical playbooks

Playbook 1: “My skill isn’t loading”

1) Confirm skill location/precedence: - OpenClaw loads <workspace>/skills and that wins precedence. :contentReference[oaicite:14]{index=14} 2) Verify the skill folder has SKILL.md and valid frontmatter. 3) If you changed files, ensure watcher is enabled: - skills.load.watch: true is the default pattern. :contentReference[oaicite:15]{index=15}

Playbook 2: “Peekaboo works in Terminal but fails in OpenClaw”

This is usually macOS TCC context + daemon behavior. A common fix is enabling PeekabooBridge in OpenClaw.app:

• - Settings → Enable Peekaboo Bridge :contentReference[oaicite:16]{index=16}

Then validate:

• - peekaboo bridge status --verbose should select a host (OpenClaw.app) rather than local (in-process). :contentReference[oaicite:17]{index=17}

Playbook 3: “ClawHub sync rejects my skill docs”

ClawHub has a quality gate (language-aware word counting and heuristics) that rejects docs that are too thin/templated. :contentReference[oaicite:18]{index=18} Fix by adding:

• - concrete examples
• troubleshooting
• environment notes (sandbox, PATH, permissions)
• “what/why/when/how” that is clearly specific to the skill

What I will NOT do

• - I will not run remote “install scripts” (e.g., curl | sh) without explicit user request and review.
• I will not paste or echo secrets into commands.
• I will not make destructive changes without confirming the exact file paths.

Quick commands I often start with

• - INLINECODE29
• INLINECODE30
• INLINECODE31
• INLINECODE32
• INLINECODE33
• INLINECODE34

If you want raw, direct execution (no model involvement), use /term.