Improve release skill and remove intra-release fix from v2.9.0 notes

Adds a Changelog Quality Checklist to the release skill covering:
- Diffing code between tags (not just reading commit messages)
- Tracing every 'Fixed' entry to its origin commit
- The 'would a user on the previous version notice this?' test
- A worked example of the intra-release bug pattern

Removes the 'expanded emoji picker background' fix from the v2.9.0
changelog -- that bug was both introduced and fixed within the 2.9.0
release window, so no shipped user ever saw it.

.agents/skills/release/SKILL.md

@@ -100,7 +100,64 @@ Prepend a new section to `CHANGELOG.md` directly below the `# Changelog` heading
 - Description of removed features
 ```
 
-**Rules:**
+#### Changelog Quality Checklist
+
+Before drafting any entries, run through this checklist. It is NOT optional -- skipping steps here is the most common way a release goes out with misleading notes.
+
+##### 5.1. Diff the code, not just the commit log
+
+Commit messages describe intent at the moment of commit; they over- and under-represent the cumulative effect at release time. Before drafting entries, **run a real diff** for each area of substantial change:
+
+```bash
+# Full diff between tags
+git diff v<prev>..HEAD
+
+# Or narrowed to an area you're unsure about
+git diff v<prev>..HEAD -- src/components/ComposeBox.tsx
+```
+
+Only the diff reveals intra-release churn (commits that cancel each other out, bugs introduced and then fixed, refactors that land and get reverted). Reading commit messages alone is insufficient.
+
+##### 5.2. Trace every candidate "Fixed" entry to its origin commit
+
+For each bug fix you're considering listing, find the commit that introduced the bug:
+
+```bash
+# Show the history of a file across all commits
+git log --oneline v<prev>..HEAD -- path/to/file.tsx
+
+# Or blame the specific lines the fix touched
+git blame -L <start>,<end> -- path/to/file.tsx
+```
+
+**If the introducing commit is also in this release window (i.e. after the previous tag), the bug is intra-release.** The user on the previous version never experienced it. Do NOT list it as a "Fixed" entry. Fold it into the relevant "Added" or "Changed" entry, or omit it entirely.
+
+##### 5.3. The "Would a user on the previous version notice this?" test
+
+The changelog describes the delta between the previous release and this one **from the user's perspective** -- not the development history. Before writing each entry, ask:
+
+> "Did a user on the previous published version experience this exact thing?"
+
+- If they experienced a broken state that is now fixed: **"Fixed" entry**
+- If they experienced the old behavior and now see new behavior: **"Changed" or "Added" entry**
+- If they never saw either state (introduced AND resolved within this release window): **omit entirely**
+
+This applies to more than just bugs:
+- A feature added and then reverted in the same release: omit both
+- A refactor that was done and then undone: omit both
+- A performance regression introduced and then fixed: omit both
+- A typo introduced in a new string and then corrected: mention the new string (if user-facing) as a single "Added"/"Changed" entry, with no "Fixed" entry
+
+##### 5.4. Worked example -- intra-release bug
+
+> **Scenario:** Commit A overhauls the compose box and, as a side effect, breaks the background of the expanded emoji picker. Commit B, later in the same release window, restores the background.
+>
+> **Correct changelog:** One "Added" entry describing the compose box overhaul. The emoji picker background is part of the finished state the user receives.
+>
+> **Incorrect changelog:** An "Added" entry for the overhaul AND a "Fixed" entry for the emoji picker background. The user on the previous version never saw the broken background; listing it invents a problem they didn't have and makes the release notes read like a developer changelog.
+
+#### Rules
+
 - Only include categories that have entries (omit empty categories)
 - Write **user-facing descriptions**, not raw commit messages
 - Keep descriptions concise -- one line per change
@@ -109,9 +166,9 @@ Prepend a new section to `CHANGELOG.md` directly below the `# Changelog` heading
 - Focus on what the user sees/experiences, not internal implementation details
 - Use the current date in YYYY-MM-DD format
 - **Never use Nostr protocol jargon.** NIP numbers (e.g., "NIP-89", "NIP-17"), kind numbers (e.g., "kind 30078"), and other protocol-level references must not appear in the changelog. Describe the feature in plain language from the user's perspective. For example, write "App cards for Nostr apps" instead of "App cards for Nostr apps (NIP-89)". The changelog audience is end users, not protocol developers.
-- **Collapse related work into one entry.** If a feature was added and then fixed/tweaked across multiple commits in the same release, present the finished result as a single "Added" entry. Never list something as "Added" and then also list fixes for that same thing -- the user sees the end product, not the development history.
+- **Only ship what the user sees.** If a bug was introduced AND fixed within this release, the user never saw it -- omit the fix entirely (or fold the net result into the relevant Added/Changed entry). The same applies to features that were added and reverted, refactors that cancel out, and any other intra-release churn. See the Changelog Quality Checklist above (especially 5.2 and 5.3) for the procedure to verify this.
+- **Collapse related work into one entry.** If a feature was added and then tweaked across multiple commits in the same release, present the finished result as a single "Added" entry. Never list something as "Added" and then also list fixes for that same thing -- the user sees the end product, not the development history.
 - **Omit purely internal changes.** CI fixes, build pipeline tweaks, developer tooling, and infrastructure changes should be omitted from the changelog entirely unless they have a direct, visible impact on the user experience. The changelog is for users, not developers.
-- **Compare the actual code between versions** to understand what really changed, rather than just reading commit messages. Commit messages may over- or under-represent the significance of changes.
 
 ### Step 6: Update Version in All Files
 

CHANGELOG.md

@@ -10,9 +10,6 @@
 ### Changed
 - Hatching and evolving Blobbis no longer requires posting -- focus on the care actions that matter
 
-### Fixed
-- The expanded emoji picker in feeds now has its background back
-
 ## [2.8.0] - 2026-04-16
 
 ### Added

public/CHANGELOG.md

@@ -10,9 +10,6 @@
 ### Changed
 - Hatching and evolving Blobbis no longer requires posting -- focus on the care actions that matter
 
-### Fixed
-- The expanded emoji picker in feeds now has its background back
-
 ## [2.8.0] - 2026-04-16
 
 ### Added