update-changelog

name	update-changelog
description	Update the project CHANGES.md with issues from a given GitHub milestone, with correct categorization and references.

Skill: update-changelog

Update CHANGES.md with entries for all issues and PRs in a given GitHub milestone. Each entry references the user-facing issue (not the PR) as the primary link, with the fix PR inline on the same line.

When to Use

• Before a new release, to populate the changelog with all fixed issues
• When new issues are added to an existing milestone and the changelog needs to be refreshed
• To ensure every entry follows the correct format for the changelog

Prerequisites

• gh CLI authenticated (gh auth status)
• Python 3.8+
• scripts/gh.py helper script available

Workflow

1. Determine the target version

The version is typically a semver string like 2.15.3. Confirm with the user if not specified.

2. Fetch all issues in the milestone

Use the helper script. It uses GraphQL for efficient single-pass fetching (closing PRs are included in the same query — no N+1):

# All closed issues (default)
python3 scripts/gh.py issues "2.16.0"

# Include open issues too
python3 scripts/gh.py issues "2.16.0" --state all

# Exclude entries that should not go in the changelog
python3 scripts/gh.py issues "2.16.0" --exclude "release blocker,no changelog"

Exclusion rules (issue-level):

• no changelog label — Chore/refactor work that doesn't need a changelog entry
• release blocker label — Blocked issues not yet ready for changelog
• Task issue type — Internal chores are not user-facing; automatically excluded by gh.py. Use --include-tasks to override.
• Rejected project status — Issues with a "Rejected" status in the "Main" project board are automatically excluded by gh.py. This project-level status (independent of the GitHub issue state) indicates the issue was rejected from the release. Use --include-rejected to override.

Exclusion rules (PR-level): In addition to issue-level exclusions, PRs with these labels should be excluded regardless of their linked issue's labels:

• release blocker — PR is part of a pending release blocker batch
• no issue required — Trivial fix not tracked as an issue

The script outputs JSON with each entry containing number, title, state, issue_type, labels, closing_prs (the PRs that fix each issue), and project_status (the "Main" project board status, e.g. "Done", "Rejected", or null if not tracked in a project).

3. Identify missing entries (optional)

If updating from an existing CHANGES.md, find issues in the milestone that are NOT yet referenced in the changelog:

python3 scripts/gh.py issues "2.16.0" --exclude "release blocker,no changelog" --compare CHANGES.md

This returns a filtered JSON array with only the missing issues.

Note: The --compare flag checks issues only (via issue number references in the changelog). To find merged PRs not yet referenced, use the milestone PR cross-reference described in step 10 below.

4. Fetch additional PR details when needed

When you need more context for specific PRs (e.g. to find the PR author for community contribution attribution, or to read the PR body for "Fixes/Closes #NNN" patterns):

# One or more PR numbers
python3 scripts/gh.py prs 9179 9204 9311

# From a file
python3 scripts/gh.py prs --file prs.txt

# From stdin
cat prs.txt | python3 scripts/gh.py prs --stdin

The prs command also supports listing all PRs in a milestone in one call:

# All merged PRs in a milestone (default)
python3 scripts/gh.py prs --milestone "2.16.0"

# All states (merged, open, closed)
python3 scripts/gh.py prs --milestone "2.16.0" --state all

The prs command returns JSON with number, title, body, state, merged_at, author, labels, and closing_issues. PRs are fetched in batches of 50 via GraphQL to stay within API limits (milestone mode uses paginated GraphQL on the milestone's pullRequests connection).

You can also list all PRs in a milestone in a single call:

# All merged PRs in a milestone (default)
python3 scripts/gh.py prs --milestone "2.16.0"

# All states (merged, open, closed)
python3 scripts/gh.py prs --milestone "2.16.0" --state all

# Open PRs only
python3 scripts/gh.py prs --milestone "2.16.0" --state open

The milestone path uses paginated GraphQL on the milestone's pullRequests connection (100 per page), avoiding one-by-one fetches.

5. Categorize entries — strictly by issue type, never by labels or emoji

Use the Issue Type field (GitHub's native issue type, exposed as issue_type in the gh.py JSON output) to determine which section an entry belongs to.

⚠️ CRITICAL: Never use labels or title emoji prefixes for categorization. Labels like bug and enhancement, as well as title prefixes like :bug: and :sparkles:, are frequently inaccurate, missing, or contradictory to the actual issue type. The issue_type field from gh.py is the single source of truth.

issue_type value	Changelog section
Bug	### :bug: Bugs fixed
Feature or Enhancement	### :sparkles: New features & Enhancements
Task	Exclude — internal chores are not user-facing
null (not set)	Check labels as a fallback: bug label → bugs, otherwise enhancements

The gh.py issues command already includes issue_type in every entry's output. No separate GraphQL query is needed.

Preserve highlighted entries: If an entry is already featured in ### :rocket: Epics and highlights, keep it in that section when refreshing a changelog version. Do not remove a highlighted entry just because issue type categorization would otherwise place it under ### :sparkles: New features & Enhancements.

Community contribution attribution: If the issue or its fix PR has the community contribution label, add an attribution (by @<github_username>) on the changelog entry line, before the GitHub issue/PR references.

The attribution should reference the PR author, not the issue author. The prs subcommand includes the author field — use that:

python3 scripts/gh.py prs <PR_NUMBER> | python3 -c "import sys,json; print(json.load(sys.stdin)[0]['author'])"

Placement in the entry line:

- Fix description of the bug (by @username) [#<ISSUE>](...) (PR: [#<PR>](...))

Only closed issues are included. An issue must have state: "closed" to appear in the changelog. Open/unresolved issues are omitted, even if they are tracked in the milestone.

Pairing rules:

Pattern	Changelog format
Closed issue + one or more PRs fix it	Primary link = issue, PR inline comma-separated
PR exists with no linked issue	If a corresponding closed issue exists in the same milestone, link the issue. Otherwise, skip the entry (the issue must be the changelog unit).
Closed issue with no fix PR in milestone	Link the issue directly, without a PR reference.

False-positive associations: A PR may incorrectly claim to close an issue from a different context (e.g., a very old PR referencing a modern issue, or a cross-project reference). If the PR title and issue title are clearly unrelated, or the PR was created years before the issue, treat it as a data glitch and skip it. PR #3 (ancient License PR claiming to close a plugin API issue) is a known example.

5a. ⚠️ Verify PR merge status before writing

A closed issue may list closing PRs that were closed without merging (e.g., a community PR that was superseded by another). The changelog must only reference merged PRs. Verify before writing:

# Collect all PR numbers from the candidate entries and check them
python3 scripts/gh.py prs <ALL_PR_NUMBERS> | python3 -c "
import json, sys
for pr in json.load(sys.stdin):
    if pr['state'] != 'MERGED':
        print(f'WARNING: #{pr[\"number\"]} is {pr[\"state\"]} (not merged)')
"

If a closing PR is closed-unmerged, find the actual merged PR that superseded it:

1. Check the issue's closing PRs list for other PRs (there may be multiple)
2. Look for other PRs with similar titles or descriptions referencing the same issue
3. Inspect the closed PR's conversation timeline for a pointer to the replacement

Replace the reference in the changelog entry with the correct merged PR number.

5b. Security advisory (GHSA) entries

Security advisories fixed in a release are documented in the changelog even though they are neither milestone issues nor PRs. The GHSA ID and its description are supplied by the user or the release notes — they never come from the milestone fetch in step 2.

Format (matches the existing precedent in CHANGES.md, e.g. the create-font-variant arbitrary file read advisory):

- Fix <user-facing description> (https://github.com/penpot/penpot/security/advisories/GHSA-XXXX-XXXX-XXXX)

Rules:

• Place the entry under ### :bug: Bugs fixed, with no issue or PR link — only the advisory URL.
• The advisory may be draft/unpublished at changelog time (the URL 404s publicly). Do not web-fetch or verify the URL, and do not drop the entry because of that. Rely on the GHSA ID provided by the user.
• Derive the description from the supplied advisory title, imperative mood and user-facing (e.g. Fix command injection in SVG exporter via legacy fill-color).
• These entries are invisible to the automation: they are not returned by gh.py issues, not matched by --compare (step 3), not part of the PR cross-reference (step 10), and not scanned by the anomaly-report regexes (step 11, which only match issues/ and pull/ links). Add them manually.
• During pre-flight checks (step 6a) apply only the backport/duplicate check: if the same GHSA already appears in an earlier version section, remove it from the current section. Their absence from milestone cross-references is expected, not an anomaly.

6. Read the current CHANGES.md

Read the top of CHANGES.md to understand the existing format and find the insertion point (newest version goes at the top, after the # CHANGELOG header).

Key format rules from the existing file:

## <VERSION>

### :bug: Bugs fixed

- Fix description of the bug [#<ISSUE>](https://github.com/penpot/penpot/issues/<ISSUE>) (PR: [#<PR>](https://github.com/penpot/penpot/pull/<PR>))
- Fix another bug (by @contributor) [#<ISSUE>](https://github.com/penpot/penpot/issues/<ISSUE>) (PR: [#<PR>](https://github.com/penpot/penpot/pull/<PR>))

### :sparkles: New features & Enhancements

- Add new feature description [#<ISSUE>](https://github.com/penpot/penpot/issues/<ISSUE>) (PR: [#<PR>](https://github.com/penpot/penpot/pull/<PR>))

Format details:

• Entries start with - followed by a short description in imperative mood
• Primary link is always the issue (user-facing artifact)
• PR references are inline on the same line: (PR: [#<N>](<url>)) If an issue has multiple fix PRs, they are comma-separated: (PR: [#<N>](<url>), [#<M>](<url>))
• The description should describe the fix/feature from the user's perspective
• Community contributions get (by @<username>) before the issue link
• Sections are separated by a blank line between the last entry and the next section title
• Only include a section if there are entries for it
• When an entry already exists in an earlier version section, it must be removed from the current version to avoid duplicates

6a. Pre-flight checks — fix rule violations in the changelog

The LLM must apply these checks during the workflow and fix any violations directly in CHANGES.md. They are not anomalies — they are process errors that should be corrected before writing the new section.

The changelog is a snapshot of the milestone at a point in time, but milestones and changelog entries can drift. The LLM must reconcile the existing changelog against the current state of the milestone and the existing changelog entries.

For each entry that already exists in CHANGES.md (in any version section) or in the candidate set for the current milestone, check:

1. Duplicate across versions. Is the same issue already documented in another (older) version section? If yes, this is a backport:

   • The user-facing fix was already released. Remove the duplicate from the current section. The earlier version is the canonical reference.

2. Stale milestone assignment. Has the issue been moved out of the current milestone since the changelog was last updated (e.g., a fix arrived late and the issue was reassigned to a future milestone)?

   • Verify the issue is still in the current milestone via python3 scripts/gh.py issues <MILESTONE> --state all. If it's no longer there, remove the entry from the current section. (If the target section doesn't exist yet, the entry is simply dropped.)

3. Exclusion labels newly applied. Did the issue acquire a no changelog or release blocker label since the changelog was last updated? If yes, remove the entry from the current section.

4. Issue state changed. Is the issue still closed? Has it been reopened, deleted, or moved to a Rejected project status? If yes, remove the entry.

5. Unmerged or removed PR references. For every PR referenced in the entry, is the PR still merged? Was the PR closed without merging (superseded)? Was the PR moved to a different milestone? If the only referenced PR is no longer merged, fix the reference (find the actual merged fix PR) or remove the entry. A PR that is merged in a different milestone is reported as an anomaly in step 11 — do not silently remove it.

6. Issue type changed. Did the issue type change (e.g., from Bug to Task)? If the new type is Task, the issue is internal and should be removed.

7. Cross-section completeness. For every closed, non-excluded milestone issue that is not referenced in any version section of the changelog, add it to the current section (per the categorization rules in step 5).

After these checks, the changelog should be internally consistent with the milestone. Do not defer these fixes to step 11 — they are workflow errors, not anomalies. Step 11 only reports milestone mismatches that require human judgment about the team's release intent.

7. Build the description text

Derive the description from the issue title, not the PR title. Strip leading emoji prefixes (:bug:, :sparkles:, :tada:) and focus on the user-facing behavior.

Examples:

Issue title	Changelog description
Plugin API token methods fail with schema validation error on PRO	Fix Plugin API token methods failing with schema validation error on PRO
Comment content is not sanitized before rendering, enabling stored XSS	Sanitize comment content on rendering
Custom uploaded font family names are not sanitized	Sanitize font family names on custom uploaded fonts

8. Insert the section into CHANGES.md

Insert the new version section right after the # CHANGELOG header (before the previous version entry). Use the edit tool with enough context to make a unique match.

9. Verify

Read the top of CHANGES.md and confirm:

• The version header is correct
• Every entry has a GitHub link
• Entries with a fix PR have the PR sub-line
• The section ordering is correct (newest first)
• Formatting matches the surrounding entries

10. Cross-reference milestone PRs against the changelog

Issues can be fixed by PRs that aren't in the milestone, and merged PRs in the milestone may not close any tracked issue. After writing, run a full cross-reference to catch gaps:

# List all merged PRs in the milestone
python3 scripts/gh.py prs --milestone "<MILESTONE>" --state merged > /tmp/milestone-prs.json

# Extract PR numbers from the changelog section
python3 -c "
import json, re

with open('CHANGES.md') as f:
    content = f.read()

# Extract the version section (adjust regex to match the actual version)
match = re.search(r'## <MILESTONE> \(Unreleased\)\n(.*?)(?:\n## |\Z)', content, re.DOTALL)
section = match.group(1)

# Collect all PR numbers referenced
changelog_prs = set()
for m in re.findall(r'\[#(\d+)\]\(https://github\.com/penpot/penpot/pull/\d+\)', section):
    changelog_prs.add(int(m))

# Collect all milestone PRs (filtered)
with open('/tmp/milestone-prs.json') as f:
    milestone_prs = json.load(f)

milestone_merged = {pr['number'] for pr in milestone_prs}

# PRs in milestone but not in changelog
missing = sorted(milestone_merged - changelog_prs)
print(f'Milestone merged PRs: {len(milestone_merged)}')
print(f'Changelog referenced PRs: {len(changelog_prs)}')
print(f'PRs in milestone but NOT in changelog: {len(missing)}')
for num in missing:
    pr = next(p for p in milestone_prs if p['number'] == num)
    print(f'  #{num} {pr[\"title\"][:80]}')
"

For each missing PR found, decide whether it should be added to the changelog or is legitimately excluded (check its labels).

Also verify that no closed-unmerged PRs remain in the changelog:

python3 scripts/gh.py prs --milestone "<MILESTONE>" --state all | python3 -c "
import json, sys
data = json.load(sys.stdin)
closed = [p for p in data if p['state'] == 'CLOSED']
if closed:
    print('WARNING: CLOSED (unmerged) PRs in milestone:')
    for p in closed:
        print(f'  #{p[\"number\"]} {p[\"title\"][:80]}')
"

Post-edit audit checklist:

• ✅ All referenced PRs are merged (no closed-unmerged artifacts)
• ✅ Every merged milestone PR is either in the changelog or excluded by label
• ✅ PR and issue counts are internally consistent
• ✅ No false-positive PR-to-issue associations
• ✅ Advisory (GHSA) entries are not milestone PRs — their absence from the cross-reference is intentional (see step 5b)

Version section template

## <VERSION>

### :bug: Bugs fixed

- <fix description> [#<ISSUE>](https://github.com/penpot/penpot/issues/<ISSUE>) (PR: [#<PR>](https://github.com/penpot/penpot/pull/<PR>))
- <fix description> (by @contributor) [#<ISSUE>](https://github.com/penpot/penpot/issues/<ISSUE>) (PR: [#<PR>](https://github.com/penpot/penpot/pull/<PR>))
- <fix description> (https://github.com/penpot/penpot/security/advisories/GHSA-XXXX-XXXX-XXXX)

Advisory (GHSA) entries have no issue or PR link — just the advisory URL. See step 5b.

11. Generate anomaly report and save to CHANGES-ISSUES.md

After all edits and cross-referencing are complete, generate a structured report and save it to CHANGES-ISSUES.md (overwriting if exists). This provides a persistent record of any discrepancies between the milestone and the changelog.

Every issue and PR number in the report must be rendered as a full GitHub Markdown link using the same URL format as CHANGES.md:

• Issue N → [#N](https://github.com/penpot/penpot/issues/N)
• PR N → [#N](https://github.com/penpot/penpot/pull/N)

The titles and notes should also link to the corresponding issue/PR page where applicable, so the report is self-contained and clickable from any Markdown viewer.

What is an anomaly

An anomaly is a milestone-mismatch between an issue and its referenced PR. It indicates that the changelog claim "this issue is fixed by this PR, all in milestone M" is inconsistent with the actual milestone assignments. There are exactly two types:

1. Issue is in the milestone, but its referenced PR is in a different milestone (or has no milestone). The changelog claims a fix in this release, but the PR is being released elsewhere — the fix may not actually ship here.
2. PR is in the milestone, but the issue it closes is in a different milestone (or has no milestone). The PR is being released here, but the issue it fixes is being released in a different version (or never tracked in a milestone) — the changelog pairing is misleading.

Anything else is not an anomaly. Other discrepancies (exclusion labels on in-changelog issues, missing valid issues, unmerged PR references, duplicates across versions, stale milestone assignments) are rule violations that the LLM must fix directly in CHANGES.md during step 6a (pre-flight checks). They should not appear in this report — if they do, the LLM has skipped the pre-flight step and needs to re-run the workflow.

The changelog's primary unit is the issue, not the PR, so a missing or mismatched PR only matters when its issue is part of this milestone.

Run this self-contained script:

python3 << 'PYEOF'
import json, re, subprocess, sys
from datetime import datetime, timezone

MILESTONE = "<MILESTONE>"
CHANGES_MD = "CHANGES.md"
OUTPUT = "CHANGES-ISSUES.md"
REPO = "penpot/penpot"

# --- URL helpers (match CHANGES.md format exactly) ---
def issue_url(n):  return f"https://github.com/{REPO}/issues/{n}"
def pr_url(n):     return f"https://github.com/{REPO}/pull/{n}"
def issue_link(n): return f"[#{n}]({issue_url(n)})"
def pr_link(n):    return f"[#{n}]({pr_url(n)})"
def issue_link_title(n, title):
    url = issue_url(n)
    if title:
        return f"[#{n}]({url}) — [{title}]({url})"
    return f"[#{n}]({url})"
def pr_link_title(n, title):
    url = pr_url(n)
    if title:
        return f"[#{n}]({url}) — [{title}]({url})"
    return f"[#{n}]({url})"
def fmt_pr_list(nums):
    return ", ".join(pr_link(n) for n in nums)
def fmt_issue_list(nums):
    return ", ".join(issue_link(n) for n in nums)

# --- Fetch milestone data ---
result = subprocess.run(
    ["python3", "scripts/gh.py", "issues", MILESTONE, "--state", "all"],
    capture_output=True, text=True)
all_issues = json.loads(result.stdout)
issue_by_num = {i['number']: i for i  all_issues}

result = subprocess.run(
    [, , , , MILESTONE, , ],
    capture_output=True, text=True)
all_prs = json.loads(result.stdout)
pr_by_num = {p[]: p  p  all_prs}


with open(CHANGES_MD) as f:
    content = f.read()

m = re.search(rf, content, re.DOTALL)
section = m.group(1)  m  

changelog_issues = ()
 num  re.findall(r, section):
    changelog_issues.add(int(num))
 num  re.findall(r, section):
    changelog_issues.add(int(num))

changelog_prs = ()
 num  re.findall(r, section):
    changelog_prs.add(int(num))
 num  re.findall(r, section):
    changelog_prs.add(int(num))




pr_milestone_cache = {p[]: MILESTONE  p  all_prs}
issue_milestone_cache = {i[]: MILESTONE  i  all_issues}

def get_pr_milestone(pr_num):
    
     pr_num  pr_milestone_cache:
         pr_milestone_cache[pr_num]
    try:
        r = subprocess.run(
            [, , , str(pr_num), , ],
            capture_output=True, text=True, check=True)
        data = json.loads(r.stdout)
        ms = data.get()
        pr_milestone_cache[pr_num] = (ms or {}).get()
    except (subprocess.CalledProcessError, json.JSONDecodeError):
        pr_milestone_cache[pr_num] = None
     pr_milestone_cache[pr_num]

def get_issue_milestone(issue_num):
    
     issue_num  issue_milestone_cache:
         issue_milestone_cache[issue_num]
    try:
        r = subprocess.run(
            [, , , str(issue_num), , ],
            capture_output=True, text=True, check=True)
        data = json.loads(r.stdout)
        ms = data.get()
        issue_milestone_cache[issue_num] = (ms or {}).get()
    except (subprocess.CalledProcessError, json.JSONDecodeError):
        issue_milestone_cache[issue_num] = None
     issue_milestone_cache[issue_num]


EXCLUDED_LABELS = {, }
EXCLUDED_ISSUE_TYPES = {}
EXCLUDED_PROJECT_STATUS = {}

def issue_excluded(issue):
     not issue:  True
     issue.get() != :  True
     issue.get()  EXCLUDED_ISSUE_TYPES:  True
     issue.get()  EXCLUDED_PROJECT_STATUS:  True
     EXCLUDED_LABELS & (issue.get(, [])):  True
     False








anomalies_a = []  
 issue_num  sorted(changelog_issues):
    issue = issue_by_num.get(issue_num)
     not issue: 
     get_issue_milestone(issue_num) != MILESTONE: 
     pr_num  issue.get(, []):
        pr_ms = get_pr_milestone(pr_num)
         pr_ms != MILESTONE:
            anomalies_a.append({
                : issue_num,
                : issue.get(, ),
                : pr_num,
                : pr_ms,  
            })


anomalies_b = []  
 pr_num  sorted(changelog_prs):
     = pr_by_num.get(pr_num)
     not : 
     get_pr_milestone(pr_num) != MILESTONE: 
     issue_num  pr.get(, []):
        issue_ms = get_issue_milestone(issue_num)
         issue_ms != MILESTONE:
            anomalies_b.append({
                : pr_num,
                : pr.get(, ),
                : issue_num,
                : issue_ms,  
            })


def fmt_ms(ms):
     ms  ms  

with open(OUTPUT, ) as f:
    f.write(f)
    f.write(f)
    f.write()

    n_a = len(anomalies_a)
    n_b = len(anomalies_b)

    f.write()
    f.write(f)
    f.write(f)
    f.write(f)

    
     n_a or n_b:
        f.write()
        f.write(
                
                
                
                
                )

         n_a:
            f.write(f)
            by_issue = {}
             a  anomalies_a:
                by_issue.setdefault(a[], []).append(a)
             issue_num  sorted(by_issue):
                entries = by_issue[issue_num]
                title = entries[0][]
                f.write(f)
                 e  entries:
                    ms_label = fmt_ms(e[])
                    badge =   e[] is None  
                    f.write(f)
                f.write()

         n_b:
            f.write(f)
            by_pr = {}
             b  anomalies_b:
                by_pr.setdefault(b[], []).append(b)
             pr_num  sorted(by_pr):
                entries = by_pr[pr_num]
                title = entries[0][]
                f.write(f)
                 e  entries:
                    ms_label = fmt_ms(e[])
                    badge =   e[] is None  
                    f.write(f)
                f.write()
    :
        f.write()

    
    f.write()
    f.write()
    f.write(f)
    f.write(f)
    f.write(f)
    f.write(f)
    f.write(f)
    f.write(f)

(f)
PYEOF

This generates CHANGES-ISSUES.md containing only the anomalies — milestone mismatches between issues and their referenced PRs:

1. Issue in milestone, referenced PR in different milestone or no milestone — the changelog claims a fix here, but the PR is released elsewhere.
2. PR in milestone, closing issue in different milestone or no milestone — the PR is released here, but the issue it fixes belongs to another version.

Rule violations are not in the report — they are workflow errors the LLM must fix directly in CHANGES.md during step 6a (pre-flight checks). If the report contains a rule violation, the LLM has skipped the pre-flight step and needs to re-run the workflow before re-generating the report.

The report is overwritten each time it's generated, reflecting the current state of the milestone and changelog. Every number is rendered as a full [#N](https://github.com/penpot/penpot/issues/N) or [#N](https://github.com/penpot/penpot/pull/N) link so the report is self-contained and clickable in any Markdown viewer.

Key Principles

• Issue = changelog unit. The primary link always points to the user-facing issue, not the implementation PR.
• PR = implementation detail. Reference the PR inline so readers can find the code changes.
• Latest version first. New sections are inserted at the top of the changelog, below the # CHANGELOG header.
• Issue Type determines section — exclusively. Use the issue_type field from gh.py output (Bug → :bug:, Feature/Enhancement → :sparkles:). Do not use labels (bug, enhancement) or title emoji prefixes (:bug:, :sparkles:) — they are frequently wrong or contradictory. The issue_type is the single source of truth.
• User-facing descriptions. Write from the user's perspective — describe what broke and what was fixed, not internal implementation details.
• Community attribution. When the issue or fix PR has the community contribution label, add (by @<username>) on the entry line between the description and the issue link. Use the PR author (not the issue author) for the attribution.
• Only closed issues. An issue must have state: "closed" to appear in the changelog. Open/unresolved issues are omitted.
• Rejected project status. Issues marked as "Rejected" in the "Main" project board are automatically excluded by gh.py, even if they are closed. The project status is distinct from the GitHub issue state. Use --include-rejected to override this behavior.
• Excluded issues. Issues with no changelog label must be excluded. Issues with issue_type: "Task" must also be excluded — they are internal chores, not user-facing changes.
• Multiple PRs per issue. If multiple PRs fix the same issue, list them comma-separated inline: (PR: [#A](url), [#B](url)).
• Duplicate removal. If an entry already exists in a prior version section, remove it from the current version. Check for text-level duplicates (after stripping links and attributions) across version sections.
• Taiga references. If a changelog entry references a Taiga URL (tree.taiga.io), attempt to find a corresponding GitHub issue via the Taiga description text or by searching GitHub PRs that reference the Taiga URL. Replace the Taiga reference with the GitHub issue link and add the PR reference if applicable.