# Patch Notes

> Generate an in-app patch notes entry for the current wowup-electron version, if one isn't already present in CHANGELOGS.

- Skill: `wowup/patch-notes` (Agent Skill)
- Install (CLI): `npx skillmds@latest add wowup/patch-notes`
- Raw SKILL.md: https://api.skillmd.com/api/skills/wowup/patch-notes/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: wowup (https://skillmd.com/u/wowup)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/wowup/patch-notes

---


# Generate Patch Notes

WowUp's in-app "What's New" dialog is driven by the `CHANGELOGS` array at the top of
[`wowup-electron/src/app/services/wowup/patch-notes.service.ts`](../../../wowup-electron/src/app/services/wowup/patch-notes.service.ts).
Each entry is `{ Version: string, html: string }`, newest first. Do **not** touch
`wowup-electron/src/assets/changelog.json` — that's a legacy file for pre-2.1.0 releases and is no longer
extended.

## Step 1 — Determine the target version

Read `version` from `wowup-electron/package.json`. Strip any pre-release/build suffix
(`-beta.1`, `-alpha.2`, etc.) — every existing `CHANGELOGS` entry uses a bare `X.Y.Z`, never a
pre-release tag.

## Step 2 — Check if it already exists

Search the `CHANGELOGS` array for an entry whose `Version` matches. If found, **stop** — tell the
user the entry already exists (quote it) and do not modify the file.

## Step 3 — Find the source material

The current top entry of `CHANGELOGS` is the previous released version. Find its git tag with
`git tag --list "v<prevVersion>*" --sort=-v:refname` (tags follow `v2.22.1`, or
`v2.22.1-beta.N` if no stable tag was ever cut). Use the most relevant tag as the base and diff
to `HEAD`:

```
git log --oneline <baseTag>..HEAD -- wowup-electron/src wowup-electron/app
```

If no matching tag exists at all, ask the user for the right base ref instead of guessing.

If that tag *does* exist but the range is empty (`HEAD` is the tagged commit, i.e. everything
interesting is still uncommitted — this happens mid-release), fall back to
`git diff <baseTag> -- wowup-electron/src wowup-electron/app` and `git status` instead of
stopping. Don't ask the user to commit first; just work from the working tree.

## Step 4 — Draft the entry

Read the actual commits/diffs (not just messages) for anything non-obvious. Group into
whichever of these sections apply — skip empty ones, keep existing entries' ordering:

1. `Features` (new user-facing capability)
2. `Changes` (behavior/UX tweaks, non-breaking)
3. `Fixes` (bug fixes)

Write each bullet as a short, user-facing sentence (not a commit message) — no ticket numbers,
no internal file paths, no "refactor"/"chore" noise. Skip commits/diff hunks that are purely
internal (lint, tests, CI, dependency bumps, config/build tooling, the ongoing UI-decoupling
migration) unless they fix a user-visible bug. Match the plain style of the two most recent
entries (`2.22.1`, `2.22.0`) — no inline `style=` attributes, just:

```html
<h4>Features</h4>
<ul>
<li>...</li>
</ul>
<h4>Fixes</h4>
<ul>
<li>...</li>
</ul>
```

**If nothing user-facing survives that filter** (everything found is internal refactor, tooling,
or config), don't stop and ask what to write. Fall back to a minimal default entry instead —
this mirrors how past releases with a quiet cycle were actually written (see `2.22.1`'s own
"Various bug fixes"):

```html
<h4>Fixes</h4>
<ul>
<li>Various bug fixes and improvements</li>
</ul>
```

Flag clearly in the hand-off (Step 6) that the default was used and why, so it's obvious this is
a placeholder rather than a researched entry.

## Step 5 — Insert

Add the new `{ Version, html }` object as the **first** element of the `CHANGELOGS` array
(right after `const CHANGELOGS: ChangeLog[] = [`), preserving the descending-version order of
every entry after it.

## Step 6 — Hand off

Show the user the diff. This is a first draft of customer-facing release copy — tell them to
proofread wording/ordering before it ships, don't present it as final.