feat(#194): refine documentation for agentic scaffolds

- Clarify conversational flow for new or not-yet-scoped work
- Improve instructions for handling unresolved questions
- Streamline guidance on implementing issues and design packages

Author: stiwicourage

src/resources/agentic-copilot/.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
 

src/resources/agentic-copilot/.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 issue/work item 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 issue/work item 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
 

src/resources/agentic-copilot/.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.

src/resources/agentic-copilot/.github/prompts/design-change.prompt.md

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

src/resources/agentic-copilot/.github/prompts/implement-issue.prompt.md

@@ -10,12 +10,10 @@ Implement the issue in the {{ProjectName}} 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 workflow files, when present and
-   `scripts/build/ci/*.ps1` files.
+4. If the issue is release-, workflow-, or coverage-related, also inspect the matching workflow files, when present 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 {{ProjectName}} repository using the repository-local
 11. Review `README.md`, `CONTRIBUTING.md`, `CHANGELOG.md`, `RELEASE_NOTE.md`, help docs, and project docs 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
 

src/resources/agentic-copilot/.github/prompts/prepare-release.prompt.md

@@ -4,23 +4,19 @@ Prepare release-related changes in {{ProjectName}} 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 release workflow files, when present.
+1. Read `CHANGELOG.md`, `RELEASE_NOTE.md`, `project.json`, `README.md`, `CONTRIBUTING.md`, `.github/pull_request_template.md`, and release workflow files, when present.
 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 {{ProjectName}} 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`).

src/resources/agentic-copilot/.github/prompts/review-change.prompt.md

@@ -9,8 +9,7 @@ Review a {{ProjectName}} 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