Release Notes Generator

Use this skill whenever the user asks to close a sprint / cut a release — i.e. to produce release notes for the latest sprint under doc/agile/v0/ and push a draft GitHub release.

The full flow has five steps; each one is described in its own section below.

1. Prepare a feature branch from origin/main, e.g. feature/release-automation.
2. Collect PR data for every PR merged since the previous v* tag using build/scripts/collect_release_pr_data.py. Output goes to tmp/release_pr_data/ (gitignored).
3. Read the sprint backlog at doc/agile/v0/sprint_backlog_<N>.org.
4. Generate the release notes by combining the PR overviews with the sprint backlog's DONE / IN-PROGRESS / BLOCKED / POSTPONED stories, following the template in Release Notes Template. Save to doc/agile/v0/sprint_backlog_<N>_release_notes.md.
5. Tag main and open a draft GitHub release (see Tag and Release below). The release is always created in draft state so a human can review and amend before publishing.

Script: build/scripts/collect_release_pr_data.py.

• Finds the most recent v* tag via git tag --sort-v:refname= (can be overridden with --since-tag v0.0.N).
• Uses the tag's commit ISO date as the lower bound for gh pr list --search "is:pr is:merged base:main merged:>=<date>".
• For each PR it calls gh pr view --json number,title,author,mergedAt,url,body,labels,baseRefName,comments,reviews and extracts "overviews" from bot-authored comments/reviews. Recognised authors include gemini-code-assist, claude[bot], claude-code[bot], anthropic-claude[bot] (see OVERVIEW_AUTHORS in the script). It also falls back to heuristic markers (## Summary of Changes, ## Code Review, Claude's review, etc.) so new review bots will still be picked up.
• Writes tmp/release_pr_data/pr_<NNNNN>.json per PR plus a summary.json index with counts and metadata.

Run it from the project root:

python3 build/scripts/collect_release_pr_data.py

Requires gh CLI to be authenticated. Add --since-tag v0.0.N to override the detected previous release.

When drafting notes:

• The sprint backlog is the source of truth for the sprint mission, DONE=/=IN-PROGRESS=/=BLOCKED=/=POSTPONED stories, and the sprint_summary clocktable (time breakdown).
• The PR overviews are the source of truth for what actually shipped. In practice backlogs may be sparser than the merged work; the PRs cover the rest.
• Group related PRs thematically (workflow, ORE integration, market data, trading/instruments, Qt, services, build/portability, etc.). Each theme should become a sub-section under Key Improvements.
• Clock totals: if sprint_summary reads 0:00 it has not been refreshed — flag this explicitly in the Time Summary section rather than inventing numbers. Always include the PR count and dominant components as a fallback.

After the notes file is committed to main (via PR), perform:

# 1. Create a signed tag on the release commit
git tag -s v0.0.<N> -m "Sprint <N>"
git push origin v0.0.<N>

# 2. Open a draft GitHub release with the generated notes
gh release create v0.0.<N> \
    --draft \
    --title "Sprint <N>" \
    --notes-file doc/agile/v0/sprint_backlog_<N>_release_notes.md

The release remains in draft state so a human can review, add screenshots or binaries, and publish it.

Follow the following template for the release notes, replacing with actual content from sprint backlog and PR overviews.

# **ProjectName Sprint N – Release Notes**
*Month Year*

A brief 1–2 sentence summary of the sprint’s primary focus and achievements.
---

## ✅ **Highlights**

- Use bullet points to list **3–5 major accomplishments**.
- Focus on high-impact features, architectural decisions, or process improvements.
- Keep each item short and outcome-oriented.

## 🛠️ **Key Improvements**

Organize improvements into **thematic sections** (e.g., Architecture, UI, Testing, Infrastructure).

- Use bold section headers (e.g., `### **Authentication & Security**`).
- Under each, list specific changes as bullet points.
- Include technical details where relevant (e.g., libraries used, patterns applied).
- Group related stories logically; avoid listing every task.

## ⚠️ **Known Issues & Postponed**

- List **BLOCKED**, **POSTPONED**, or unresolved issues.
- For each, provide a **short reason** or status (e.g., "Deferred to next sprint", "Waiting on upstream fix").
- Do not include resolved or cancelled items.

## 📊 **Time Summary**

- Show total effort: `**Total effort**: Xh Ym`
- Show effort distribution: `**Code**: A% | **Infra**: B% | **Agile/Analysis/Doc**: C%`
- List top time-consuming tasks with durations (e.g., `Top tasks: Task A (8h), Task B (6h)`)

---

*Next sprint: One sentence summarizing the upcoming sprint mission or focus.*

---

Requirements:

• Use clean Markdown formatting with consistent emoji (✅ 🛠️ ⚠️ 📊).
• Keep the entire document under 1 page in length.
• Use bold for emphasis and `code` for filenames, commands, or libraries.
• Do not invent details — only include information present in the input.
• Match the tone: professional, factual, and developer-focused.
• Do not include headers, footers, or metadata outside the template.
• Replace ProjectName, Sprint N, Month Year, and all content with actual values from the sprint data.