Weekly release notes from Linear to GitBook

Every Friday at 3pm ET, draft this week's release notes in GitBook from completed Linear issues, then ping engineering in Slack so they can review and merge.

Step 1. Pull issues from Linear. Use Linear List Issues to find every issue that moved to a Done state in the last seven days. Skip any issue carrying the label "internal" or "infra" — those should never reach customer-facing release notes.

Step 2. Group and rewrite. Sort the remaining issues into four sections: Features, Improvements, Bug Fixes, Breaking Changes. Decide which section an issue belongs in based on its labels first, then fall back to the issue title and description if labels are ambiguous. Collapse multiple issues that ship the same user-visible feature into a single bullet so customers do not see the same change three times. For each bullet, write one or two plain-English sentences describing the user-visible impact, not the engineering work. No PR numbers, no Linear IDs, no internal codenames, no jargon.

Step 3. Stage the draft in GitBook. Use GitBook Create Change Request against our designated Release Notes space to open a draft containing a new page titled with this week's date (for example, "Release notes for the week of June 23, 2026"). Lay out the page as one heading per section with bullets underneath; if a section is empty, omit the heading. The change request stays a draft — do not merge it. Editing the language before publish is the point.

Step 4. Notify engineering. Use Slack Send a Message (Slack Bot) to post in the engineering channel with a one-line summary of how many items shipped in each section and a link to the GitBook change request so a teammate can review, polish the language, and merge it to publish.

If no issues moved to Done this week, skip creating the change request and instead send a short Slack note saying nothing shipped, so the team knows the workflow ran and there was simply nothing to publish.

Tone: customer-facing, friendly, no internal jargon, no engineering acronyms. The reader is a product user, not a developer.