changelog-release-notes-stinger

# changelog-release-notes Stinger You are the playbook for `changelog-release-notes-wasp-drone`. Every invocation should leave one concrete artifact: a ready-to-commit CHANGELOG.md entry, a version-bump decision, GitHub Release notes, or a changelog audit. The research in `research/` backs the format and semver claims in these guides. This skill is specific to **@deeplake/hivemind** - Activeloop's cloud-backed shared memory for coding agents (TypeScript, Node >=22, ESM, published to npm as a library plus a CLI). The audience is developers who run `npm i -g @deeplake/hivemind` and the six-harness users. Release notes speak to capture / recall / skillify / harness changes, not marketing fluff. ## When this stinger applies Load this stinger for any of: - Writing a CHANGELOG.md entry for a Hivemind release. - Deciding the version bump (patch / minor / major) for a set of changes. - Drafting GitHub Release notes from the CHANGELOG entry. - Auditing the existing CHANGELOG for quality, cadence, or honest scope. - Tying a release to the `sync-versions.mjs` + `release.yaml` mechanics. Do NOT load for: - The build/release pipeline / CI internals themselves - that is `ci-release-wasp-drone`. - Marketing landing pages or launch campaigns - out of scope for this Wasp Nest. - Internal sprint retrospectives - not a changelog. ## First action when this stinger is loaded 1. Read `guides/00-principles.md` - the non-negotiables that govern every output. 2. Match the user's request to one of the four triage intents below. 3. Open the relevant guide(s) before producing any output. ## Folder layout ```text changelog-release-notes-stinger/ +- SKILL.md (this file) +- README.md (one-page human overview) +- guides/ | +- 00-principles.md (core doctrine: user-centric, honest scope, one source of truth) | +- 01-changelog-format.md (Keep-a-Changelog CHANGELOG.md + GitHub Releases for a CLI/library) | +- 02-semver-decisions.md (patch vs minor vs breaking; the contract surfaces that break) | +- 03-copy-craft.md (release-note writing: impact-first, honest scope, the before/after test) | +- 04-release-mechanics.md (sync-versions.mjs + release.yaml; how the changelog ties in) | +- 05-audit-playbook.md (scoring framework for the existing CHANGELOG) +- examples/ | +- minor-release.md (a Hivemind minor-release CHANGELOG entry from raw PRs) | +- breaking-change.md (a harness/MCP/schema contract break with migration notes) | +- audit-report-example.md (filled-in audit of a hypothetical CHANGELOG) +- templates/ | +- changelog-skeleton.md (a fresh CHANGELOG.md skeleton) | +- changelog-entry.md (a single release-notes entry template) +- reports/ | +- README.md (where past audit reports accumulate) +- research/ +- research-plan.md +- research-summary.md +- index.md +- internal/command-brief-notes.md +- external/keep-a-changelog.md +- external/semver.md +- external/changelog-copy-craft.md ``` ## Critical directives These apply on every invocation. Full justifications in `guides/00-principles.md`. - **Never paste raw commit logs into the CHANGELOG.** Re-frame commits for what changed for the person installing or upgrading the package. - **Name the user-visible behavior, not the implementation.** "Recall now returns results in relevance order" beats "refactored the recall ranking pipeline." - **Get the semver bump right.** A harness contract, MCP tool surface, or Deep Lake schema change is the breaking-change surface for this package. See `guides/02-semver-decisions.md`. - **Include honest scope.** When users expect something that did NOT ship, say so in one sentence. - **One source of truth for the version.** `package.json` feeds `scripts/sync-versions.mjs` (prebuild), which inlines the version into every manifest and bundle via esbuild `define`. The CHANGELOG version heading must match the version that ships. See `guides/04-release-mechanics.md`. - **Distribute the release.** A CHANGELOG entry with no GitHub Release and no communit