Release Notes

# Stakeholder Summary

Date: <DD Month YYYY>

<PROJECT-CODE-1>

- <What changed + why it matters — combines Summary and Change into one sentence>
- <What changed + why it matters — combines Summary and Change into one sentence>

<PROJECT-CODE-2>

- <What changed + why it matters — combines Summary and Change into one sentence>

---

# Detailed Release Notes

## <PROJECT-CODE>

### <Plain-language name for the change — what the user sees, not how it was built>

**Summary**
- <One sentence: what is better now, written so a PM understands in 5 seconds>

**Problem**
- <What the user or team experienced — describe the symptom, not the code>
- <Max 2 bullets>

**Change**
- <What changed, in words a non-developer understands — name the screen, page, or button>
- <Max 2 bullets. One idea per bullet. No paragraphs.>

**Impact**
- <What is better now — one short sentence>

**Scope**
- <Which screen/app/user group is affected>

**Manual QA Steps**
1. <Do X → Y should happen>
2. <Do X → Y should happen>
3. <Do X → Y should happen>

**Commits Included**
- <commit-hash-1>, <commit-hash-2>


# Stakeholder Summary

<PROJECT-CODE>

- <What changed + why it matters — combines Summary and Change into one sentence>

---

# Detailed Release Notes

## <PROJECT-CODE>

### <Improvement Name>

**Summary**
- <One sentence: what is better now>

**Problem**
- <What issue or limitation existed>

**Change**
- <What was changed in this session>

**Impact**
- <What improved as a result>

**Scope**
- <Which screen/app/user group is affected>

**Manual QA Steps**
1. <Do X → Y should happen>
2. <Do X → Y should happen>
3. <Do X → Y should happen>

**Commits Included**
- <commit-hash-1>, <commit-hash-2>


# release-notes

Generate PM-friendly release notes from git commits, session work, or completed feature work.

## Install

```bash
npx skills install https://github.com/devarfeen/agent-skills-kit --skill release-notes
```

## Update

```bash
npx skills update https://github.com/devarfeen/agent-skills-kit --skill release-notes
```

## Supports
- Date-based release notes (single date or date range)
- All-project or single-project summaries
- Session summaries (current dev session)
- Feature summaries (completed feature/task)
- Automatic commit clustering (related commits → one logical change)
- Stakeholder summary (quick-scan one-liner list at the top)
- Manual QA steps (auto-detected from specs or generated)

## Example Requests
- Generate release notes for 11 March 2026
- Generate release notes for PARTNERS-APP on 11 March
- Generate release notes for all projects on 15 April
- Summarize today's development session
- Write release notes for the RFID scanning improvements
- Summarize what we changed this session
- Create PM update for today's work

## Output Style
Uses a two-part structure in a single file:

### Part 1: Stakeholder Summary (top of file)
Quick-read bullet list structured as: **Date → Project Code → Bullet points**. Each bullet combines what changed and why it matters into one sentence. Designed for PMs who need to scan everything in 30 seconds.

### Part 2: Detailed Release Notes (after `---` separator)
Full structured entries per feature:
- Date (date-based mode only)
- Project
- Feature
- Summary
- Problem
- Change
- Impact
- Scope
- Manual QA Steps
- Commits Included

Required section order is strict: Stakeholder Summary -> optional Date -> --- -> Detailed Release Notes -> Project -> Feature -> Child sections.

Only include project sections that have confirmed changes in the selected commit/session scope.

## Manual QA Steps
Each feature entry includes a **Manual QA Steps** section:
- 3–5 practical QA steps are generated inline (Action → Expected Result format).
- Steps cover the primary happy path and one edge case, written so a manual tester can follow them without reading the code.

## Detail Level
- For git-based outputs, include concrete "what changed where" details when available:
	setting, page/view, component section, URL/route, or vi