Write release notes that tell the truth
Assembles the week's releases from GitHub, Vercel and Render with what the telemetry did after each one landed.
I want to do this: Write release notes for this week's deploys, including what regressed and what got fixed. ## 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: Write release notes that tell the truth Steps: 1. List the week's deploys across services with their diffs 2. Summarise each release's intent from the changes themselves 3. Check the aftermath: metrics that moved, issues raised, fixes that followed 4. Fold the honest parts in: what regressed, what recovered, what's still open 5. Deliver the notes, each claim tied to its deploy or its metric 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.
Release notes describe intentions, not outcomes.
The changelog says what was meant to ship. Whether it worked, what it broke, and what quietly got fixed lives in the telemetry and never makes the document.
- Changelogs assembled from commit messages at 6pm Friday
- The regression and its fix, both missing from the notes
- Stakeholders learning about breakage from support tickets
One prompt, this much work. Every step on your real data.
- 1 List the week's deploys across services with their diffs
- 2 Summarise each release's intent from the changes themselves
- 3 Check the aftermath: metrics that moved, issues raised, fixes that followed
- 4 Fold the honest parts in: what regressed, what recovered, what's still open
- 5 Deliver the notes, each claim tied to its deploy or its metric
A changelog that matches reality
What shipped, what it did, and what it took to stabilise, in one document nobody has to spin. Trust in the notes survives contact with the telemetry.
Review the risky one 
“Review PR #241 against production: what does it deploy to, and what breaks if it merges?” 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.” Headroom check “Which services are closest to their limits: connection pools, queues, compute?”
“Review PR #241 against production: what does it deploy to, and what breaks if it merges?” 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.” Headroom check “Which services are closest to their limits: connection pools, queues, compute?”