azure/azure-sdk-for-js-update-changelog
Update ai-projects CHANGELOG.md after a TypeSpec regeneration. Merges new items into the existing top (Unreleased) entry when present; otherwise creates a new top entry, classifying changes into Breaking Changes / Features Added / Bugs Fixed / Other Changes buckets and syncing package.json version as needed.
npx skills add https://github.com/Azure/azure-sdk-for-js --skill update-changelog
apply-post-emitter-edits, author-samples, and author-tests skills have all completed.src/ and review/ai-projects-node.api.md.git diff HEAD -- src/ for context on hand-applied edits and bug fixes.Run from sdk/ai/ai-projects/.
Open CHANGELOG.md. Note the section ordering used in recent entries:
### Breaking Changes### Features Added### Bugs Fixed### Other ChangesVoice examples (copy this voice exactly):
project.beta.skills route for accessing skills"id property in Schedule interface to schedule_id"foundryFeatures property from EvaluationRulesCreateOrUpdateOptionalParam"TextResponseFormatConfiguration in favor of TextResponseFormat"For each item from the api-surface diff plus each hand-applied edit:
| Bucket | What goes here |
|--------|----------------|
| Breaking Changes | Removed/renamed public symbols; required→optional or optional→required; method signature changes; namespace renames. |
| Features Added | New public classes, methods, namespaces, interfaces. |
| Bugs Fixed | Behavioral fixes; redundant-property removals; correctness fixes from post-emitter workarounds. |
| Other Changes | Deprecations, internal refactors, dependency bumps. |
Beta-namespace additions still go under Features Added, with the namespace path included (e.g., project.beta.toolboxes).
When a new public method or route brings supporting request/response models, helper classes, union members, or enum values along with it, do not enumerate every supporting type in the changelog. List the new public method/route and mention the feature it enables. Only call out supporting types separately when they are independently user-facing concepts that customers would reasonably search for outside the method they support.
First, inspect the current top entry in CHANGELOG.md:
## <version> (Unreleased) (or otherwise unreleased) entry, do not create a new entry and do not bump the version. Instead, merge the new items into the existing buckets under that entry — adding new bullets, keeping the existing ones, and dropping any subsection that ends up empty. Skip Step 3.5 entirely in this case (the package.json version already matches).(Unreleased)) do you create a new top entry. Use templates/changelog-entry.md and insert it directly above that released entry.When creating a new entry, pick a tentative next version following semver against the previous CHANGELOG entry:
2.1.0 → 3.0.0).2.1.0 → 2.2.0).2.1.0 → 2.1.1).Use the header form ## <new-version> (Unreleased) so the release engineer just has to swap Unreleased for a date.
Drop empty subsections (don't leave a ### Bugs Fixed heading with no items underneath).
package.json versionSkip this step if you merged into an existing (Unreleased) entry in Step 3 — the version did not change, so package.json is already correct.
When you created a new top entry, the version field in package.json MUST match the version in that new entry. Update package.json to match (e.g., "version": "2.2.0"). Release tooling fails CI if these drift.
npx prettier --check CHANGELOG.md).package.json version field matches the top CHANGELOG entry's version (run node -p "require('./package.json').version" and compare).Done. Hand off to open-regeneration-pr.
Take azure/azure-sdk-for-js-update-changelog from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.
The instructions reference npx.
Without those the skill loads but fails at the first command.