Building Your First Flow

Open the Builder

Navigate to Flows in the left sidebar of the Steroid web UI and click New Flow. The canvas opens with a single empty trigger node at the top. Every flow starts here — the trigger defines how the flow is invoked.

Add a Trigger

Click the trigger node to open the trigger picker. Choose the trigger type that matches how you want to invoke this flow.

For this guide, select Webhook. Once selected, Steroid generates a unique endpoint URL for this flow. The URL is shown in the trigger node panel — copy it for later. Any JSON body sent to that URL becomes available as {{trigger.body.field}} in downstream steps.

Add Steps

Click + Add Step below the trigger to open the step picker. You can add MCP blocks or LLM nodes in any order. Steps execute top to bottom.

Step 1 — LLM Node (Summarise the PR)

1. In the step picker, choose the Invoke LLM piece and its plain invoke_llm action.
2. Select an IDE and Model advertised by an eligible connected client; authenticate that agent before testing.
3. Write your prompt in the Prompt field (see example below).
4. For typed generation, choose the separate invokeStructuredLlm action and provide jsonSchema; there is no universal structured-output toggle.
5. Click Save.

You are a senior engineer writing release notes.

Given the following pull request diff, produce a concise summary suitable
for a GitHub issue body. Include: what changed, why it matters, and any
known risks.

PR title: {{trigger.body.pr_title}}
PR diff:
{{trigger.body.diff}}

{
  "type": "object",
  "properties": {
    "summary":     { "type": "string" },
    "risk_level":  { "type": "string", "enum": ["low", "medium", "high"] },
    "labels":      { "type": "array", "items": { "type": "string" } }
  },
  "required": ["summary", "risk_level", "labels"]
}

Step 2 — GitHub Block (Create Issue)

1. Click + Add Step and choose MCP Block.
2. Select the GitHub MCP server.
3. Choose issue_write; set method to create.
4. Provide separate owner and repo inputs plus the title/body shown below.
5. Resolve github.personal_access_token through the piece's credential property or an existing project connection reference.
6. This example does not guess a nested LLM text path. Inspect the test output/data picker before mapping a generated summary into a text field.

{
  "arg_method": "create",
  "arg_owner": "{{trigger.body.owner}}",
  "arg_repo": "{{trigger.body.repo}}",
  "arg_title": "{{trigger.body.pr_title}} — review request",
  "arg_body": "{{trigger.body.diff}}"
}

Step 3 — Slack Block (Post Notification)

1. Click + Add Step and choose MCP Block.
2. Select the Slack MCP server.
3. Choose slack_post_message.
4. Set channel_id to the channel ID from the trigger, not a #channel name.
5. Configure slack.bot_token and the server's required slack.team_id.
6. Compose a confirmation from explicit request inputs; inspect tested outputs before adding an issue URL.

{
  "arg_channel_id": "{{trigger.body.channel_id}}",
  "arg_text": "Review flow ran for {{trigger.body.owner}}/{{trigger.body.repo}}"
}

Step 4 — Return Response

1. Click + Add Step and choose Return Response.
2. Set the status to 200.
3. Return complete step envelopes first. The example assumes internal names step_1 (LLM), step_2 (GitHub) and step_3 (Slack); use actual data-picker names in your flow.

{
  "llm_result": "{{step_1}}",
  "github_result": "{{step_2}}",
  "slack_result": "{{step_3}}"
}

Test Your Flow

Before publishing, use the built-in test runner to verify each step. Click the test button in the top-right of the canvas to open the test panel, paste a sample payload, and click Run Test.

{
  "owner":    "acme",
  "repo":     "backend",
  "channel_id": "C0123456789",
  "pr_title": "Optimise worker pool memory usage",
  "diff":     "- pool.size = 100\n+ pool.size = dynamic(cpu_count * 4)\n..."
}

Publish

Once all steps pass the test run, click Publish in the top bar. Enter a description and valid JSON in the trigger-body-schema field; the visible{} is a placeholder, not an entered value. The schema is descriptive metadata, not automatic payload validation. Publishing activates the selected version.

• The base webhook is asynchronous; append /sync for JSON or /sync-stream for SSE.
• Published/live and search-indexed are distinct. Agent publication reports an indexed outcome; a UI signature alone does not prove SRP discoverability.
• You can continue editing the flow after publishing — changes are saved as a draft until you publish again.
• The flow's run history and logs are accessible from the flow detail page.