feat(#194): update guidance and documentation for agentic scaffolds

- Refine conversational flow for architect and design change prompts.
- Clarify instructions for handling unresolved questions in design packages.
- Adjust release notes and changelog formatting for consistency.

Author: stiwicourage

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

@@ -36,13 +36,11 @@ 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`.
+- 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`
-  skill (`.github/skills/markdown-authoring/SKILL.md`).
+- When the release summary is returned as Markdown or copy-ready UI output, it must follow the `markdown-authoring` skill (`.github/skills/markdown-authoring/SKILL.md`).
 
 ## Definition of done
 

.github/copilot-instructions.md

@@ -18,8 +18,7 @@ Read these files before making non-trivial changes:
 
 Prompt templates under `.github/prompts/*.prompt.md` are not auto-loaded. Reference them explicitly in chat when you want to use one of the repository's reusable task prompts.
 
-For new or not-yet-scoped work, start with `.github/agents/architect.agent.md` and
-`.github/prompts/design-change.prompt.md`. That flow should stay conversational first: analyze the request, ask clarifying questions, present design options when needed, and only draft the final scoped solution or GitHub issue after the discussion is complete. When unresolved questions still remain, architect should surface what is settled vs unresolved before asking whether to finalize, and should allow either full finalization or a resumable design-package-only handoff. Proposed scope cuts or out-of-scope boundaries must be confirmed by the user before they are treated as final.
+For new or not-yet-scoped work, start with `.github/agents/architect.agent.md` and `.github/prompts/design-change.prompt.md`. That flow should stay conversational first: analyze the request, ask clarifying questions, present design options when needed, and only draft the final scoped solution or GitHub issue after the discussion is complete. When unresolved questions still remain, architect should surface what is settled vs unresolved before asking whether to finalize, and should allow either full finalization or a resumable design-package-only handoff. Proposed scope cuts or out-of-scope boundaries must be confirmed by the user before they are treated as final.
 
 ## Repository map
 

.github/instructions/powershell-coding-standards.instructions.md

@@ -44,9 +44,7 @@ Use this file when changing `src/public/`, `src/private/`, or PowerShell build/r
 
 ### Spacing
 
-- Use one space between language keywords and `(` in control statements such as `if (...)`, `foreach (...)`,
-  `switch (...)`,
-  `while (...)`, and `for (...)`.
+- Use one space between language keywords and `(` in control statements such as `if (...)`, `foreach (...)`, `switch (...)`, `while (...)`, and `for (...)`.
 - Use one space before an opening `{`.
 - Use one space around binary, comparison, and logical operators.
 - Use one space after commas in parameter and argument lists.

.github/prompts/design-change.prompt.md

@@ -67,8 +67,7 @@ If the user chooses **design package and GitHub issue draft**, return:
 - Recommended follow-on agent
 - GitHub issue draft
 
-If unresolved questions still remain, keep them under `Open questions` in the design package and add a short `Open
-questions` section inside the GitHub issue draft too.
+If unresolved questions still remain, keep them under `Open questions` in the design package and add a short `Open questions` section inside the GitHub issue draft too.
 
 If the user chooses **design package only**, return:
 

.github/prompts/implement-issue.prompt.md

@@ -10,12 +10,10 @@ Implement the issue in the NovaModuleTools repository using the repository-local
 
 ## Required process
 
-1. If scope, acceptance criteria, or ownership are still unclear, start with `.github/prompts/design-change.prompt.md`
-   and `architect.agent.md` before implementing.
+1. If scope, acceptance criteria, or ownership are still unclear, start with `.github/prompts/design-change.prompt.md` and `architect.agent.md` before implementing.
 2. Read `README.md`, `CONTRIBUTING.md`, `.github/copilot-instructions.md`, and `.github/pull_request_template.md`.
 3. Inspect the relevant public command, matching private helper domain, tests, and docs.
-4. If the issue is release-, workflow-, or coverage-related, also inspect the matching `.github/workflows/*.yml` and
-   `scripts/build/ci/*.ps1` files.
+4. If the issue is release-, workflow-, or coverage-related, also inspect the matching `.github/workflows/*.yml` and `scripts/build/ci/*.ps1` files.
 5. Preserve the Nova build model: use `project.json` and Nova commands for build/test/package/release behavior, and do not create hand-written source `.psm1` or module `.psd1` files.
 6. Inspect `project.json` `Manifest.PowerShellHostVersion` before changing PowerShell code, tests, or examples, and keep the implementation compatible with that target.
 7. Implement the smallest maintainable fix.
@@ -25,8 +23,7 @@ Implement the issue in the NovaModuleTools repository using the repository-local
 11. Review `README.md`, `CONTRIBUTING.md`, `CHANGELOG.md`, `RELEASE_NOTE.md`, help docs, and `docs/*.html` as applicable.
 12. If a commit message is requested, derive it from `$GIT_BRANCH_NAME` and the implemented change using the repository's Conventional Commit rules.
 13. Run the relevant validation, then summarize what changed, why, and how it was verified.
-14. If that summary is returned as Markdown or copy-ready UI output, format it according to the `markdown-authoring`
-    skill (`.github/skills/markdown-authoring/SKILL.md`).
+14. If that summary is returned as Markdown or copy-ready UI output, format it according to the `markdown-authoring` skill (`.github/skills/markdown-authoring/SKILL.md`).
 
 ## Repository-specific reminders
 

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

@@ -4,23 +4,19 @@ Prepare release-related changes in NovaModuleTools without publishing or tagging
 
 ## Required process
 
-1. Read `CHANGELOG.md`, `RELEASE_NOTE.md`, `project.json`, `README.md`, `CONTRIBUTING.md`,
-   `.github/pull_request_template.md`, and `.github/workflows/Publish.yml`.
+1. Read `CHANGELOG.md`, `RELEASE_NOTE.md`, `project.json`, `README.md`, `CONTRIBUTING.md`, `.github/pull_request_template.md`, and `.github/workflows/Publish.yml`.
 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. Use only the official Keep a Changelog section types in `CHANGELOG.md` and `RELEASE_NOTE.md`: `Added`, `Changed`,
-   `Deprecated`, `Removed`, `Fixed`, and `Security`.
+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 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.
 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.
+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
 
@@ -30,5 +26,4 @@ Prepare release-related changes in NovaModuleTools without publishing or tagging
 - Keep unreleased changelog entries aligned with the final intended behavior, not internal iteration history.
 - Keep `CHANGELOG.md` exhaustive and keep `RELEASE_NOTE.md` limited to public interface, configuration, and migration changes.
 - Treat `.github/pull_request_template.md` as the source of truth for release-preparation summaries.
-- If the summary must be pasted as one Markdown block in the UI, it should follow the `markdown-authoring` skill
-  (`.github/skills/markdown-authoring/SKILL.md`).
+- If the summary must be pasted as one Markdown block in the UI, it should follow the `markdown-authoring` skill (`.github/skills/markdown-authoring/SKILL.md`).

.github/prompts/review-change.prompt.md

@@ -9,8 +9,7 @@ Review a NovaModuleTools change set with emphasis on correctness, maintainabilit
 3. Check whether tests, docs, and changelog updates match the change.
 4. Call out the smallest set of meaningful issues first.
 5. Note any missing validation or follow-up work.
-6. If the review is returned as Markdown or copy-ready UI text, format it according to the `markdown-authoring` skill
-   (`.github/skills/markdown-authoring/SKILL.md`).
+6. If the review is returned as Markdown or copy-ready UI text, format it according to the `markdown-authoring` skill (`.github/skills/markdown-authoring/SKILL.md`).
 
 ## Repository-specific reminders
 

CHANGELOG.md

@@ -1,6 +1,6 @@
 # Changelog
 
-All notable changes to this project will be documented in this file and **PREVIEW / UNRELEASED** changes will be included in the next **stable** release!
+All notable changes to this project will be documented in this file and **UNRELEASED** changes will be included in the next **stable** release!
 
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/), and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
@@ -378,21 +378,39 @@ Keep stable `Update-NovaModuleVersion` / `% nova bump` releases on the SemVer ma
 - All basic functionality of Module is ready
 
 [Unreleased]: https://github.com/stiwicourage/NovaModuleTools/compare/2.4.0...HEAD
+
 [2.4.0]: https://github.com/stiwicourage/NovaModuleTools/compare/2.3.1...2.4.0
+
 [2.3.1]: https://github.com/stiwicourage/NovaModuleTools/compare/2.3.0...2.3.1
+
 [2.3.0]: https://github.com/stiwicourage/NovaModuleTools/compare/2.2.0...2.3.0
+
 [2.2.0]: https://github.com/stiwicourage/NovaModuleTools/compare/Version_2.1.0...2.2.0
+
 [2.1.0]: https://github.com/stiwicourage/NovaModuleTools/compare/Version_2.0.0...Version_2.1.0
+
 [2.0.0]: https://github.com/stiwicourage/NovaModuleTools/compare/Version_1.9.1...Version_2.0.0
+
 [1.9.1]: https://github.com/stiwicourage/NovaModuleTools/compare/Version_1.8.0...Version_1.9.1
+
 [1.8.0]: https://github.com/stiwicourage/NovaModuleTools/compare/Version_1.7.0...Version_1.8.0
+
 [1.3.0]: https://github.com/stiwicourage/NovaModuleTools/compare/Version_1.2.5-preview...Version_1.3.0
+
 [1.2.0]: https://github.com/stiwicourage/NovaModuleTools/compare/Version_1.1.4-preview...Version_1.2.0
+
 [1.1.3]: https://github.com/stiwicourage/NovaModuleTools/compare/Version_1.1.0...Version_1.1.3
+
 [1.1.0]: https://github.com/stiwicourage/NovaModuleTools/compare/Version_1.0.0...Version_1.1.0
+
 [1.0.0]: https://github.com/stiwicourage/NovaModuleTools/compare/Version_0.0.9...Version_1.0.0
+
 [0.0.9]: https://github.com/stiwicourage/NovaModuleTools/compare/Version_0.0.8...Version_0.0.9
+
 [0.0.7]: https://github.com/stiwicourage/NovaModuleTools/compare/Version_0.0.6...Version_0.0.7
+
 [0.0.6]: https://github.com/stiwicourage/NovaModuleTools/compare/Version_0.0.5...Version_0.0.6
+
 [0.0.5]: https://github.com/stiwicourage/NovaModuleTools/compare/Version_0.0.4...Version_0.0.5
+
 [0.0.4]: https://github.com/stiwicourage/NovaModuleTools/compare/Version_0.0.3...Version_0.0.4

RELEASE_NOTE.md

@@ -1,8 +1,7 @@
 # Release notes
 
 This file summarizes public cmdlet, CLI, configuration, and migration changes for NovaModuleTools.
-`CHANGELOG.md` remains the exhaustive record of all changes in each release. **PREVIEW / UNRELEASED**
-changes will be included in the next **stable** release!
+`CHANGELOG.md` remains the exhaustive record of all changes in each release. **UNRELEASED** changes will be included in the next **stable** release!
 
 ## [Unreleased]
 

src/resources/agentic-copilot/CHANGELOG.md

@@ -1,6 +1,6 @@
 # Changelog
 
-All notable changes to this project will be documented in this file and **PREVIEW / UNRELEASED** changes will be included in the next **stable** release!
+All notable changes to this project will be documented in this file and **UNRELEASED** changes will be included in the next **stable** release!
 
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/), and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).