Feature/183 introduce a new root level release notemd that is separate from changelogmd (#189)

Author: stiwicourage

.github/agents/release-manager.agent.md

@@ -37,6 +37,10 @@ Handle versioning, changelog shaping, release-flow documentation, and publish au
 
 - Treat release automation as high-risk.
 - Keep Keep a Changelog structure intact.
+- Use only the official Keep a Changelog section types in `CHANGELOG.md` and `RELEASE_NOTE.md`: `Added`, `Changed`,
+  `Deprecated`, `Removed`, `Fixed`, and `Security`.
+- Do not invent extra changelog section headings such as `Documentation`; place documentation-related release notes under
+  the official type that best matches the actual impact.
 - Distinguish contributor docs from end-user docs.
 - Treat `.github/pull_request_template.md` as the authoritative format for structured release summaries.
 - When the release summary is returned as Markdown or copy-ready UI output, it must follow the `markdown-authoring`

.github/agents/reviewer.agent.md

@@ -16,6 +16,8 @@ Review changes for correctness, maintainability, test coverage, workflow safety,
 - Use the PR template categories as the review frame.
 - Treat CodeScene maintainability and changed-code coverage results as release-blocking signals unless risk is accepted
   explicitly.
+- If local CodeScene tooling is unavailable, continue the review with normal validation and rely on PR/CI as the
+  effective CodeScene gate.
 - Check whether website docs preserve the CLI-vs-cmdlet separation when `docs/*.html` or help markdown changed.
 
 ## Inputs to inspect

.github/agents/test-engineer.agent.md

@@ -43,7 +43,8 @@ Improve or maintain the repository's Pester coverage, coverage-gate behavior, an
 - The changed behavior is covered.
 - The touched tests are readable and low-duplication.
 - Validation and CodeScene implications are addressed.
-- The pre-commit CodeScene safeguard is clean before the work is treated as commit-ready.
+- The pre-commit CodeScene safeguard is clean before the work is treated as commit-ready when local CodeScene tooling is
+  available.
 
 ## Must not do
 

.github/copilot-instructions.md

@@ -96,6 +96,9 @@ When CodeScene tooling is available:
 - use the `guiding-refactoring-with-code-health` skill for small, measured Code Health-driven refactors
 - use the `safeguarding-ai-generated-code` skill when deciding whether AI-touched work is ready for commit or PR handoff
 
+If CodeScene tooling is unavailable locally, continue with the normal repository validation flow and continue silently;
+the pull request and CI flow remains the effective CodeScene gate.
+
 For documentation-only changes, executable validation may be skipped if no code path or workflow behavior changed.
 
 ## File formatting rule

.github/instructions/release-policy.instructions.md

@@ -15,6 +15,10 @@ automation.
 - Treat `CHANGELOG.md` as the exhaustive release history.
 - Treat `RELEASE_NOTE.md` as the interface-focused summary for public cmdlet, CLI, configuration, and migration changes.
 - Keep `## [Unreleased]` valid and readable.
+- Use only the official Keep a Changelog section types in both files: `Added`, `Changed`, `Deprecated`, `Removed`,
+  `Fixed`, and `Security`.
+- Do not add custom section headings such as `Documentation`; place documentation-related release notes under the
+  official type that best matches the real change.
 - If `RELEASE_NOTE.md` has no public API or workflow changes under `## [Unreleased]`, keep the exact placeholder under
   `### Added`: `No public API or workflow changes in this release. Internal maintenance only.`
 - If `RELEASE_NOTE.md` has real release-note entries, do not keep that placeholder.

.github/prompts/prepare-release.prompt.md

@@ -9,15 +9,19 @@ Prepare release-related changes in NovaModuleTools without publishing or tagging
 2. Inspect the touched versioning, package, publish, or release tests.
 3. Confirm whether the change affects stable releases, prereleases, or both.
 4. Update changelog, release notes, and contributor docs as needed.
-5. Check whether `RELEASE_NOTE.md` needs the placeholder rule under `## [Unreleased]`:
-    - If there are no real public API or workflow changes, ensure `### Added` contains exactly
+5. Use only the official Keep a Changelog section types in `CHANGELOG.md` and `RELEASE_NOTE.md`: `Added`, `Changed`,
+   `Deprecated`, `Removed`, `Fixed`, and `Security`.
+   - Do not create custom headings such as `Documentation`; place documentation-related release notes under the official
+     type that best matches the actual impact.
+6. Check whether `RELEASE_NOTE.md` needs the placeholder rule under `## [Unreleased]`:
+   - If there are no real public API or workflow changes, ensure `### Added` contains exactly
       `No public API or workflow changes in this release. Internal maintenance only.`
-    - If there are real release-note entries, remove that placeholder.
-6. Keep `RELEASE_NOTE.md` free of compare-link footer URLs.
-7. Validate the relevant release or versioning path.
-8. Summarize the result using the exact structure from `.github/pull_request_template.md`.
-9. Make the summary concise, reviewer-focused, directly reusable, and compliant with the `markdown-authoring` skill
-   (`.github/skills/markdown-authoring/SKILL.md`) when the output is returned as Markdown.
+   - If there are real release-note entries, remove that placeholder.
+7. Keep `RELEASE_NOTE.md` free of compare-link footer URLs.
+8. Validate the relevant release or versioning path.
+9. Summarize the result using the exact structure from `.github/pull_request_template.md`.
+10. Make the summary concise, reviewer-focused, directly reusable, and compliant with the `markdown-authoring` skill
+    (`.github/skills/markdown-authoring/SKILL.md`) when the output is returned as Markdown.
 
 ## Repository-specific reminders
 

.github/skills/codescene-quality/SKILL.md

@@ -29,6 +29,8 @@ Use the narrower sibling skills when the task is more specific:
 - Treat Code Health as the repository's authoritative maintainability signal.
 - Aim for Code Health `10.0` on touched files, not merely "good enough."
 - Treat CodeScene findings as actionable maintainability signals.
+- If CodeScene tooling is unavailable locally, continue with the normal repository validation flow and continue silently;
+  pull requests and CI remain the effective CodeScene gate.
 - Fix duplicated test structure by extracting or parameterizing setup.
 - Add the smallest test that covers the missing changed-code branch.
 - Prefer incremental refactors over large rewrites.
@@ -42,7 +44,7 @@ Use the narrower sibling skills when the task is more specific:
 ## Verification
 
 - Re-run the affected test file(s)
-- Re-run the CodeScene file review after the refactor
-- Run the pre-commit safeguard before suggesting a commit
-- Run a change-set analysis before suggesting a PR for larger branch work
+- Re-run the CodeScene file review after the refactor when local CodeScene tooling is available
+- Run the pre-commit safeguard before suggesting a commit when local CodeScene tooling is available
+- Run a change-set analysis before suggesting a PR for larger branch work when local CodeScene tooling is available
 - Run `./run.ps1` after code changes

.github/skills/release-and-changelog/SKILL.md

@@ -26,6 +26,10 @@ Use this skill when working on semantic versioning, release automation, package
 
 - Keep unreleased entries readable and outcome-focused.
 - Keep `CHANGELOG.md` exhaustive and keep `RELEASE_NOTE.md` limited to interface-facing change summaries.
+- Use only the official Keep a Changelog section types: `Added`, `Changed`, `Deprecated`, `Removed`, `Fixed`, and
+  `Security`.
+- Do not create custom changelog headings such as `Documentation`; place documentation-related release notes under the
+  official type that best matches the actual release impact.
 - If `RELEASE_NOTE.md` has no public API or workflow changes under `## [Unreleased]`, keep the exact placeholder under
   `### Added`: `No public API or workflow changes in this release. Internal maintenance only.`
 - If `RELEASE_NOTE.md` has real release-note entries, remove that placeholder.
@@ -38,6 +42,7 @@ Use this skill when working on semantic versioning, release automation, package
 ## Common pitfalls
 
 - Logging internal iteration history in the changelog instead of final unreleased behavior
+- Using unofficial changelog section types such as `Documentation`
 - Copying internal-only changelog detail into `RELEASE_NOTE.md` when public interfaces are unchanged
 - Leaving the no-public-changes placeholder in place after real release-note entries were added
 - Forgetting that `main` and `develop` have different publish/version roles

.github/skills/safeguarding-ai-generated-code/SKILL.md

@@ -30,10 +30,13 @@ Do not use this skill for broad refactoring discovery or project-level prioritiz
 1. After each AI modification to a file, run `code_health_review` on that file.
 2. If the review reports maintainability problems or regression risk, refactor the file in small steps and review it
    again.
-3. Run `pre_commit_code_health_safeguard` before commit-oriented recommendations as a broader gate across staged or
-   modified files.
-4. Run `analyze_change_set` before PR-oriented recommendations as a final branch-level gate.
-5. If either later gate reports a regression, inspect the affected files with `code_health_review` and keep iterating
+3. When local CodeScene tooling is available, run `pre_commit_code_health_safeguard` before commit-oriented
+   recommendations as a broader gate across staged or modified files.
+4. When local CodeScene tooling is available, run `analyze_change_set` before PR-oriented recommendations as a final
+   branch-level gate.
+5. If local CodeScene tooling is unavailable, continue with the normal repository validation flow and continue silently;
+   pull requests and CI remain the effective CodeScene gate.
+6. If either later gate reports a regression, inspect the affected files with `code_health_review` and keep iterating
    until the issue is removed or the user explicitly accepts the risk.
 
 ## Common mistakes

CHANGELOG.md

@@ -25,6 +25,8 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
     - Treats CodeScene Code Health as authoritative, requires safeguard checks before commit/PR readiness, and carries
       the
       repository's trailing-newline formatting rule into the agent flow.
+      - Keeps local agentic work moving silently when CodeScene tooling is unavailable on a contributor machine, while
+        pull requests and CI remain the effective CodeScene gate.
     - Adds repository-local PowerShell style guidance for indentation, spacing, braces/wrapping, and blank-line usage.
     - Adds a dedicated docs-site agent and documentation-separation guidance so website docs keep a clear CLI-vs-cmdlet
       split.
@@ -49,6 +51,13 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 - `Package.Latest` now supports policy values: `"never"`, `"stable"`, and `"always"`.
   - `"stable"` keeps the floating `latest` alias pinned to stable package versions.
   - Legacy boolean values still work for now and map to `"always"` / `"never"` for backward compatibility.
+- Release-history handling now uses a separate root-level `RELEASE_NOTE.md`.
+    - `CHANGELOG.md` remains the exhaustive release history.
+    - `RELEASE_NOTE.md` now captures only public cmdlet, CLI, configuration, and migration-impacting changes, including
+      backfilled summaries for the existing released versions in `CHANGELOG.md`.
+    - `Tests.yml` now validates both files, and `Publish.yml` now finalizes both files during stable release
+      preparation.
+    - The public release-notes page now renders `RELEASE_NOTE.md` instead of the full changelog feed.
 
 ### Deprecated