# 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.

## The prompt

```
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.
```

## What it replaces

**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

## What the agent does

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

## What you get

**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.

Every prompt: https://polylane.com/prompts/

Get started with one command: `curl -fsSL https://polylane.com/setup | bash` installs the CLI, connects your coding agents, and creates the account.