Triage Railway deploy failures into Linear tickets

Build me an agent workflow that triages Railway deployment failures and files a Linear ticket for whoever broke it.

Trigger: a Railway outgoing webhook configured for the Deployment.failed event. Use the webhook payload directly. I care about these fields: deploymentId, serviceName, environmentName, projectName, status, commit (SHA), author (committer username/email), and branch. Railway webhook docs: https://docs.railway.com/guides/webhooks.

When the webhook fires, the agent should:

1. Pull deploy context from Railway. Call Get Deployment with deploymentId to confirm the status and grab the Railway deploy URL. Then call Get Build Logs and Get Deployment Logs for that deployment to capture both build-time and runtime output. Keep the last ~200 relevant lines (errors, stack traces, the failing step) and drop noise.

2. Identify the breaking change on GitHub. Use the repo owner/name configured for the workflow plus the branch and commit SHA from the webhook. Call Get a Pull Request if the deploy traces to a merged PR (look it up by commit SHA via Search Issues and Pull Requests, or fall back to List Pull Requests filtered by head branch). Capture the PR title, body, author, and changed files. If no PR is found (direct push), just use the commit author from the webhook.

3. Produce a short root-cause summary (no more than ~6 lines). Classify the failure as build error vs runtime error, name the exact failing step or command, quote the key error message, and call out a suspected file or area based on the changed files in the PR. Keep it tight and skimmable.

4. File the ticket in Linear. Call Create Issue in the team I configure (default: the Engineering team). Title: "[Deploy failure] <serviceName> on <branch> — <one-line cause>". Description: the root-cause summary, the trimmed log excerpt in a code block, the list of changed files, and direct links to the Railway deployment URL and the GitHub PR/commit. Priority: Urgent. Assignee: the Linear user matching the commit author's GitHub username or email; if no match, leave unassigned and add a comment tagging a configured fallback assignee.

5. Post one Slack alert. Call Send a Message into #deploys (configurable). The message should include: the service name and environment, a one-line cause, the commit author, a link to the Linear issue that was just created, and a link to the Railway deployment. Use a single message, not a thread of follow-ups.

Guardrails: if Get Deployment shows the deploy has since recovered (e.g. a retry succeeded) before the agent finishes, skip Linear and Slack and exit. If the same commit already has an open Linear issue with the "deploy-failure" label, add a comment to that issue instead of creating a duplicate, and still post the Slack alert linking to the existing issue. Tag the new Linear issue with the label "deploy-failure" so future runs can find it.

Inputs the workflow should expose for configuration: GitHub repo (owner/name), default Linear team, default Linear assignee fallback, Slack channel, and an optional environment filter so users can limit this to production only.