| name | ductile |
| description | Operate, configure, and troubleshoot the ductile integration gateway CLI. Use this skill when the user wants to: run ductile commands, manage plugins or pipelines, configure the gateway, inspect jobs, trigger API calls, manage tokens/webhooks, validate or lock config, or understand ductile architecture. Triggers: any mention of "ductile", "config lock", "plugin list", "job inspect", "system start", pipeline DSL, or integration gateway tasks.
|
Ductile CLI Skill
Ductile is a lightweight YAML-configured integration gateway for personal automation.
Design philosophy: polyglot plugins, event-driven pipelines, LLM-first CLI.
Runtime Context
- Binary:
/home/matt/admin/ductile-test/ductile (test) or /home/matt/.local/bin/ductile (local prod)
- Test env:
/home/matt/admin/ductile-test/
- Local prod config:
~/.config/ductile/
- Run from:
/home/matt/admin
- Pattern:
ductile <noun> <action> [flags]
CLI Command Reference
System
ductile system start
ductile system status [--json]
ductile system watch
ductile system reset <plugin>
ductile system skills [--config <dir>]
Config
ductile config check [--json] [--strict]
ductile config lock
ductile config show [entity]
ductile config get <path>
ductile config set <path>=<value>
ductile config init
ductile config backup
ductile config restore
ductile config token create
ductile config token
ductile config scope
ductile config plugin
ductile config route
ductile config webhook
Job
ductile job inspect <job_id> [-v]
Plugin
ductile plugin list
ductile plugin run <name>
Universal Flags
| Flag | Purpose |
|---|
--json | Machine-readable output (all read commands) |
-v, --verbose | Internal logic, path resolution, baggage merges |
--dry-run | Preview mutations without committing |
--config <dir> | Override config directory |
Entity Addressing
Use <type>:<name> syntax with config show/get/set:
ductile config show plugin:withings
ductile config show pipeline:video-wisdom
ductile config set plugin:withings.enabled=false
ductile config show plugin:*
LLM Capability Discovery
Ductile is designed for LLM operation. Use system skills to get the current live manifest:
ductile system skills --config ~/.config/ductile/
Or set DUCTILE_CONFIG_DIR and run ductile system skills.
This outputs a Markdown skill manifest listing all plugin commands with endpoints, schemas, and semantic anchors (mutates_state, idempotent, retry_safe), plus all configured pipelines.
Common Workflows
After any config change:
ductile config check
ductile config lock
Trigger a pipeline via API:
curl -X POST http://localhost:8081/pipeline/<name> \
-H "Authorization: Bearer $DUCTILE_LOCAL_TOKEN" \
-H "Content-Type: application/json" \
-d '{"payload": {"key": "value"}}'
Trigger a plugin directly (bypasses routing):
curl -X POST http://localhost:8081/plugin/<name>/poll \
-H "Authorization: Bearer $DUCTILE_LOCAL_TOKEN" \
-d '{"payload": {}}'
Inspect a failed job:
ductile job inspect <job_id> -v --json
Check gateway health:
curl http://localhost:8081/healthz
Architecture Summary
- Governance Hybrid: Control plane (SQLite
event_context baggage) + Data plane (filesystem workspaces)
- Spawn-per-command: Each plugin invocation is a fresh process (polyglot: bash, python, go, any executable)
- At-least-once: Jobs survive crashes and are recovered on restart
- Immutable audit:
origin_* baggage keys can never be overwritten by plugins
Config Integrity (Tiered)
| Tier | Files | On Mismatch |
|---|
| High Security | tokens.yaml, webhooks.yaml, scopes/*.json | Hard fail (refuses to start) |
| Operational | config.yaml, plugins/*.yaml, pipelines/*.yaml | Warn & continue |
Always run config check then config lock after authorizing changes.
Job Statuses
queued → running → succeeded / failed / timed_out / dead
Reference Files