Plane Release Notes Generator

Release Notes Generator

Generate structured release notes from a Plane release PR by parsing its commit list, then update the PR description. Output matches the format used on github.com/makeplane/plane/releases (e.g. v1.2.0). Works for both makeplane/plane-cloud and makeplane/plane-ee.

Repo-specific versioning

Plane uses different version schemes across its two release repos. Detect which repo the PR belongs to and use the matching scheme when communicating about the release — the version itself does not appear in the release notes body (GitHub's release tag carries it).

• plane-cloud ships daily — version is vYY.MM.DD-N where N is the counter for that date's release.
• plane-ee ships on a versioned cadence — version is vX.Y.Z (major.minor.patch) following semver.
• Detect the repo with gh pr view <PR_NUM> --json headRepository,baseRepository or from the URL the user shared.

When to Use

• User links/mentions a Plane release PR (e.g. release: v26.04.13-1 for cloud or release: v1.12.0 for EE) and asks for release notes
• User asks to "create release notes" / "update PR description" for a PR in makeplane/plane-cloud or makeplane/plane-ee
• The branch is named uat or release/x.y.z and the base is master or preview

Steps

1. Fetch commits

gh pr view <PR_NUM> --json title,body,baseRefName,headRefName,commits \
  --jq '.commits[] | .messageHeadline + "\n---BODY---\n" + .messageBody + "\n===END==="'

For a quick scan first:

gh pr view <PR_NUM> --json commits \
  --jq '.commits[] | {oid: .oid[0:10], message: .messageHeadline}'

2. Filter out noise

Always exclude these commits — mechanical, not user-facing:

3. Identify work item IDs (for research only)

Most meaningful commits begin with a Plane work item identifier in brackets:

• [WEB-XXXX] — web/frontend product items
• [SILO-XXXX] — Silo (integrations: Slack, GitHub, GitLab, Jira/Linear)
• [MOBILE-XXXX], [API-XXXX], etc.

Do not include these IDs in the release notes. The GitHub Releases format is end-user-facing — IDs are only useful as a lookup key for fetching context in step 4.

4. (Optional) Enrich via Plane MCP

For larger features where the commit headline is terse, fetch the work item to write a richer paragraph:

mcp__plane__retrieve_work_item_by_identifier(project_identifier="WEB", issue_identifier=6874)

Use the returned name and description_stripped to flesh out the prose. Skip for routine fixes — commit body is usually enough. Don't enrich every item (slow + descriptions are often empty).

5. Categorize commits

Map each surviving commit into one of four sections:

Drop entirely (do not surface to users): pure infra chore:, dependabot bumps with no CVE, internal refactors with no behavioural impact, test-only changes, doc-only changes.

6. Format

Output follows the GitHub Releases convention — ### for section headers, with two spaces between the emoji and the label for ✨ / ⬆️ / 🐞 (matches v1.2.0).

### ✨ Features

#### **Short Feature Name in Title Case**

A 1–3 sentence paragraph describing what the user gets, why it matters, and any notable behaviour. Write in product-marketing voice, not commit-message voice.

- Optional nested bullets for sub-capabilities or callouts
- Keep them user-facing — what the user can now do

#### **Second Major Feature**

Another descriptive paragraph. Each major feature gets its own `####` subsection.

### ⬆️ Enhancements

- One-line description of an improvement to an existing capability
- Another improvement, written as a clean sentence (no commit prefix, no ticket ID)

### 🐞 Bug fixes

- Plain-English description of what was broken and is now fixed
- Another bug fix

### 🛡️ Security

- Upgraded <component> to <version> to mitigate [CVE-XXXX-NNNNN](https://link-to-advisory). Brief impact note.
- Other security-relevant change

Rules:

• Section headers use ### (three hashes), then emoji + two spaces + label — exactly as in the published v1.2.0 release. Exception: 🛡️ Security uses a single space (matches v1.2.0).
• Features use #### (four hashes) and the feature name is bolded inside the heading: #### **Feature Name**.
• Each feature gets a real paragraph, not a bullet — written for end users, not engineers.
• Enhancements, Bug fixes, and Security are simple bullets. No nested asterisks, no ticket IDs, no PR numbers.
• Do not include work item IDs ([WEB-XXXX]) or PR numbers ((#NNNN)) in any section — this format is user-facing.
• Do not add a # Release vX.Y.Z heading. The GitHub release tag carries the version; the body starts directly with the first ### ✨ Features section.
• Do not insert images. The user adds screenshots manually after the notes are drafted. Leave space for them only if the user asks.
• Drop empty sections entirely.
• Blank line between section header and first bullet/feature, and between sections.