PR code review from Telegram, by way of Pi

I’ve been off-engineering for a while — running Neul Labs is more product and ops than code. But our small contributor base ships pull requests at all hours, and “approve this PR” is still mostly on me.

So I built a small openclawOS binding that does the first half of the review work and sends the result to my Telegram. Here’s the shape.

The binding

trigger:
  channel: github
  match:
    event: pull_request
    action: [opened, synchronize]
agent: pi
session: { scope: pr }
prompt: |
  Review the diff. Surface:
   - Likely regressions or broken assumptions
   - Tests missing for the changed behaviour
   - Style nits I should call out, briefly
   - One-sentence summary, then bullets
output:
  channel: telegram
  to: "@dipankar_dev_bot"

What I get

A Telegram message within ~30 seconds of any PR opening or being pushed to:

PR #142: feat: add identity linking across channels
Summary: Adds a new identities table and a linkIdentity() API. Migrates existing per-channel session lookups to go through the new table.

⚠ The migration is not idempotent — re-running it on an already-migrated DB will throw a uniqueness constraint. Wrap in a check.
⚠ No test for the cross-channel session lookup case. (Existing tests are channel-scoped.)
✓ Backwards compatible at the binding API level.
nit: linkIdentity and linkIdentityChain differ subtly; consider naming the latter for clarity.

It’s not always right but it’s almost always useful — a starting point. I read it. If it’s flagging something real, I open the PR and engage. If it’s all benign, I approve from the GitHub mobile app.

Why Telegram, not Slack

Telegram is what I check on the sofa. Slack feels like work. The choice of channel is purely about which app I have less guilt opening at 9pm.

The binding doesn’t care — the same setup with output.channel: slack would post into a #pr-reviews channel for a team setup. Several openclawOS users do exactly that.

What Pi can’t do

This setup is fine for diffs under 500 lines. Above that, the model loses track of where assumptions live. I keep large refactors as human-only territory.

It’s also not great at security review. The model occasionally over-flags things (a string concatenation it suspects of being SQL injection that isn’t) and under-flags real issues (subtle race conditions). I never use it as a sole security signal.

What Pi is great at

• One-paragraph summaries of “what this PR does”.
• Catching missing tests for behaviour change.
• Style consistency.
• Catching off-by-one and edge-case omissions in clearly-scoped functions.

These are the boring categories of review feedback. Pi catches them; I get to spend my attention on the interesting categories.

Setup, end-to-end

If you want this for your repo:

1. Install openclawOS.
2. Create a Telegram bot (BotFather).
3. Register a GitHub App pointed at your Gateway’s /github webhook.
4. Drop the binding YAML above.
5. Open a PR. Watch Telegram light up.

Total time: about 45 minutes if it’s your first openclawOS setup, 10 if you already have a Gateway running.

The bigger pattern

This isn’t really about code review. It’s about triage layer between an event stream and your attention. Pi is good at first-pass triage: “is this worth your time, and if so, what should you look at first?”. openclawOS is the wiring that lets that triage live in whichever app you’re most likely to glance at.

Substitute “PR” with “support ticket”, “Linear issue”, “incoming email”, “Sentry alert”, and the same shape works. The Telegram-Pi-GitHub triangle is just one slice of it.