release: 0.7.1-rc.2

.agents/skills/check-changes/SKILL.md

@@ -32,11 +32,21 @@ release.
    Open `CHANGES.md` and extract every bullet under `## Development`.
 
 4. **Cross-reference.**
-   For each commit that represents a user-visible change (type `feat`, `fix`,
-   `refactor`, or `perf`), check whether a corresponding bullet exists in the
-   Development section. A bullet does not need to quote the commit message
-   verbatim -- it only needs to describe the same change at a short summary
-   level.
+   `CHANGES.md` opens with a comment block stating what qualifies for an entry.
+   Read it first; it is authoritative and the rules below restate only what
+   this check needs.
+
+   A commit needs a bullet when it adds something a user can use, changes
+   behaviour they would be surprised by, removes something, or fixes a bug
+   that was BROKEN IN A RELEASED VERSION. A bullet does not need to quote the
+   commit message -- it only needs to describe the same change.
+
+   A commit does NOT need one when it is refactoring, a test, CI, an internal
+   rename, or a dependency bump with no user-visible effect. Nor when it fixes
+   a bug that never shipped: if the last released version did not have the
+   defect, the changelog has nothing to say about it. That case is common on a
+   long branch and is the one most often reported as a false gap -- check the
+   bug's origin before flagging a missing entry, not just the commit's type.
 
 5. **Check each bullet against the length rule.**
    Per the "Changelog Entries" section of CONTRIBUTING.md, a bullet is at most
@@ -45,15 +55,23 @@ release.
    ones that exceed it, with their count. Do not measure released `## Version`
    sections -- a section is frozen once cut and is never rewritten.
 
-6. **Report findings.**
+6. **Check the section against the entry-count limits.**
+   `CHANGES.md`'s comment block sets a soft limit of **10** bullets per version
+   section and a hard limit of **50**, counting every bullet across its
+   subsections. Report the count. Over the soft limit, name the entries that
+   look mergeable or cuttable. Over the hard limit, say plainly that the
+   release must not ship until they are merged or cut.
+
+7. **Report findings.**
    - List commits with NO changelog entry (missing entries -- these must be
      added).
    - List changelog bullets that appear to describe nothing in the commit
      history (stale or speculative entries -- flag for author review).
    - List bullets over the 25-word limit, each with its count, and propose a
      shorter wording.
+   - Report the section's bullet count against the soft and hard limits.
    - If everything matches, report "CHANGES.md is current."
 
-7. **Do not edit CHANGES.md automatically.**
+8. **Do not edit CHANGES.md automatically.**
    Propose the missing bullets in your report and let the developer apply them.
    The developer owns the changelog wording.

.agents/skills/check-docs/SKILL.md

@@ -45,8 +45,12 @@ Verify that all project documentation is accurate and up to date.
    (e.g., `1.0.0`) must match the version in root `package.json`.
 
 6. **Check CHANGES.md structure.**
-   Confirm the file starts with a `## Development` section and that previous
-   release sections follow the `## Version X.Y.Z` heading format (no date).
+   Confirm the file carries its rules comment block, that `## Development` is
+   the first heading after it, and that previous release sections follow the
+   `## Version X.Y.Z` heading format (no date). The block sits above
+   `## Development` on purpose: `release-notes.mjs` extracts only from a
+   `## Version` heading to the next `## `, so anything above the first one
+   never reaches a GitHub release.
 
 7. **Report.**
    List every issue found (missing files, broken nav links, stale commands,

AGENTS.md

@@ -323,7 +323,9 @@ more accurately.
 Design specs and implementation plans live in `.superpowers/` which is
 git-ignored. When planning a multi-step task, write a plan there first. The
 `superpowers:writing-plans` skill guides the process. CHANGES.md entries are
-planned at the plan stage, not after the fact.
+planned at the plan stage, not after the fact -- and planned against the rules
+block at the top of `CHANGES.md`, which decides what earns an entry at all.
+Most of a plan's tasks earn none.
 
 ---
 

CHANGES.md

@@ -1,15 +1,51 @@
 # SkillKeeper Changelog
 
+<!--
+  RULES FOR THIS FILE. Read them before adding an entry.
+
+  Audience: someone deciding whether to upgrade. Not a commit log, and not a
+  record of how the code got this way -- that belongs in commit messages and
+  code comments, both of which survive and are searchable.
+
+  LIMITS per version section, counting every bullet across its subsections:
+    soft  10  -- aim for this. Over it, look for entries to merge or cut.
+    hard  50  -- a release must not ship with more. Merge related entries into
+                 one that names the feature, or cut what does not affect a
+                 user.
+
+  What goes in:
+    - A feature, option or command a user can now use.
+    - A change in behaviour they would otherwise be surprised by.
+    - A fix for something that was BROKEN IN A RELEASED VERSION.
+    - A removal, or anything needing action on upgrade.
+
+  What stays out:
+    - Anything fixed before it ever shipped. If a released version never had
+      the bug, the changelog has nothing to say about it. Before the first
+      release, that is every fix.
+    - Refactoring, test changes, CI, internal renames, dependency bumps with
+      no user-visible effect.
+    - The reasoning behind a change. One clause of why is fine when it changes
+      what a reader does; an essay is not.
+
+  Form:
+    - One entry per user-visible thing. Present tense, active voice.
+    - Name the command or option in backticks, so it is greppable.
+    - Wrap at 80 columns. ASCII only (see AGENTS.md).
+
+  Sections: `## Development` collects unreleased entries. `bump-version`
+  promotes it to `## Version <v>` and `release-notes.mjs` extracts that section
+  for the GitHub release, so the heading format matters.
+-->
+
 ## Development
 
-## Version 0.7.1-rc.1
+## Version 0.7.1-rc.2
 
 ### Changed
 
-- Updated bundled dependencies, including the SHA-256, Argon2, AES and TOML
-  implementations. No behaviour changes: the hashing and key-derivation test
-  vectors are unchanged, so existing skill hashes and PPK keys read exactly as
-  before.
+- Adding a repository that fails now keeps the dialog open and states the
+  reason, instead of closing and leaving only a notification.
 
 ## Version 0.7.0
 

CONTRIBUTING.md

@@ -42,6 +42,10 @@ Every user-visible change gets a bullet under `## Development` in
 [`CHANGES.md`](CHANGES.md), grouped under `### Added`, `### Changed`, or
 `### Fixed`.
 
+`CHANGES.md` opens with a comment block stating what qualifies for an entry and
+what does not. That block is authoritative; read it before adding a bullet. The
+rules below are additional, not a summary of it.
+
 **Rules:**
 
 - Keep each bullet to 25 words or fewer, counted as whitespace-separated

Cargo.toml

@@ -10,7 +10,7 @@ members = [
 
 [workspace.package]
 edition = "2021"
-version = "0.7.1-rc.1"
+version = "0.7.1-rc.2"
 license = "Apache-2.0"
 
 [workspace.dependencies]

apps/desktop/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@skillkeeper/desktop",
-  "version": "0.7.1-rc.1",
+  "version": "0.7.1-rc.2",
   "private": true,
   "description": "Install and manage skills and hooks for AI coding agents",
   "author": {

apps/desktop/src-tauri/tauri.conf.json

@@ -1,7 +1,7 @@
 {
   "$schema": "https://schema.tauri.app/config/2",
   "productName": "SkillKeeper",
-  "version": "0.7.1-rc.1",
+  "version": "0.7.1-rc.2",
   "identifier": "dev.lorem.skillkeeper",
   "build": {
     "beforeDevCommand": "pnpm exec vite",

package.json

@@ -1,6 +1,6 @@
 {
   "name": "skillkeeper",
-  "version": "0.7.1-rc.1",
+  "version": "0.7.1-rc.2",
   "private": true,
   "type": "module",
   "description": "Install and manage skills and hooks for AI coding agents",

packages/i18n/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@skillkeeper/i18n",
-  "version": "0.7.1-rc.1",
+  "version": "0.7.1-rc.2",
   "private": true,
   "author": "Lorem Dev",
   "homepage": "https://lorem-dev.github.io/skillkeeper/",