iii-functions-triggers

Registers functions and triggers on the iii engine across TypeScript, Python, and Rust. Use when creating workers, registering function handlers, binding tri...

Security Scan

The skill's instructions, lack of installs, and absent credential requests are coherent with its stated purpose of registering functions and triggers for the 'iii' engine.

Purpose & Capability

Name and description match the SKILL.md content: registering workers, functions, triggers, and cross-language invocation. The skill does not request unrelated credentials or binaries.

Instruction Scope

The SKILL.md stays on-topic (registration, trigger types, invocation modes). It suggests replacing placeholder handler logic with real business logic (API calls, DB queries, LLM calls), which is expected for a runtime pattern but means code you write using this pattern will likely use external credentials and network calls — the skill itself doesn't request or manage those secrets. The reference links point to ../references/... files that are not included in the package, which is an inconsistency (missing examples) but not a direct security issue.

Install Mechanism

Instruction-only skill with no install spec and no code files, so nothing is downloaded or written to disk by the skill itself.

Credentials

The skill declares no required environment variables or credentials. This is proportionate. NOTE: handlers created by users following this pattern may need service API keys or DB credentials — those would be supplied by the user/environment separately.

Persistence & Privilege

always is false, and the skill is user-invocable with normal autonomous invocation permitted. The skill does not request persistent presence or modify other skills or system-wide settings.

Assessment

This skill appears coherent and low-risk as-is because it's instruction-only and requests no credentials or installs. Before using it in a production agent, do the following: (1) Confirm the referenced ../references/* example files exist from a trustworthy source — currently they are absent in the package. (2) Review any handler code you or the agent generates: handlers often call external APIs, databases, or LLMs and will require credentials; ensure those secrets are supplied separately and follow least-privilege practices. (3) Verify the worker endpoint (e.g., ws://localhost:49134) — avoid pointing workers to untrusted remote engines. (4) Pay attention to HTTP triggers and cross-function invocations since misconfigured triggers could leak data or call unintended endpoints. If you need the skill to manage credentials or access external services automatically, request a version that explicitly declares and justifies those environment variables.

Functions & Triggers

Comparable to: Serverless function runtimes, Lambda, Cloud Functions

Key Concepts

Use the concepts below when they fit the task. Not every worker needs all of them.

• A Function is an async handler registered with a unique ID
• A Trigger binds an event source to a function — types include http, durable:subscriber, cron, state, stream, and subscribe
• Functions invoke other functions via trigger() regardless of language or worker location
• The engine handles serialization, routing, and delivery automatically
• HTTP-invoked functions wrap external endpoints as callable function IDs
• Functions can declare request/response formats for documentation and discovery — auto-generated from types in Rust (via schemars::JsonSchema) and Python (via type hints / Pydantic), or manually provided in Node.js

Architecture

registerWorker() connects the worker to the engine, registerFunction defines handlers, registerTrigger binds event sources to those handlers, and the engine routes incoming events to the correct function. Functions can invoke other functions across workers and languages via trigger().

iii Primitives Used

Primitive	Purpose
registerWorker(url, options?)	Connect worker to engine
registerFunction(id, handler)	Define a function handler
registerTrigger({ type, function_id, config, metadata? })	Bind an event source to a function
trigger({ function_id, payload })	Invoke a function synchronously
trigger({ ..., action: TriggerAction.Void() })	Fire-and-forget invocation
trigger({ ..., action: TriggerAction.Enqueue({ queue }) })	Durable async invocation via queue

Reference Implementation

• TypeScript: ../references/functions-and-triggers.js
• Python: ../references/functions-and-triggers.py
• Rust: ../references/functions-and-triggers.rs

Each reference shows the same patterns (function registration, trigger binding, cross-function invocation) in its respective language.

Common Patterns

Code using this pattern commonly includes, when relevant:

• registerWorker('ws://localhost:49134', { workerName: 'my-worker' }) — connect to the engine
• registerFunction('namespace::name', async (input) => { ... }) — register a handler
• registerTrigger({ type: 'http', function_id, config: { api_path, http_method, middleware_function_ids? } }) — HTTP trigger (with optional middleware)
• registerTrigger({ type: 'durable:subscriber', function_id, config: { topic } }) — queue trigger
• registerTrigger({ type: 'cron', function_id, config: { expression } }) — cron trigger
• registerTrigger({ type: 'state', function_id, config: { scope, key } }) — state change trigger
• registerTrigger({ type: 'stream', function_id, config: { stream } }) — stream trigger
• registerTrigger({ type: 'subscribe', function_id, config: { topic } }) — pubsub subscriber
• Cross-language invocation: a TypeScript function can trigger a Python or Rust function by ID
• registerTrigger({ ..., metadata: { owner: 'team', priority: 'high' } }) — optional trigger metadata

Request/Response Format (Auto-Registration)

Functions can declare their input/output schemas for documentation and discovery:

• Rust: Derive schemars::JsonSchema on handler input/output types — RegisterFunction::new() auto-generates JSON Schema (Draft 7) from the type
• Python: Use type hints (Pydantic models or primitives) on handler parameters and return types — register_function() auto-extracts JSON Schema (Draft 2020-12)
• Node.js: Pass request_format / response_format manually in the registration message (e.g., via Zod's toJSONSchema())

Adapting This Pattern

Use the adaptations below when they apply to the task.

• Replace placeholder handler logic with real business logic (API calls, DB queries, LLM calls)
• Use namespace::name convention for function IDs to group related functions
• For HTTP endpoints, configure api_path and http_method in the trigger config
• For durable async work, use TriggerAction.Enqueue({ queue }) instead of synchronous trigger
• For fire-and-forget side effects, use TriggerAction.Void()
• Multiple workers in different languages can register functions that invoke each other by ID

Pattern Boundaries

• For HTTP endpoint specifics (request/response format, path params), prefer iii-http-endpoints.
• For queue processing details (retries, concurrency, FIFO), prefer iii-queue-processing.
• For cron scheduling details (expressions, timezones), prefer iii-cron-scheduling.
• For invocation modes (sync vs void vs enqueue), prefer iii-trigger-actions.
• Stay with iii-functions-and-triggers when the primary problem is registering functions, binding triggers, or cross-language invocation.

When to Use

• Use this skill when the task is primarily about iii-functions-and-triggers in the iii engine.
• 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.