OpenClaw Manager

Overview

Build and operate OpenClaw with production-safe defaults across both local and hosted environments. This skill is optimized for operators with limited platform expertise and enforces hard security gates before rollout completion.

Primary references:

• - Docs map: INLINECODE0
• Security gates checklist: INLINECODE1
• Mode matrix: INLINECODE2
• OS matrix: INLINECODE3
• Integrations playbook: INLINECODE4
• Ops ledger schema: INLINECODE5

Automation helpers:

• - INLINECODE6
• INLINECODE7
• INLINECODE8

Default ops ledger path:

• - ./openclaw-manager-operations-ledger.md (or operator specified)

Hard-Stop Rules (Never Bypass)

Stop and block deployment/install progression if any condition is true:

1. 1. Required secrets profile fails validation.
2. Security checklist mandatory gates are not all passing.
3. Rollback path is not documented and owned.
4. Ops ledger was not updated for the current phase.
5. Public exposure requested without auth boundary and token controls.

Workflow

1) Intake and Scope Lock

Collect and confirm:

• - mode: local or INLINECODE12
• INLINECODE13: local, fly, render, railway, hetzner, INLINECODE19
• INLINECODE20: macos, linux, INLINECODE23
• INLINECODE24: subset of telegram, discord, INLINECODE27
• INLINECODE28: subset of email, INLINECODE30
• INLINECODE31: dev, staging, INLINECODE34
• INLINECODE35: private or INLINECODE37

Before proceeding, write a scope_lock ledger entry:

CODEBLOCK0

2) Generate a Decision-Complete Plan

Always generate a plan first:

CODEBLOCK1

The plan output is the execution contract. Do not skip sections.

3) Validate Secrets and Config Profile Before Any Infra Change

Validate environment using profile-aware gates:

CODEBLOCK2

Validation enforces:

• - required keys by profile
• required provider/model alternatives
• malformed and duplicate env keys
• placeholder values
• weak gateway/setup tokens
• legacy alias warnings

Write a predeploy_validation ledger entry immediately after validation.

4) Execute Mode Branch

Branch A: Local install (mode=local)

1. 1. Use official install/onboarding docs for local setup.
2. Apply OS-specific commands from references/openclaw-os-matrix.md.
3. Validate startup, persistence path, and local auth boundaries.
4. If local public exposure is requested, apply gateway hardening gates from security checklist first.

Branch B: Hosted clone + deploy (mode=hosted)

1. 1. Clone the selected OpenClaw source repo.
2. Follow provider playbook from references/openclaw-doc-map.md.
3. Configure persistent storage before production traffic.
4. Configure ingress/auth, secrets, and health checks.
5. Verify runtime logs for startup/auth errors and secret leakage.

Write a deploy_complete ledger entry once deployment/install is complete.

5) Configure Channels and Integrations Safely

For each selected channel/integration:

• - inject credentials via secret manager/env only
• run a minimal smoke test
• verify auth boundaries and error logging safety

Track each item as:

• - INLINECODE45
• INLINECODE46
• INLINECODE47

Use references/openclaw-integrations-playbook.md for email/calendar specifics.

6) Agent + Memory Baseline

Document and validate:

• - memory persistence strategy
• retention expectations
• restart and recovery behavior
• agent behavior boundaries

Update ledger with operational baseline decisions.

7) Mandatory Security Gate

Run references/openclaw-security-checklist.md and produce pass/fail per gate.

No go-live if any mandatory gate fails.

Write a security_gate ledger entry with explicit blockers (if any).

8) Handover and Incident Readiness

Produce:

• - provider status summary
• channel + integration matrix
• security gate table
• rollback and escalation ownership
• follow-up actions by risk order

Write handover ledger entry. For incidents/troubleshooting, append incident entries as events happen.

Output Contract

Always return:

1. 1. Mode/provider/OS/environment status summary
2. Security gate results (hard pass/fail)
3. Channel + integration matrix
4. Agent + memory configuration summary
5. Ops ledger update confirmation (event names written)
6. Follow-up actions ordered by risk