Openmeld Changelog Agent Skill

OpenMeld Changelog

Keep changelog/entries/*.md as the human- and agent-authored source of truth.

Treat CHANGELOG.md, changelog/index.json, and changelog/releases/*.md as

generated projections. Read developing/engineering/changelog.md before

editing either source or projections.

Choose the job

• Record a change: inspect the implementation and add one concise draft

entry when users or contributors gain, lose, or materially experience a

capability.

• Publish a change: add publishedAt, optional release, and concrete

evidence only after the delivery claim is proven.

• Backfill history: reconstruct an omitted entry from tags, commits, pull

requests, tests, deployment records, or other durable evidence. Use the

original availability date, not today's date.

• Prepare release notes: publish the applicable entries, rebuild the

projections, and hand the generated release file to the authorized release

workflow. A notes file is not release authorization.

Gather evidence

Use the coding agent's native file, Git, GitHub, test, and search tools. No

custom Changelog command is required for investigation or writing.

Establish these facts separately:

• what behavior changed;
• who can notice or use it;
• which code, pull request, or commit contains it;
• whether it was merged;
• whether the relevant component was delivered; and
• whether any required real-user smoke produced the visible outcome.

Merge, tag, deployment, and smoke are different claims. Keep an entry draft

when the evidence proves only an earlier claim.

Decide whether to record it

Record changes that affect users, operators, integrators, or contributors:

• new or removed capabilities;
• material workflow or behavior improvements;
• user-visible fixes and security changes;
• breaking behavior and deprecations; or
• developer-facing changes that alter supported integration or contribution

work.

Skip internal refactors, test-only changes, routine dependency maintenance, and

documentation cleanup when they do not change an external workflow. Combine

several implementation commits into one user-meaningful entry when they deliver

one outcome.

Write the entry

Use a unique lowercase slug for both the filename and id. Write native-level

English for OpenMeld's North American audience. Lead with what is now possible

or what changed, not implementation details.

---
id: slack-channel-invitations
title: Invite teammates from Slack
kind: new
areas: ["channels", "center-agent"]
audiences: ["admins"]
---

Organization admins can invite a teammate while working with the Center Agent
in Slack, without switching to a separate setup flow.

That entry is a draft. Publish it only after delivery is proven:

publishedAt: 2026-08-17
release: v0.3.60
evidence: ["pr:72", "commit:1d5254d", "workflow:123456789"]

release is optional for continuously delivered changes. Every published entry

requires durable evidence. Keep uncertain historical work as a draft rather

than inventing a date, scope, or release.

Rebuild and verify

Run:

pnpm changelog:build
pnpm changelog:check

Review the resulting diff. A complete change has valid source entries,

up-to-date deterministic projections, and no unsupported publication claim.

For a historical backfill, also confirm that adding the older entry placed it

by publishedAt rather than by the date of the backfill commit.