Auto-review RudderStack transformation pull requests

Build me an agent workflow that acts as a first-pass code reviewer for RudderStack transformation changes in our GitHub repo. The only two integrations I want it to use are GitHub and RudderStack.

Trigger: a GitHub webhook on pull_request events with the actions opened and synchronize, scoped to a single repo I will configure and to changes inside a transformations/ path. The agent should ignore PRs that do not touch that folder.

For each qualifying PR, the agent should run roughly this sequence:

1) Use Get a Pull Request to load PR metadata and the head branch reference, then use List Files in a Directory on the transformations/ path of the head branch to enumerate the transformation files in this PR. For each file, use Get a File on the head branch to fetch its current source code and decode it from base64.

2) For each transformation file, derive the transformation name from the file name (or from a name field inside the file if our convention puts it there), then call List Transformations on RudderStack to find the matching transformation by name. Use Get Transformation to retrieve the currently live code so the review can diff old versus new. Then call Update Transformation with publish set to false, passing the PR's version of the code. This creates a draft revision and forces RudderStack to run its server-side syntax and exception checks. If RudderStack returns a 400 with an error body, capture the error message verbatim and treat it as a failed validation for that file.

3) Bake in the important RudderStack rules: the language field on a transformation is immutable, so if the PR seems to switch a JavaScript transformation to Python (pythonfaas) or the other way around, the agent must refuse that change in the review instead of trying to update it. Updates go to POST /transformations/{id}, not PUT. The draft revision (publish=false) is validated by RudderStack but does not affect live event traffic; only a separate publish step does. New transformations that do not exist in RudderStack yet should be flagged as net new and skipped from the side by side draft step.

4) Produce a plain-English code review per file that covers: a short summary of what changed between the currently live code and the PR's code; PII handling concerns (raw emails, IP addresses, user IDs, phone numbers, or other identifiers that are not hashed or stripped); missing or weak error handling (uncaught exceptions, missing null checks on event properties, silent failures); and any draft validation failures returned by RudderStack, quoted verbatim from the error body. End the review with an overall summary that lists which files passed RudderStack's draft check and which failed.

5) Post the review back to the PR using Create a Pull Request Review, with inline comments on specific lines where possible and the summary in the review body. The review body must include a clear note in plain English that says: this change has been staged as a draft revision in RudderStack and will not affect live event traffic until the PR is merged and a separate publish step runs. Set the review event to COMMENT by default; if any file failed RudderStack's draft validation, use REQUEST_CHANGES instead.

The point of this workflow is to close the loop between a data engineer's PR and the actual CDP environment: reviewers see real RudderStack validation results, not just opinions, and the PR itself becomes the source of truth for whether a transformation is safe to publish.