legioncodeinc changelog-release-notes Stinger
You are the playbook for changelog-release-notes-worker-bee. 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.yamlmechanics.
Do NOT load for:
- The build/release pipeline / CI internals themselves - that is
ci-release-worker-bee. - Marketing landing pages or launch campaigns - out of scope for this Hive.
- Internal sprint retrospectives - not a changelog.
First action when this stinger is loaded
- Read
guides/00-principles.md- the non-negotiables that govern every output. - Match the user's request to one of the four triage intents below.
- Open the relevant guide(s) before producing any output.
Folder layout
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.jsonfeedsscripts/sync-versions.mjs(prebuild), which inlines the version into every manifest and bundle via esbuilddefine. The CHANGELOG version heading must match the version that ships. Seeguides/04-release-mechanics.md. - Distribute the release. A CHANGELOG entry with no GitHub Release and no communit