technical-changelog

Produce a **one-page technical report** of what changed for a release, stored in `docs/technical-changelog/<base>-<next>.md`. The report must be grounded in the **real diff** — added/modified/removed code, CLI-flag / requirements-doc / plugin / dependency deltas — **not** commit messages or the requirements docs (`docs/*.md` and `docs/ai/*.md` describe the *end state* and the *whole* feature history, so they routinely credit the range with work that predates it, or describe posture that was already true). Every claim is a verified delta between the base tag and HEAD. ## The two facts that make this skill necessary 1. **HEAD is the next, unreleased version.** `package.json` still holds the *last* released version (and it usually matches the base tag), so the release number can't be read from the repo — **you must ask the user** what the next planned version is. 2. **The base is always the most recent production release tag** (e.g. `v0.19.0`), and the range is `<base>..HEAD`. Pre-release tags (`-rc.1`, `-beta`) are never the base. ## Glassbox-specific traps (read these before writing) - **The requirements docs (`docs/N-topic.md`, `docs/ai/*.md`, `CLAUDE.md`) describe the end state, not the range.** They are maintained in-sync and describe a whole subsystem as it stands — including parts that shipped in *earlier* releases. Treat them as leads to verify against the diff, never as sources to quote. A doc paragraph about "the plugin system" may span five releas...