Defer changelog updates to release PRs

.github/instructions/documentation.instructions.md

@@ -17,7 +17,7 @@ docs/
 ## When to Update Documentation
 
 - **New command or flag:** Update `docs/guides/adding-a-new-command.md` if the pattern changes; update `docs/reference/feature-status.md` with the new feature's stage.
-- **User-visible behavior change:** Add or update a `CHANGELOG.md` entry when release-note-worthy, and update relevant command docs/help when behavior affects workflows, especially `--no-prompt` or CI/script semantics.
+- **User-visible behavior change:** Update relevant command docs/help when behavior affects workflows, especially `--no-prompt` or CI/script semantics.
  - **New environment variable:** Add it to `cli/azd/docs/environment-variables.md` (canonical), and keep `docs/reference/environment-variables.md` in sync when appropriate.
 - **New extension capability:** Update `docs/architecture/extension-framework.md` and `docs/guides/creating-an-extension.md`.
 - **Feature stage change:** Update `docs/reference/feature-status.md` when a feature graduates (alpha → beta → stable).

.github/skills/azd-code-reviewer/reviewers.md

@@ -143,7 +143,6 @@ Focus areas:
 - New features: does this add a command, flag, config option, or behavior that users need to know about?
 - Changed behavior: does this change how something works that is currently documented?
 - Documentation debt: does this change make existing docs inaccurate?
-- Changelog: does this warrant a changelog entry? What category (feature, fix, breaking change)?
 - README: does the README need updating?
 - API docs: are public Go packages properly documented with godoc comments?
 - Help text: do new commands/flags have complete help strings?

cli/azd/AGENTS.md

@@ -229,6 +229,7 @@ When adding a method that mutates one of these types: take the documented lock,
 - Public functions and types must have Go doc comments
 - Comments should start with the function/type name
 - Document non-obvious dependencies or assumptions
+- **Changelog entries**: Generally defer `CHANGELOG.md` updates for core and extensions to release/version-bump PRs. Exceptions are reasonable when a PR is intentionally also preparing a release, such as for a hotfix
 - **Help text consistency**: When changing command behavior, update **all** related help text — `Short`, `Long`, custom description functions used by help generators, and usage snapshot files. Stale help text that contradicts the actual behavior is a common review finding
 - **No dead references**: Don't reference files, scripts, directories, or workflows that don't exist in the PR. If a README lists `scripts/generate-report.ts`, it must exist. If a CI table lists `eval-human.yml`, it must be included
 - **PR description accuracy**: Keep the PR description in sync with the actual implementation. If the description says "server-side filtering" but the code does client-side filtering, update the description

cli/azd/extensions/azure.ai.inspector/AGENTS.md

@@ -70,8 +70,7 @@ telemetry categories, error codes, or user-facing suggestions similar to the
 
 The embedded SPA in `internal/inspector/assets/` is a built artifact (Vite output).
 It is checked in as-is. When the SPA source is updated, replace the contents of
-`internal/inspector/assets/` and bump `version.txt` + `extension.yaml` + add a
-CHANGELOG entry.
+`internal/inspector/assets/`.
 
 ## Release preparation