Workflow
ReviewAudited by ClawScan on May 10, 2026.
Overview
This is a coherent instruction-only workflow builder, but it can guide the agent to create persistent scripts that use API credentials and store workflow data.
Use this skill if you want local workflow automation. Before enabling a generated workflow, review its script, config, schedule, webhook route, and stored credentials; start with dry-run mode; use least-privilege API tokens; and periodically clean or inspect state, data, and logs.
Findings (5)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
A generated workflow can perform real actions on the machine or through APIs when run.
The skill tells the agent/user how to create executable workflow scripts. That is central to the workflow-building purpose, but generated scripts can run shell commands and make network calls.
touch .../{flow.md,config.yaml,run.sh,CHANGELOG.md}; chmod +x .../run.shReview each generated `run.sh`, run `--dry-run` first, and only execute scripts that match the intended workflow.
Workflows may act with the privileges of stored API keys or OAuth tokens.
The workflow pattern includes reading service credentials from the local Keychain. This is expected for API integrations, but it grants workflows access to whatever tokens the user stores for them.
Secrets in macOS Keychain (`security find-generic-password`)
Use dedicated least-privilege tokens, verify secret names before use, and avoid storing broad account credentials for generic workflows.
Local workflow files may retain sensitive payloads or stale state that affects later runs.
The skill deliberately stores state, logs, and intermediate data between runs. This is purpose-aligned, but those files can contain workflow inputs, outputs, or private operational data.
State: `flows/{name}/state/` ... Logs: `flows/{name}/logs/` ... Data: `flows/{name}/data/`Do not write secrets to logs or data files, set retention/cleanup rules, and inspect state files before reusing or sharing a workspace.
If webhook validation is incomplete, an external caller could trigger workflows or inject unexpected payloads.
The webhook pattern accepts external payloads and starts local workflows. The docs mention signature and timestamp validation, but the sample router leaves that as implementation work.
Configure in external service to POST to: `https://your-server/webhooks/{workflow}` ... Trigger workflow ... `(cd ... && ./run.sh) &`Implement signature verification, timestamp checks, event allowlists, and workflow-path allowlists before exposing any webhook route.
A workflow may keep running on a schedule or in response to events without further manual invocation.
The lifecycle guide includes cron scheduling, and other files describe webhooks and file watchers. Persistent automation is disclosed and purpose-aligned, but it can continue operating after setup.
0 8 * * * cd /path/to/workflows/flows/my-workflow && ./run.sh >> /dev/null 2>&1
Enable schedules or watchers only when requested, document them, monitor logs, and remove cron/webhook/file-watcher entries when no longer needed.