Iii iii-low-code-automation
install
source · Clone the upstream repo
git clone https://github.com/iii-hq/iii
Claude Code · Install into ~/.claude/skills/
T=$(mktemp -d) && git clone --depth=1 https://github.com/iii-hq/iii "$T" && mkdir -p ~/.claude/skills && cp -r "$T/skills/iii-low-code-automation" ~/.claude/skills/iii-hq-iii-iii-low-code-automation && rm -rf "$T"
manifest:
skills/iii-low-code-automation/SKILL.mdsource content
Low-Code Automation Chains
Comparable to: n8n, Zapier, LangFlow
Key Concepts
Use the concepts below when they fit the task. Not every automation needs all of them.
- Each "node" in the automation is a small registered function with a single job
- Nodes chain via named queues using
— easy to add, remove, or reorder stepsTriggerAction.Enqueue - HTTP triggers receive external webhooks (form submissions, payment events)
- Cron triggers start scheduled automations (daily digests, periodic syncs)
- PubSub broadcasts completion events for downstream listeners
Architecture
Automation 1: Form → Enrich → Store → Notify HTTP webhook → auto::enrich-lead → auto::store-lead → auto::notify-slack Automation 2: Cron → Fetch → Transform → Store Cron (daily) → auto::fetch-rss → auto::transform-articles → auto::store-articles Automation 3: Payment webhook → Validate → Update → Notify HTTP webhook → auto::validate-payment → auto::update-order → publish(payment.processed)
iii Primitives Used
| Primitive | Purpose |
|---|---|
| Initialize the worker and connect to iii |
| Define each automation node |
| Chain nodes via named queues |
| Persist data between nodes |
| Fire-and-forget notifications |
| Webhook entry points |
| Scheduled automations |
Reference Implementation
See ../references/low-code-automation.js for the full working example — three automation chains: form-to-Slack notification, RSS feed aggregation, and payment webhook processing.
Common Patterns
Code using this pattern commonly includes, when relevant:
— worker initializationregisterWorker(url, { workerName })
— node chainingtrigger({ function_id, payload, action: TriggerAction.Enqueue({ queue: 'automation' }) })- Each node as its own
withregisterFunction
prefix IDsauto:: - Small, focused functions that do one thing (enrich, validate, store, notify)
— persist between nodestrigger({ function_id: 'state::set', payload: { scope, key, value } })
— structured logging per nodeconst logger = new Logger()
Adapting This Pattern
Use the adaptations below when they apply to the task.
- Add new automation chains by registering HTTP/cron triggers and chaining functions
- Each node should be independently testable — accept input, produce output
- Use separate queue names when different chains need different retry/concurrency settings
- For unreliable external services, wrap calls in try/catch and handle failures explicitly
- Keep node functions small — offload complex logic to dedicated functions
Pattern Boundaries
- If the task requires durable multi-step workflows with saga compensation and step tracking, prefer
.iii-workflow-orchestration - If the task involves multiple AI agents handing off work, prefer
.iii-agentic-backend - Stay with
when the primary concern is simple trigger-transform-action chains with minimal orchestration overhead.iii-low-code-automation
When to Use
- Use this skill when the task is primarily about
in the iii engine.iii-low-code-automation - Triggers when the request directly asks for this pattern or an equivalent implementation.
Boundaries
- Never use this skill as a generic fallback for unrelated tasks.
- You must not apply this skill when a more specific iii skill is a better fit.
- Always verify environment and safety constraints before applying examples from this skill.