Review a pull request against production
Reads the diff in GitHub, then the config, capacity and live telemetry of every service it deploys to, and comes back with a clean pass or exactly how it would break.
I want to do this: Review PR #241 against production: what does it deploy to, and what breaks if it merges? ## Setup (skip if Polylane is already set up) Read and follow https://polylane.com/auth.md for non-interactive signup and setup. Start by checking whether I am already signed in; reuse my account and workspace. If the CLI is missing, bootstrap it without starting the interactive wizard: curl -fsSL 'https://polylane.com/setup?ref=prompts' | bash -s -- --install-only Then follow the guide through email verification, workspace selection, source connections, and MCP authentication. Ask me for an email code or OAuth consent only when needed. Verify each step; report pending setup instead of claiming success from installation alone. ## How to work Over MCP: searchTools lists what this workspace exposes, with each tool's schema; call it first. runTool runs one tool, runCode chains several in one call and returns just the answer. search and execute cover the full Polylane REST API: threads, issues, investigations, autofixes, memories. From the terminal: the polylane CLI wraps the same API, with structured output and non-interactive flags everywhere. Reads always work. Write tools appear only if I have opted in, and every write is screened. ## Task: Review a pull request against production Steps: 1. Read the diff and work out which services and resources it deploys to 2. Pull each target's current config and capacity from the context graph 3. Read the live telemetry behind those services: headroom, error rates, recent wobble 4. List the changes that landed on them recently 5. Deliver a verdict with the mechanism and the evidence, or a clean pass Ground every claim in data you actually pulled: the query, the log line, the change record. If the data is inconclusive, say so. Ask me before anything that writes.
The diff looks fine. The diff always looks fine.
The review that matters isn't in the file view: it's what the change lands on. Checking that means opening the infra console, the dashboards, and the deploy history for every service the code touches.
- Opening four consoles to answer "what does this touch?"
- Approving a config change whose blast radius nobody can see
- Finding out at deploy time that the connection pool was already at its limit
One prompt, this much work. Every step on your real data.
- 1 Read the diff and work out which services and resources it deploys to
- 2 Pull each target's current config and capacity from the context graph
- 3 Read the live telemetry behind those services: headroom, error rates, recent wobble
- 4 List the changes that landed on them recently
- 5 Deliver a verdict with the mechanism and the evidence, or a clean pass
Approve with the blast radius in view
The verdict names what the change lands on and exactly what would break, with the queries behind it. Approving stops being a leap of faith.
Blast radius 
“If checkout-api goes down, what goes down with it? Walk the graph and rank by traffic.” Before the migration 
“We're renaming the orders table tonight. Which services, queries, and crons touch it?” Audit the weekend 
“List every deploy since Friday and flag the ones whose metrics moved afterwards.” Honest release notes “Write release notes for this week's deploys, including what regressed and what got fixed.” Headroom check “Which services are closest to their limits: connection pools, queues, compute?”
“If checkout-api goes down, what goes down with it? Walk the graph and rank by traffic.” Before the migration “We're renaming the orders table tonight. Which services, queries, and crons touch it?” Audit the weekend “List every deploy since Friday and flag the ones whose metrics moved afterwards.” Honest release notes “Write release notes for this week's deploys, including what regressed and what got fixed.” Headroom check “Which services are closest to their limits: connection pools, queues, compute?”