Turn Linear tickets into draft RudderStack transformations

Build me an agent workflow that turns Linear tickets from our data team into draft RudderStack transformations the team can review.

Trigger: a Linear webhook on issue created or updated, filtered to a configurable label (default candidates: "rudderstack" or "event-transform"). The label and team should both be configurable so we can scope it to our data board.

When the trigger fires, the agent should:

1. Use Linear's Get Issue to pull the full title, description, and any relevant fields from the ticket so it has the complete spec.

2. Call RudderStack's List Transformations and List Libraries so it can see existing naming conventions and reuse any helper libraries we already maintain (for example PII masking, IP anonymization, geo enrichment helpers). The agent should explicitly prefer reusing an existing library over inlining duplicate logic.

3. Draft the transformation code that satisfies the ticket. Default to JavaScript. If the ticket explicitly asks for Python, use pythonfaas instead. Common patterns to consider when drafting: PII masking or hashing, IP anonymization, geo enrichment, event allowlists or denylists, and sampling.

4. Save the result using RudderStack's Create Transformation with publish=false so the draft is stored as an unpublished revision and never touches live event traffic. Reference any helper libraries it depends on via libraryVersionIds. Pick a transformation name consistent with our existing naming convention.

5. Use Linear's Add Comment to Issue to post a summary back on the ticket. The comment must include: the new draft transformation ID, the language chosen, which libraries it depends on, the generated code inline in a Markdown code block, and a clear note that the revision is unpublished and awaiting human review before being connected to destinations.

Error handling: if RudderStack rejects the code with a 400 syntax error, the agent should retry the draft once with the RudderStack error message included in its context. If the second attempt still fails, it must post the failure back to the Linear ticket as a comment with the error message, instead of pretending the draft saved. Never publish a transformation, never connect destinationIds, and never edit an existing live transformation.

Notes for the build: Linear is a GraphQL API, so the Get Issue and Add Comment to Issue operations on our Linear integration should be used directly rather than reinventing the GraphQL. RudderStack requires the publish query param to be false on the create call to keep the revision in draft. The language field is immutable after creation, so the language choice must be made before calling Create Transformation.