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.

Additional information

What does this prompt do?

Watches your data team's Linear board and reacts whenever a ticket with your transformation label is created or updated.
Reads the full ticket description and looks at your existing RudderStack transformations and helper libraries so the draft matches your team's naming and patterns.
Writes a draft transformation in JavaScript by default, or Python if the ticket asks for it, and saves it in RudderStack as an unpublished revision so live traffic is never touched.
Posts a summary comment back on the Linear ticket with the new draft transformation ID, the language, the helper libraries it relies on, the generated code inline, and a clear note that the draft is waiting on human review.

What do I need to use this?

A Linear workspace where your data team files transformation requests, with a label such as rudderstack or event-transform you can apply to those tickets.
A RudderStack account with permission to create transformations, plus an access token for the integration.
A loose convention for how you describe transformation requests in tickets (event name, fields to change, PII to mask, etc.) so the agent has enough to work from.

How can I customize it?

Change the label the agent listens for, or scope it to a specific Linear team so it only reacts to tickets on the data board.
Pick the default language for new drafts (JavaScript or Python) and the style rules the agent should follow, such as PII masking, IP anonymization, geo enrichment, or event allowlists.
Decide what the follow-up comment should include, for example a checklist for the reviewer or a link to your destination connection runbook.

Frequently asked questions

Will this push code to live RudderStack traffic?

No. Every draft is saved as an unpublished revision, so it never runs against live events until a teammate reviews it and connects it to destinations themselves.

What happens if RudderStack rejects the generated code?

The agent retries once with the error message in context, and if it still fails it posts the error back to the Linear ticket so the requester knows the draft did not save instead of pretending it worked.

Can non-data-engineers file these tickets?

Yes, that is the point. An analytics engineer, PM, or marketer can describe what they want in plain English in a Linear ticket and get a reviewable draft back without writing any code.

How does the agent know our team's conventions?

Before drafting, it pulls your existing transformations and helper libraries from RudderStack so the new draft matches your naming and reuses the helpers you already trust.

Does this replace our code review process?

No. The draft is unpublished and the Linear comment explicitly flags it as awaiting human review. Your normal review and publish steps still happen.