Rensei docs
Nodes

Generic Action Nodes

issue.* / llm.* / text action nodes.

Generic action nodes provide tracker-agnostic issue operations, direct LLM inference, and text utilities. These nodes are designed for portability: issue.* nodes route through your project's active tracker binding (Linear, GitHub Issues, Jira, or Asana) without requiring tracker-specific configuration on the node itself.

Issue nodes (tracker-agnostic)

The issue.* family projects operations onto a canonical issue shape and routes to whichever tracker is configured as the project's primary tracker. This makes workflows portable across organizations using different trackers.

issue.read

Reads an issue from the project tracker and returns it in the canonical cross-provider shape.

Input ports

PortTypeRequiredDescription
issueIdstringyesTracker-native issue ID or identifier. Linear: UUID or identifier (e.g. REN-1234). GitHub Issues: owner/repo#42. Jira: PROJ-1. Asana: GID.
trackerOverridestringnoPin to a specific tracker. A numeric ID selects an exact tracker; a provider name (e.g. linear) selects the first active tracker of that provider on the project. Omit to use the project primary tracker.

Output ports

PortTypeDescription
outputIssueReadResultIssue in canonical shape, or an error reason

IssueReadResult shape

{
  ok: boolean
  issue?: {
    id: string
    identifier: string    // e.g. "REN-1234" or "#42"
    title: string
    description?: string
    status: string
    url: string
    labels?: string[]
    assigneeId?: string
    provider: string      // "linear" | "github_issues" | "jira" | "asana"
  }
  details?: object        // Raw provider response for debugging
  reason?: string         // Error message when ok=false
}

issue.update_status

Updates the status of an issue using its canonical tracker state name. The node handles the translation from the canonical name to the tracker-native state identifier.

Input ports

PortTypeRequiredDescription
issueIdstringyesTracker-native issue ID
statusstringyesNew status name (uses tracker-canonical names, e.g. "Started" for Linear, "open" / "closed" for GitHub Issues)
trackerOverridestringnoPin to a specific tracker

Output ports - success ({ updated: boolean }) / fail ({ error: string })


issue.add_comment

Adds a comment to an issue on the project's active tracker.

Input ports

PortTypeRequiredDescription
issueIdstringyesTracker-native issue ID
bodystringyesComment body (Markdown supported on most trackers)
trackerOverridestringnoPin to a specific tracker

Output ports - success ({ id: string }) / fail ({ error: string })

LLM nodes

The llm.* pair separates configuration from execution. Declare a shared llm.config node and wire it to one or more llm.inference nodes - this lets you swap models or adjust parameters in one place rather than on every inference node.

llm.config

Declares a reusable LLM configuration as a first-class graph node. Its output port carries an LlmConfig object consumed by downstream llm.inference nodes.

Config schema

FieldTypeRequiredDefaultDescription
modelstringyes-Model identifier. Examples: claude-opus-4-8, gpt-5.4, gemini-2.5-pro, anthropic/claude-3.5-sonnet
providerstringnoopenrouterclaude (Anthropic), codex (OpenAI), gemini (Google), openrouter (OpenRouter gateway)
temperaturenumberno0.2Sampling temperature, 0.0-2.0
maxTokensnumberno1024Maximum output tokens per call, 1-128,000
systemPromptstringno-System prompt prepended to every inference call using this config
credentialIdstringno-Optional credential override; uses org-default credential when omitted

Output port - output (LlmConfig): the configuration object, ready to wire to llm.inference.


llm.inference

Calls an LLM and returns the generated text (and optionally parsed JSON). Accepts either a prompt string shortcut or a full messages array, plus optional overrides for model, temperature, max tokens, and system prompt.

Input ports

PortTypeRequiredDescription
configLlmConfignoConfiguration from an upstream llm.config node
promptstringnoSingle user message shortcut. Mutually exclusive with messages in config.

Config schema (inline fields, supplement or override config)

FieldTypeDescription
promptstringSingle user message. Mutually exclusive with messages.
messagesArray<{ role, content }>Full chat history. Roles: system, user, assistant.
jsonModebooleanAsk the model to return JSON. Parsed object appears on output.json.
modelstringOverride config.model
temperaturenumberOverride config.temperature
maxTokensnumberOverride config.maxTokens
systemPromptstringOverride config.systemPrompt

Output port - output (InferenceResult)

InferenceResult shape

{
  text: string             // Generated text
  json?: object            // Parsed JSON when jsonMode=true
  finishReason?: string    // "stop", "length", "tool_calls", etc.
  usage?: {
    promptTokens: number
    completionTokens: number
    totalTokens: number
  }
  model?: string           // Actual model used
  latencyMs?: number       // End-to-end latency
}

Example: classify an issue

steps:
  - id: llm_cfg
    type: action
    nodeId: llm.config
    config:
      provider: claude
      model: claude-opus-4-8
      temperature: 0
      maxTokens: 256
      systemPrompt: "Classify the following issue as bug, feature, or chore. Respond with JSON."

  - id: classify
    type: action
    nodeId: llm.inference
    config:
      prompt: "{{ nodes.readIssue.output.issue.title }}: {{ nodes.readIssue.output.issue.description }}"
      jsonMode: true

  - id: check_class
    type: condition
    nodeId: rensei.value.switch
    config:
      value: "{{ nodes.classify.output.json.classification }}"
      cases:
        - bug
        - feature
        - chore

Text utility

rensei.text.keyword_prefix

Prepends a keyword prefix to a string value. Used in the SDLC templates to stamp work-type labels (e.g. "Research: ", "Backlog: ") onto comment bodies or issue titles before passing them downstream.

Input ports

PortTypeRequiredDescription
textstringyesInput text
prefixstringyesPrefix to prepend

Output port - output ({ text: string }): "${prefix}${text}"

When to use issue.* vs provider-specific nodes

ScenarioRecommended approach
Workflow serves a single org with a known trackerUse provider-specific nodes (linear.*, github_issues.*) for the richer field set and more control
Workflow template shipped to multiple orgs with different trackersUse issue.* nodes for portability
SDLC template that should work with both Linear and GitHub IssuesUse issue.* - the SDLC v2 template uses this pattern

On this page