igniteui-cli-changelog

# Changelog Release notes for **Ignite UI CLI** live in [`CHANGELOG.md`](../../../CHANGELOG.md). A section is written when a release is cut (commits like `chore(*): cut 15.8.1`), summarizing the PRs merged since the previous cut. --- ## Input - **Version** and **date** of the release (e.g. `15.9.0`, `2026-10-15`). If missing, stop and ask. - **Mode**: - `draft` (default): output the section text only; the working tree stays unchanged. - `write`: insert the section at the top of `CHANGELOG.md`. - Optional **range**: a commit range to use instead of "since the last cut". --- ## Limits - Your one change is the new section at the top of `CHANGELOG.md`, in `write` mode only. Existing release sections stay as they are. - Versioning and publishing belong to the release process: `npm run release` and `npm run version` are never run. - Every bullet describes something visible in the commits and their diffs. --- ## Steps ### 1. Find the Range The previous release is the most recent commit whose subject matches `cut <version>` (e.g. `git log --format='%h %s' | grep -E 'cut [0-9]+\.[0-9]+'`). Not every commit touching `CHANGELOG.md` is a cut. Range = that commit (exclusive) to `HEAD`, unless the user gave one. ### 2. Collect Changes `git log --format='%h %s' <range>`. Subjects end with `(#<PR>)`. For each PR-level commit: - read the diff summary (`git show --stat <hash>`) and, where the subject is vague, the relevant diff; - if the `gh` CLI is available and authenticated, `gh pr view <PR>` for the description. Descriptions are often the empty PR template; then rely on the diff. ### 3. Select and Group Classify each commit by its **effect on users**, not only by its prefix: | Commit | Treatment | |---|---| | Release cut, merge commit | Skip | | Only touches `CHANGELOG.md` (e.g. rewording an older section) | Skip | | Dependency bump of repository tooling (dev deps, lockfile, MCP server deps) | Fold into **one** `build(deps)` bullet listing notable packages and all PR links | | Dependency or version change that alters what scaffolded projects get (template `package.json`, `constants.ts`, template `packages`) | Its own bullet as `chore(<framework>)`, even if the commit says `build(deps)` | | No conventional prefix | Infer type and scope from the diff; mention the inference under "Needs human input" | Merge several PRs about the same thing into one bullet with all PR links, for example: ```markdown * **build(deps):** Updated workspace dependencies, including `axios` 1.20.0 and `js-yaml` 4.3.2. [#1802](https://github.com/IgniteUI/igniteui-cli/pull/1802), [#1805](https://github.com/IgniteUI/igniteui-cli/pull/1805) ``` ### 4. Write in the Existing Style Study the two most recent sections **before the target version** and match them: ```markdown # <version> (<YYYY-MM-DD>) ## What's Changed * **<type>(<scope>):** <One or two sentences in past tense describing the user-visible effect.> [#<PR>](https://github.com/IgniteUI/igniteui-cli/pull/<PR>) ``` - `<type>` follows the commit's conventional type (`feat`, `fix`, `chore`, `docs`, `build`). - `<scope>` names the **area users see**, normalized to: `angular`, `react`, `webcomponents`, `blazor`, `templates` (several frameworks), `cli`, `schematics`, `mcp`, `cd`, `deps`. Map commit scopes accordingly: `chore(cli)` that bumps Angular templates → `chore(angular)`; `feat(breadcrumb)` for a Web Components template → `feat(webcomponents)`; `wc` / `igc-ts` → `webcomponents`; `igr-ts` → `react`; `igx-ts` → `angular`. - Describe the effect for users (what scaffolded projects get, what a command now does), not the implementation. - For template additions, list the component names. For version updates, name the packages and ranges, wrapped in backticks. - Order: lead with the most user-visible changes (new features, then fixes), keep `chore` items after them, and put `build(deps)` last. Older sections are not strictly consistent; do not reorder to an exact rule. ### 5. Surfacing Problems If a commit's purpose cannot be determined from its subject, diff and PR, list it under "Needs human input" in your output instead of guessing. ### 6. Follow-up Corrections When the user corrects something after the report (a reworded bullet, a different scope, an answer to "Needs human input"), change only the affected bullets. Do not re-collect the whole range unless the range itself changed. --- ## Final Report - The section text (always). - In `write` mode: confirmation it was inserted at the top, and `git diff --stat`. - "Needs human input" list, if any. ## Final Self-Validation - [ ] Git was used only as the `AGENTS.md` git rules allow for this session. - [ ] In `draft` mode, no file changed; in `write` mode, only `CHANGELOG.md` changed and no existing section was altered. - [ ] Every PR in the range is either in a bullet, deliberately skipped (release cut, merge, `CHANGELOG.md`-only), or listed under "Needs human input". - [ ] Every bullet links its PR(s) and uses a normalized scope.