fix: clean up whitespace and formatting in multiple files

- Removed unnecessary blank lines in ReadAwesomeHost.ps1
- Adjusted spacing in GetNovaResolvedProjectPackageSettings.ps1
- Standardized spacing in SKILL.md and other markdown files

Author: stiwicourage

.github/agents/architect.agent.md

@@ -7,25 +7,21 @@ description: Designs and scopes NovaModuleTools changes through a discussion-fir
 
 ## Purpose
 
-Design or reshape changes that cross public commands, private helper boundaries, workflows, documentation layers, or
-release automation.
+Design or reshape changes that cross public commands, private helper boundaries, workflows, documentation layers, or release automation.
 
 ## Responsibilities
 
-- Default new work to analysis first: clarify the problem, scope, risks, affected layers, validation needs, and
-  documentation impact before implementation starts.
+- Default new work to analysis first: clarify the problem, scope, risks, affected layers, validation needs, and documentation impact before implementation starts.
 - Keep new-work design conversations interactive instead of collapsing them into a complete solution in the first reply.
 - Identify the affected public surface, internal helper domains, tests, docs, and workflows.
 - Keep the change aligned with the repo's layering and ArchitectureGuardrails expectations.
 - Recommend the smallest structure that solves the problem cleanly.
 - Treat scope cuts, deferrals, and out-of-scope boundaries as proposals that require explicit user confirmation.
-- Before offering finalization when unresolved questions remain, summarize what is settled, what is still unresolved, and
-  present the explicit next-step choices.
+- Before offering finalization when unresolved questions remain, summarize what is settled, what is still unresolved, and present the explicit next-step choices.
 - Support two finalization modes when the discussion is sufficiently scoped:
     - design package plus GitHub issue draft
     - design package only
-- Once the discussion is sufficiently scoped, produce an issue-ready change design with acceptance criteria,
-  out-of-scope boundaries, and a GitHub issue draft.
+- Once the discussion is sufficiently scoped, produce an issue-ready change design with acceptance criteria, out-of-scope boundaries, and a GitHub issue draft.
 
 ## Inputs to inspect
 
@@ -54,10 +50,8 @@ release automation.
 - Preserve the public/private command model and CLI vs PowerShell distinction.
 - Avoid introducing new abstractions unless the current structure clearly duplicates or conflicts.
 - Do not edit repository files unless the user explicitly asks to move from design into implementation.
-- Do not finalize the full design package until the user says the discussion is done, or you explicitly ask whether you
-  should finalize it now.
-- Do not ask to finalize as if the change is fully issue-ready when unresolved questions still exist; surface those
-  unresolved items explicitly before asking how the user wants to proceed.
+- Do not finalize the full design package until the user says the discussion is done, or you explicitly ask whether you should finalize it now.
+- Do not ask to finalize as if the change is fully issue-ready when unresolved questions still exist; surface those unresolved items explicitly before asking how the user wants to proceed.
 - Do not finalize out-of-scope decisions unless the user has explicitly confirmed them.
 
 ## Definition of done
@@ -75,8 +69,6 @@ release automation.
 - Must not invent new build or test tools.
 - Must not bypass established adapters or shared helpers without a strong reason.
 - Must not create or edit repository files when the task is still in design mode.
-- Must not return a full implementation plan or finished issue draft in the first reply when the user is clearly asking
-  for a design discussion.
+- Must not return a full implementation plan or finished issue draft in the first reply when the user is clearly asking for a design discussion.
 - Must not leave the user guessing whether the final output is a handoff document, paste-ready issue text, or both.
-- Must not decide on its own that requested work is out of scope and then finalize the design without the user's
-  confirmation.
+- Must not decide on its own that requested work is out of scope and then finalize the design without the user's confirmation.

.github/agents/docs-site.agent.md

@@ -7,8 +7,7 @@ description: Keeps NovaModuleTools website documentation accurate and clearly se
 
 ## Purpose
 
-Keep the GitHub Pages documentation under `docs/*.html` accurate, user-focused, and clearly separated from PowerShell
-cmdlet help and contributor documentation.
+Keep the GitHub Pages documentation under `docs/*.html` accurate, user-focused, and clearly separated from PowerShell cmdlet help and contributor documentation.
 
 ## Responsibilities
 
@@ -37,8 +36,7 @@ cmdlet help and contributor documentation.
 
 - Treat `docs/*.html` as end-user website docs, not cmdlet help.
 - Keep CLI and cmdlet surfaces clearly separated.
-- Mention PowerShell-only commands in CLI-oriented docs only when there is no CLI equivalent for that scenario, such as
-  installing NovaModuleTools with `Install-Module`.
+- Mention PowerShell-only commands in CLI-oriented docs only when there is no CLI equivalent for that scenario, such as installing NovaModuleTools with `Install-Module`.
 
 ## Definition of done
 

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

@@ -14,8 +14,7 @@ Handle versioning, changelog shaping, release-flow documentation, and publish au
 - Verify how a change affects stable vs prerelease behavior.
 - Keep `CHANGELOG.md` accurate and release-ready.
 - Review workflow, docs, and versioning implications together.
-- Produce a release-ready summary that follows `.github/pull_request_template.md` when a release preparation summary is
-  requested.
+- Produce a release-ready summary that follows `.github/pull_request_template.md` when a release preparation summary is requested.
 
 ## Inputs to inspect
 
@@ -39,8 +38,7 @@ Handle versioning, changelog shaping, release-flow documentation, and publish au
 - 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.
+- 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

@@ -14,10 +14,8 @@ Review changes for correctness, maintainability, test coverage, workflow safety,
 - Start with the highest-risk workflow or public behavior surface.
 - Check for missing tests, doc drift, changelog gaps, and CI/release side effects.
 - 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.
+- 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,8 +43,7 @@ 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 when local CodeScene tooling is
-  available.
+- 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

@@ -4,8 +4,7 @@
 
 Use this file as the repository-wide Copilot instruction entry point for NovaModuleTools.
 
-NovaModuleTools is not a generic PowerShell repo. It has a strong split between public commands, private helpers,
-Pester-heavy testing, GitHub Actions automation, CodeScene coverage gates, and Keep a Changelog / SemVer release flow.
+NovaModuleTools is not a generic PowerShell repo. It has a strong split between public commands, private helpers, Pester-heavy testing, GitHub Actions automation, CodeScene coverage gates, and Keep a Changelog / SemVer release flow.
 
 ## Start here
 
@@ -17,22 +16,15 @@ Read these files before making non-trivial changes:
 4. The relevant file in `.github/instructions/`
 5. The relevant skill under `.github/skills/<skill-name>/SKILL.md`
 
-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.
+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.
+`.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
 
 - `src/public/` - public PowerShell command surface; one top-level function per file
-- `src/private/` - internal helpers grouped by domain (`build/`, `cli/`, `package/`, `quality/`, `release/`,
-  `scaffold/`, `shared/`, `update/`)
+- `src/private/` - internal helpers grouped by domain (`build/`, `cli/`, `package/`, `quality/`, `release/`, `scaffold/`, `shared/`, `update/`)
 - `tests/` - Pester tests and shared test-support scripts
 - `scripts/build/` - local analyzer and build helpers
 - `scripts/build/ci/` - CI coverage, CodeScene, and artifact helpers
@@ -58,11 +50,8 @@ handoff. Proposed scope cuts or out-of-scope boundaries must be confirmed by the
 
 - When you are asked to suggest or prepare a commit message, answer in English.
 - Use Conventional Commit format.
-- Extract the ticket number from `$GIT_BRANCH_NAME` and render it as `(#<number>)` immediately after the type when one
-  is
-  available.
-- If `$GIT_BRANCH_NAME` starts with `hotfix/` or `bug/`, use `fix` as the type even when the implementation looks more
-  like a feature. Use `fix!` if that branch change is also breaking.
+- Extract the ticket number from `$GIT_BRANCH_NAME` and render it as `(#<number>)` immediately after the type when one is available.
+- If `$GIT_BRANCH_NAME` starts with `hotfix/` or `bug/`, use `fix` as the type even when the implementation looks more like a feature. Use `fix!` if that branch change is also breaking.
 - Otherwise estimate the type from the actual change:
     - `feat` for feature work
     - `fix` for bug fixes
@@ -74,11 +63,8 @@ handoff. Proposed scope cuts or out-of-scope boundaries must be confirmed by the
 
 ## Markdown output guidance
 
-- When the output is intended to be copied as Markdown from the UI or written to a Markdown file, follow
-  the `markdown-authoring` skill (`.github/skills/markdown-authoring/SKILL.md`).
-- Apply that rule especially to release summaries, review summaries, contributor-facing Markdown docs, prompt output,
-  and
-  PR-template-shaped text.
+- When the output is intended to be copied as Markdown from the UI or written to a Markdown file, follow the `markdown-authoring` skill (`.github/skills/markdown-authoring/SKILL.md`).
+- Apply that rule especially to release summaries, review summaries, contributor-facing Markdown docs, prompt output, and PR-template-shaped text.
 
 ## Validation expectations
 
@@ -97,8 +83,7 @@ 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.
+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.
 

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

@@ -20,8 +20,7 @@ Use this file when changing `src/public/`, `src/private/`, or PowerShell build/r
 
 - Put internal helpers in the correct domain folder under `src/private/`.
 - Reuse existing adapters and shared helpers before adding new infrastructure calls.
-- Keep direct environment access, Git execution, upload requests, and self-update execution in their approved helper
-  locations. `tests/ArchitectureGuardrails.Tests.ps1` is authoritative.
+- Keep direct environment access, Git execution, upload requests, and self-update execution in their approved helper locations. `tests/ArchitectureGuardrails.Tests.ps1` is authoritative.
 - Prefer explicit workflow-context objects (`[pscustomobject]` / ordered hashtables) for multi-step flows.
 
 ## Error and behavior rules
@@ -38,9 +37,7 @@ Use this file when changing `src/public/`, `src/private/`, or PowerShell build/r
 - Use 4 spaces per indentation level.
 - Indent block contents one level inside `function`, `if`, `switch`, `foreach`, `for`, `while`, `try`, `catch`,
   `finally`, `class`, and method bodies.
-- When an expression wraps onto the next line, indent the continuation line one extra level instead of trying to align
-  it
-  visually to a previous token column.
+- When an expression wraps onto the next line, indent the continuation line one extra level instead of trying to align it visually to a previous token column.
 
 ### Spacing
 
@@ -56,8 +53,7 @@ Use this file when changing `src/public/`, `src/private/`, or PowerShell build/r
 
 ### Wrapping and braces
 
-- Use same-line opening braces for functions, control statements, `try` / `catch` / `finally`, `switch` labels, classes,
-  and methods.
+- Use same-line opening braces for functions, control statements, `try` / `catch` / `finally`, `switch` labels, classes, and methods.
 - Keep `elseif`, `else`, `catch`, and `finally` on the same line as the preceding closing brace.
 - Keep closing braces on their own line.
 - Prefer multi-line `param(...)`, hashtables, and long argument sets over overly long single lines.

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

@@ -6,8 +6,7 @@ applyTo: "CHANGELOG.md,RELEASE_NOTE.md,project.json,.github/workflows/Publish.ym
 
 ## Scope
 
-Use this file when changing versioning, changelog handling, package metadata, publish workflows, or GitHub release
-automation.
+Use this file when changing versioning, changelog handling, package metadata, publish workflows, or GitHub release automation.
 
 ## Versioning rules
 
@@ -17,8 +16,7 @@ automation.
 - 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.
+- 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/instructions/testing-policy.instructions.md

@@ -26,8 +26,7 @@ Use this file when changing production code, tests, coverage behavior, or CI tes
 
 - CI coverage is generated by `./scripts/build/ci/Invoke-NovaModuleToolsCI.ps1`.
 - The Cobertura artifact is reused by the CodeScene PR coverage gate and by the develop/manual CodeScene analysis flow.
-- If CodeScene flags coverage or duplication, fix the underlying test design instead of suppressing the warning
-  casually.
+- If CodeScene flags coverage or duplication, fix the underlying test design instead of suppressing the warning casually.
 
 ## Common pitfalls