From crayon
How to trigger workflows and nodes. Covers MCP tools (run_workflow, run_node), HTTP webhooks (async/sync), authentication, and cron scheduling.
npx claudepluginhub timescale/crayon --plugin crayonThis skill uses the workspace's default tool permissions.
Crayon workflows can be triggered via MCP tools, HTTP webhooks, or cron schedules.
Verifies tests pass on completed feature branch, presents options to merge locally, create GitHub PR, keep as-is or discard; executes choice and cleans up worktree.
Guides root cause investigation for bugs, test failures, unexpected behavior, performance issues, and build failures before proposing fixes.
Writes implementation plans from specs for multi-step tasks, mapping files and breaking into TDD bite-sized steps before coding.
Crayon workflows can be triggered via MCP tools, HTTP webhooks, or cron schedules.
Use these to trigger workflows and nodes directly from Claude:
run_workflow — run a workflow by name with JSON input. Returns run_id, status, and result.run_node — run a single node (wrapped in a workflow for durability). Takes optional workflow_name for connection resolution.list_runs — list recent workflow runs (optionally filtered by workflow name).get_run — get a specific run by ID (supports prefix matching like git short hashes).get_trace — get the full execution trace with operation tree and timings.Two modes for HTTP triggering:
Interactive triggers (CLI, MCP tools) run in test mode by default — side-effect nodes describe what they would do without actually performing the action. Webhooks and cron run live by default. Pass "test_mode": true in the request body to run a webhook in test mode instead.
POST /dev/api/workflows/{workflow_name}/start
Authorization: Bearer {token}
Content-Type: application/json
{"input": {}}
"test_mode": true to run in test mode instead202 immediately with { "status": "accepted", "runId": "...", "workflow": "..." }GET /dev/api/runs/{runId} — returns { "status": "SUCCESS" | "ERROR" | "PENDING", ... }POST /dev/api/workflows/{workflow_name}/run
Authorization: Bearer {token}
Content-Type: application/json
{"input": {}}
"test_mode": true to run in test mode instead200 with { "run_id": "...", "status": "SUCCESS", "result": ... }500 on error with { "status": "ERROR", "error": "..." }Webhook requests require a Bearer token in the Authorization header. Tokens are Ed25519 JWTs signed by the auth-server.
Generate a token via the Dev UI: Open the Trigger tab → click Async or Sync → use the token generator (configurable expiry: 7d, 30d, 90d, 365d).
Generate a token via MCP: generate_webhook_token — specify expiry (7d, 30d, 90d, 365d).
Generate a token via API:
POST /dev/api/webhook-token
Content-Type: application/json
{"expiresIn": "30d"}
Returns { "data": { "token": "...", "expiresAt": "..." } }
https://{fly_app_name}.fly.dev/dev/api/workflows/{name}/start
The {workflow_name} must be URL-encoded if it contains special characters.
Workflows can be scheduled to run on a recurring basis via the cron system. The auth-server acts as the external scheduler — it sends HTTP requests to machines at the right times, auto-waking them from Fly.io's auto_stop.
Manage schedules via Dev UI: Open the Schedule tab to create, pause, resume, or delete schedules.
Manage via MCP tools:
list_cron_jobs — list all scheduled jobscreate_cron_job — create a new schedule (cron expression + timezone)update_cron_job — update schedule, enable/disabledelete_cron_job — remove a schedulelist_cron_runs — view execution history for a jobTest mode: Cron jobs run live by default. To run a cron job in test mode, include "test_mode": true in the job's input JSON when creating or updating the job. This value is forwarded to the workflow execution.
Cron behavior:
triggered → success | error | timeout