Node Overview

The Rensei node catalog gives every workflow its vocabulary. Nodes are the atomic steps you drop onto the canvas; edges wire their typed output ports to input ports on downstream nodes. The platform ships 75+ nodes across 7 categories, auto-discovered at startup from the manifest.generated.ts registry.

Node categories

Node identity convention

Every node has a canonical id of the form <provider>.<domain>.<verb>. The provider segment (agent, linear, github, github_issues, llm, rensei) determines which integration credential the executor resolves at runtime. The donmai provider is the runner itself and needs no external OAuth.

linear.issue.update          ← provider=linear, domain=issue, verb=update
github.pr.create             ← provider=github, domain=pr, verb=create
agent.dispatch               ← provider=agent (donmai), domain=dispatch
gate.human_query             ← category=gate, type=human_query
parallel.fanout              ← category=parallel, type=fanout

Foundational nodes (agent, llm-model, kit-provider, …) omit the verb segment - they are configuration sources, not executable actions.

Definition schema

The workflow definition is a Zod-validated JSON document (definition-schema.ts, v1.1 and v2). Each node on the canvas serializes as a step in spec.steps. The step type field maps to the seven canonical step types:

For the full grammar - how steps, edges, groups, and lifecycle config compose into a valid definition - see donmai.dev/docs/workflow-engine.

Typed ports and connection validation

Every node declares typed input and output ports. The canvas enforces port-type compatibility when you draw an edge: you cannot wire a String output to an Object input without an explicit type cast. Ports are typed using the PortTypes helpers:

PortTypes.String
PortTypes.Number
PortTypes.Boolean
PortTypes.Object(schema)      // Object with a JSON Schema 7 descriptor
PortTypes.Array(itemType)     // Typed array
PortTypes.Nullable(type)      // Allows null in addition to the base type
PortTypes.Any                 // Bypass type checking - use sparingly

Port definitions are the source of truth for the SchemaPicker variable tree in config panels - every {{ nodes.X.field }} expression you type is validated against the output schema of node X.

Expression syntax

Node config values can reference upstream node outputs using double-brace interpolation:

{{ nodes.linearIssueRead.output.title }}
{{ $trigger.data.issueId }}
{{ $workflow.id }}

For the full expression reference - namespaces, type preservation, the = sentinel - see Expressions.

Node palette filtering

The palette sidebar filters nodes by the integrations connected to your organization. Nodes with requiredProviders set (for example, all github_issues.* nodes) only appear when the corresponding integration is enabled. Nodes are grouped by category, sorted recommended-first within each group.

Auto-discovery

Node registration is fully automated. The scripts/generate-node-manifest.ts script scans every frontend.ts and backend.ts under src/lib/nodes/ at build time and writes manifest.generated.ts. The registry validates provider references and node IDs at module initialization - a missing provider or a duplicate ID fails the build.

Bespoke config panels follow the same pattern: a config-panel.tsx sibling file is auto-discovered into config-panels.generated.ts. See Node Config Panels for the convention.