Workflow Automator

First run vs scheduled runs

• First run of any workflow: human approval per step (always)
• Subsequent scheduled runs: autonomous (no approval needed)
• You can switch any workflow back to "approval mode" anytime
• Plan integrity: When a plan is approved, its SHA-256 hash is recorded. Autonomous runs verify the hash before execution. If the plan file has been modified since approval, execution is blocked and you are alerted.
• Approval expiry: Plan approvals expire after a configurable TTL (default 30 days). Expired approvals must be renewed to continue autonomous execution. This forces periodic review of running workflows.
• Run budgets: Approvals can set a max number of autonomous runs. Once exhausted, the workflow pauses until re-approved.
• Audit log: Every execution (interactive and autonomous) is recorded in an append-only audit log at ~/.openclaw/workflow-automator/audit.log. Use audit-log.sh read --failures to review failed runs or audit-log.sh stats for a summary.
• Session age guard: Before autonomous browser steps, the session age is checked. Sessions older than a configurable max (default 7 days) are blocked, and the user is asked to re-authenticate. Set max_session_age_days in the plan to override.
• Per-workflow browser isolation: Each workflow gets its own browser profile directory under ~/.openclaw/workflow-automator/sessions/. One workflow's cookies cannot leak to another.
• Post-run session cleanup: Plans can declare "clear_session": true to wipe browser cookies/localStorage after the last step completes. Use for one-time tasks that should not leave a logged-in session behind.
• Restricted command mode: Plans can declare "restricted_mode": true. In this mode, only commands listed in allowed_commands can run (warnings become hard blocks), and inline interpreter execution (e.g. inline scripting language execution) is forbidden.
• Encoding detection: validate-plan.sh flags commands containing obfuscation patterns: base64, eval, exec, hex escapes (\x).
• Risk scoring: Every plan receives a risk score (LOW/MEDIUM/HIGH) based on shell commands, browser steps, and file writes. High-risk plans require --force to approve immediately.
• Approval summary: When approving a plan, a detailed summary is shown: number of shell commands, browser actions, file writes, URLs accessed, and risk score. Forces the reviewer to see exactly what they're approving.
• Runtime command validation: Every command is validated at execution time in BOTH interactive and autonomous modes. Destructive patterns are always hard-blocked. In autonomous mode, exfiltration and encoding patterns are also hard-blocked. In interactive mode, dangerous patterns trigger a secondary confirmation prompt — the user must type CONFIRM to proceed, ensuring they explicitly acknowledge the risk rather than rubber-stamping through a generic approval.
• Hardened file permissions: Session directories, approval records, and browser profiles are set to owner-only access (chmod 700/600). Other users on the system cannot read session cookies or approval data.
• Auto-expiry of stale sessions: The cron heartbeat (check-schedules.sh) automatically wipes browser sessions older than 7 days. Stale cookies don't accumulate on disk indefinitely.
• Data inventory and purge: data-inventory.sh show displays all persistent data with disk usage, permissions, and sensitivity levels. data-inventory.sh purge <category> deletes data by category. data-inventory.sh purge-workflow <name> removes all traces of a workflow.
• Sensitive site blocking: validate-plan.sh blocks browser automation of financial, banking, payment, and investment sites (Chase, PayPal, Coinbase, etc.). These sites cannot be automated even with approval.

During execution

• Each step runs with a 60-second timeout (browser steps: 120 seconds)
• I capture all output (stdout, stderr, screenshots)
• I show you the results immediately after each step

After each step

• I show: what ran, what it produced, whether it succeeded or failed
• On first run: "Continue to next step?" before proceeding
• On scheduled run: proceed automatically unless an error occurs

Logging

All runs are logged to ~/.openclaw/workflow-automator/runs/

Safety

I will refuse to execute commands that:

• Delete system files or recursive force-delete (rm -rf /)
• Format disks or overwrite block devices
• Escalate privileges without explicit intent
• Modify system configuration files

Plan Format

When I present your workflow plan, it looks like this:

WORKFLOW PLAN: [Your description]
SCHEDULE: Every Monday at 8:00 AM CST (cron: 0 8 * * 1)
NOTIFY: Telegram on completion, WhatsApp on failure
ALLOWED SITES: stripe.com, docs.google.com (browser scope)
═══════════════════════════════════════════════

Step 1 of N: [Description]
  Type:   [step type from classification table]
  Input:  [source]
  Output: [destination]
  Command: [exact command or browser action]

Step 2 of N: [Description]
  Type:   [step type]
  Input:  [source — may reference Step 1 output]
  Output: [destination]
  Command: [exact command or browser action]

...

APPROVE this plan and schedule? (yes / edit / reject)

Execution Output Format

After each step executes:

STEP 1 of N: [Description]
─────────────────────────
Command:  [what ran]
Status:   SUCCESS (exit code 0) | FAILED (exit code N)
Duration: [seconds]

Output:
  [stdout, truncated to 50 lines — full output saved to log]

Errors:
  [stderr, if any]

→ Continue to Step 2? (yes / no / retry)

Completion Summary

After all steps finish:

WORKFLOW COMPLETE: [Name]
═════════════════════════
Total steps:  N
Passed:       N
Failed:       N
Duration:     [total time]

Files created/modified:
  - [list of output files]

Schedule: Next run Monday March 24 at 8:00 AM CST
Notification: Results will be sent to Telegram

Status: Workflow completed successfully.

Conditional Workflows

If your workflow has branches ("if X then Y, else Z"), I handle it like this:

Step 3 of N: Check condition
  Type:   condition
  Input:  [what to check]
  Check:  [the condition]
  If TRUE  → proceed to Step 4a
  If FALSE → proceed to Step 4b

Step 4a: [Action if true]
  ...

Step 4b: [Action if false]
  ...

Step 5: [Continues from whichever branch executed]

I show you which branch was taken and why.

What I Can Do (Phase 2)

• Read, write, transform, merge any local files
• Parse JSON (via jq) and CSV (via awk/csvtool)
• Run shell commands and scripts
• Call APIs via curl
• Send you results on any messaging channel OpenClaw supports
• Handle conditional logic (if/then/else)
• Chain steps together with data flowing between them
• Open Chrome and navigate websites
• Log into web apps (using saved browser sessions)
• Extract data from web pages
• Take screenshots
• Run workflows on any schedule (one-time or recurring)
• Manage schedules conversationally (list, pause, resume, change, cancel)
• Alert you on any channel when something fails
• Retry transient failures automatically

What I Cannot Do Yet

• Undo completed steps — No rollback mechanism yet (coming in Phase 3)
• Pre-built workflow templates — Coming in Phase 3
• Full audit log with search — Coming in Phase 3
• Multi-channel escalation chains — Coming in Phase 3

Platform Requirements

Required binaries

This skill requires the following tools in the runtime environment: bash, jq, shasum (or sha256sum), date, grep, sed, awk, mktemp, curl, bc. Optional: timeout/gtimeout (for step timeouts), wkhtmltopdf (for PDF invoice generation).

Run check-environment.sh --verbose to verify your environment before first use. The preflight check runs automatically on each workflow execution and caches the result for one hour.

Runtime dependencies

This skill depends on the OpenClaw runtime for the following:

• Messaging delivery: notify.sh outputs structured JSON describing the notification (channel, message, urgency). The OpenClaw agent runtime is responsible for delivering to WhatsApp/Telegram/Slack/email using platform-managed credentials. This skill does NOT store or request messaging API tokens.
• Cron invocation: check-schedules.sh must be called by an external cron mechanism (OpenClaw's cron system or system crontab). This skill manages schedule JSON files but does not install crontab entries itself.
• Browser profile management: Chrome instances and persistent login sessions are managed by the OpenClaw platform. This skill emits browser action JSON instructions; the platform drives the actual CDP session.

Credential and data storage disclosure

All credentials and data paths are declared in the SKILL.md frontmatter (platform_credentials, user_credentials, data_directories).

• This skill does NOT store API tokens or passwords in files or logs.
• Browser sessions (cookies/localStorage) persist on disk at ~/.openclaw/workflow-automator/sessions/ with owner-only permissions (chmod 700) and auto-expire after 7 days.
• Approval records are stored with owner-only permissions (chmod 700).
• No credentials are embedded in workflow plans or schedule files.

Tips for Best Results

• Be specific about file paths, output files, messaging channels, and website URLs
• State your schedule clearly: "Every Monday at 8am" not "regularly"
• Break big workflows into pieces: start with the first 5 steps