Add GitHub PR comment trigger workflow for self-hosted k8s workers (REMOTE-2003)

[seemeroland]

Summary

Adds a GitHub PR comment trigger workflow for self-hosted Kubernetes workers (REMOTE-2003).

Problem: Enterprise customers running self-hosted Oz workers on Kubernetes (e.g. via the Helm chart) had no documented path to trigger Oz from GitHub PR comments (@oz-agent mentions). The existing respond-to-comment.yml in oz-agent-action routes tasks to Warp cloud agents, not to customer-managed k8s workers.

Solution: A new consumer workflow template that calls the Warp REST API directly with config.worker_host targeting the customer's k8s worker ID, so PR-comment-triggered tasks run entirely within the customer's cluster.

Changes

consumer-workflows/gh-pr-comment.yml (new)

GitHub Actions workflow template that customers copy into .github/workflows/. When a PR comment containing @oz-agent is detected:

1. Acknowledges with a 👀 reaction
2. Resolves PR context (number, branch, changed files)
3. Calls POST https://app.warp.dev/api/v1/agent/runs with config.worker_host set to the customer's OZ_WORKER_ID variable
4. Posts a reply with a link to the run so the developer can track progress
5. Reports any dispatch failure back to the commenter

The workflow runs on GitHub-hosted runners; no oz CLI is needed on the runner — only curl, jq, and the gh CLI. The Oz agent runs inside the customer's k8s cluster, checks out the PR branch, makes changes, commits, pushes, and replies.

README.md

New GitHub PR Integration section covering:

• End-to-end flow diagram
• Step-by-step setup (k8s GitHub credentials, workflow copy, secrets/variables)
• Comparison table vs. oz-agent-action respond-to-comment.yml
• Self-hosted GitHub Actions runner instructions
• Prompt customization guidance

Design decisions

• API call instead of oz CLI: The trigger step is just a lightweight API call, making the workflow runner-agnostic. No Debian/Ubuntu dependency from dpkg -i.
• Fire-and-forget async model: Unlike the synchronous oz-agent-action approach, the workflow dispatches the run and returns. Oz handles pushing commits and posting the summary reply as part of the task.
• config.worker_host routing: Uses the Warp API's worker_host field in the task config to route to the specific self-hosted worker, rather than requiring a Warp environment to be configured.
• GitHub credentials via Kubernetes Secrets: Documented injection via kubernetesBackend.podTemplate.containers[task].env[GITHUB_TOKEN] or SSH key volume mounts.

---

Conversation: https://staging.warp.dev/conversation/325ab22d-8473-4aef-8ce4-221340cf2d05
Run: https://oz.staging.warp.dev/runs/019ef64d-601d-7ad8-91e0-717fde30252f
This PR was generated with Oz.