Automation Workflow

Create and manage automation workflows for repetitive tasks. Use when user needs to schedule periodic data sync, chain API calls, set up triggered actions, b...

Security Scan

The skill appears to implement a simple workflow runner matching its stated purpose, but there are multiple implementation/documentation mismatches and insecure behaviors (notably disabled TLS verification and undeclared credential expectations) that make it suspicious rather than benign.

Purpose & Capability

The name/description (general-purpose automation: schedules, webhooks, file watchers, queues, storage, email) is broader than the shipped implementation. The Python script implements scheduled workflows, http, telegram, transform, and log actions only; webhook/file/queue triggers and actions like email/storage referenced in SKILL.md are not implemented. The SKILL metadata declares no required credentials while the code expects TELEGRAM_BOT_TOKEN for Telegram actions (and examples include .env use). These mismatches suggest sloppy or incomplete implementation.

Instruction Scope

SKILL.md instructs installing 'schedule' and 'requests' and using YAML placeholders like {{env.CHAT_ID}}. The runner loads an .env file into os.environ and exposes environment in context, but the interpolation implementation is a very simple string replace that does not support nested keys (e.g., {{env.KEY}}) as the docs imply — templates in the docs will often not work as advertised. The script also disables TLS verification for outbound HTTP(s) (ssl.CERT_NONE), which is insecure and increases risk if workflows contact untrusted endpoints. The instructions ask users to put secrets in .env; the code will load whatever file is provided and make network requests, so users could accidentally expose secrets to external endpoints defined in workflows.

Install Mechanism

There is no install spec (instruction-only install). SKILL.md recommends 'pip install schedule requests'. The code imports requests but does not actually use it; this is likely harmless but inconsistent. No downloads or archive extraction are performed.

Credentials

The skill metadata declares no required environment variables, but the code expects TELEGRAM_BOT_TOKEN for Telegram actions and examples show TELEGRAM_BOT_TOKEN and REPORT_CHAT_ID in .env. Requiring a bot token is reasonable for Telegram functionality, but the omission from metadata is a transparency issue. Because the runner can load any .env file the user supplies, there is a risk of inadvertently exposing credentials to workflow-defined HTTP endpoints (especially with TLS verification disabled).

Persistence & Privilege

The skill is not always-enabled and does not request persistent system-wide privileges or modify other skills. It is an instruction-and-script package run by the user; autonomous invocation is allowed (default) which is expected for skills but not an additional flag here.

What to consider before installing

This skill is plausible for running scheduled API calls and sending Telegram messages, but it has several red flags and bugs. Before installing or running: (1) review and fix the code's TLS handling — it disables SSL verification for outbound requests (insecure); (2) do not run it with sensitive credentials until you confirm how templates access environment variables — the template interpolation is simplistic and the docs' {{env.KEY}} usage may not work as expected; (3) the SKILL.md claims features (webhook triggers, file watchers, queue triggers, email/storage actions) that the script does not implement — treat those docs as inaccurate; (4) do not point workflows at untrusted external endpoints or supply real secrets in .env until you confirm where data is sent; (5) consider running in an isolated environment (container or VM) and inspect/patch the code (enable proper TLS verification, implement safe template resolution, and explicitly declare required env vars) before using in production.

Create and manage automation workflows for repetitive tasks.

Quick Start

# Install dependencies
pip install schedule requests

# Run a simple workflow
python scripts/workflow.py examples/simple.yaml

Core Concepts

• Trigger: What starts the workflow (time, webhook, file change)
• Actions: What gets executed (API calls, notifications, data transformations)
• Flow Control: Conditions, loops, error handling

Workflow Format (YAML)

name: daily-report
trigger:
  type: schedule
  cron: "0 9 * * *"  # Daily at 9am

actions:
  - name: fetch-data
    type: http
    config:
      url: https://api.example.com/data
      method: GET
      
  - name: process
    type: transform
    config:
      template: "Report: {{results.count}} items"
      
  - name: notify
    type: telegram
    config:
      chat_id: "{{env.CHAT_ID}}"
      message: "{{processed}}"

Supported Triggers

• schedule: Cron-based scheduling
• webhook: HTTP POST/GET triggers
• file: Watch for file changes
• queue: Message queue triggers

Supported Actions

• http: Make HTTP requests
• telegram: Send Telegram messages
• email: Send emails
• transform: Data transformation
• storage: Save/load data

Usage Examples

See references/examples.md for more.

Daily Report Workflow

name: daily-sales
trigger:
  type: schedule
  cron: "0 8 * * *"
actions:
  - type: http
    name: get-sales
    config:
      url: https://api.shop.com/sales
  - type: transform
    name: format
    config:
      template: "Sales: ${{results.total}}"
  - type: telegram
    name: send
    config:
      message: "{{formatted}}"

Webhook Trigger

name: github-webhook
trigger:
  type: webhook
  path: /webhook/github
actions:
  - type: transform
    name: parse
    config:
      template: "New {{payload.action}} on {{payload.repository}}"

Script Usage

python scripts/workflow.py [OPTIONS]

Options:
  --file PATH      Workflow YAML file (required)
  --run-once       Run workflow once and exit
  --daemon         Run as background daemon
  --env FILE       Load environment variables

Best Practices

1. Use environment variables for secrets
2. Add error handling for each action
3. Log actions for debugging
4. Test workflows with --run-once first