feat(#194): update command help paths and instructions for NovaModuleTools

- Adjust command help source paths in documentation and tests to reflect NovaModuleTools
- Ensure consistency in PlatyPS help generation instructions

Author: stiwicourage

.github/agents/powershell-developer.agent.md

@@ -44,7 +44,7 @@ Implement PowerShell command and helper changes in the NovaModuleTools style.
 - Preserve existing command names, warning semantics, and output shape.
 - Keep new or heavily changed source functions inside the warning thresholds from `.github/instructions/code-quality-matrix.instructions.md` unless the scope explicitly justifies otherwise.
 - Prefer `./scripts/build/Invoke-ScriptAnalyzerCI.ps1` and `./run.ps1` for normal analyzer loops; use direct `Invoke-ScriptAnalyzer` only for focused local checks that reuse the repository-approved settings.
-- When help files change, keep `docs/<ProjectName>/en-US/*.md` valid for `Import-MarkdownCommandHelp`: use `New-MarkdownCommandHelp` for new files, `Update-MarkdownCommandHelp` after command-surface changes, and `Test-MarkdownCommandHelp` before handoff.
+- When help files change, keep `docs/NovaModuleTools/en-US/*.md` valid for `Import-MarkdownCommandHelp`: use `New-MarkdownCommandHelp` for new files, `Update-MarkdownCommandHelp` after command-surface changes, and `Test-MarkdownCommandHelp` before handoff.
 
 ## Definition of done
 

.github/agents/reviewer.agent.md

@@ -19,7 +19,7 @@ Review changes for correctness, maintainability, test coverage, workflow safety,
 - Check whether website docs preserve the CLI-vs-cmdlet separation when `docs/*.html` or help markdown changed.
 - Check that Nova projects still use generated `dist/` module files instead of hand-written source `.psm1` or module `.psd1` files.
 - Check changed PowerShell code, tests, and examples against `project.json` `Manifest.PowerShellHostVersion`; flag PowerShell 7.x-only constructs in projects that target `5.1` unless the change explicitly adds guarded compatibility handling.
-- Check that public commands/classes have matching valid PlatyPS-compatible help and that new source files have source-mirrored tests. Flag help files under `docs/<ProjectName>/en-US/` that look like plain Markdown, break the required PlatyPS section order, or would fail `Test-MarkdownCommandHelp` / `Import-MarkdownCommandHelp`.
+- Check that public commands/classes have matching valid PlatyPS-compatible help and that new source files have source-mirrored tests. Flag help files under `docs/NovaModuleTools/en-US/` that look like plain Markdown, break the required PlatyPS section order, or would fail `Test-MarkdownCommandHelp` / `Import-MarkdownCommandHelp`.
 - Check analyzer changes and PowerShell validation flow against `.github/instructions/psscriptanalyzer.instructions.md`. Flag direct `Invoke-ScriptAnalyzer` usage that bypasses repository-approved settings or wrapper semantics without a clear reason.
 - Review changed `src/**/*.ps1` and `tests/**/*.ps1` against `.github/instructions/code-quality-matrix.instructions.md`; flag new or heavily changed code that exceeds the warning thresholds without a clear, explicit reason.
 - Flag public files that do not keep exactly one top-level function, and flag private files that group multiple externally called functions instead of limiting extra functions to same-file support helpers. Also flag file/function name mismatches for public commands or externally called private helpers.

.github/copilot-instructions.md

@@ -16,7 +16,7 @@ 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`
 6. `.github/instructions/code-quality-matrix.instructions.md` when shaping or reviewing `src/**/*.ps1` or `tests/**/*.ps1`
-7. `.github/instructions/platyps-help.instructions.md` when creating or updating `docs/<ProjectName>/en-US/*.md`
+7. `.github/instructions/platyps-help.instructions.md` when creating or updating `docs/NovaModuleTools/en-US/*.md`
 8. `.github/instructions/psscriptanalyzer.instructions.md` when changing PowerShell code, test helpers, or analyzer wrappers
 
 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.
@@ -43,22 +43,22 @@ For new or not-yet-scoped work, start with `.github/agents/architect.agent.md` a
 - Treat `project.json` as the source of truth for project metadata, build output, package settings, and release settings.
 - Treat `project.json` `Manifest.PowerShellHostVersion` as the compatibility target for PowerShell code, tests, and examples. If a project targets `5.1`, do not introduce PowerShell 7.x-only syntax, cmdlets, parameters, or APIs unless the work explicitly adds guarded compatibility handling.
 - Use Nova commands and repository wrappers for build, test, package, and release workflows; do not replace them with ad hoc PowerShell module build scripts.
-- Do not create or maintain hand-written module `.psm1` or module `.psd1` files in source; Nova generates the built module root and manifest under `dist/<ProjectName>/` from `project.json` and `src/**/*.ps1`.
+- Do not create or maintain hand-written module `.psm1` or module `.psd1` files in source; Nova generates the built module root and manifest under `dist/NovaModuleTools/` from `project.json` and `src/**/*.ps1`.
 - Do not exclude or suppress PSScriptAnalyzer rules in repository analyzer helpers; fix the code that violates analyzer rules instead.
 - Use `.github/instructions/psscriptanalyzer.instructions.md` as the ScriptAnalyzer workflow source of truth. Prefer `./scripts/build/Invoke-ScriptAnalyzerCI.ps1` and `./run.ps1`, and only use direct `Invoke-ScriptAnalyzer` for focused local checks or deliberate analyzer-tooling changes.
 - Keep `run.ps1` as the local quality loop: run ScriptAnalyzer first, then `Invoke-NovaBuild`, then `Test-NovaBuild`.
 - If `run.ps1` or `./scripts/build/Invoke-ScriptAnalyzerCI.ps1` reports ScriptAnalyzer findings, fix them before review, handoff, or commit. Do not treat a failing local quality loop as an acceptable stopping point.
 - Keep file/function ownership explicit: `src/public/` files should own exactly one top-level function each, and `src/private/` files should expose at most one externally called function per file. Additional private functions may stay only as support helpers used from the same file, and the file name should match the function that owns the file.
 - Use `.github/instructions/code-quality-matrix.instructions.md` as the best-effort quality matrix for `src/**/*.ps1` and `tests/**/*.ps1`; generated projects should follow that guidance through Agentic Copilot files, not by depending on a required `.codescene/code-health-rules.json`.
-- Generate valid PlatyPS help under `docs/<ProjectName>/en-US/` whenever command help changes. Use the Microsoft.PowerShell.PlatyPS workflow (`New-MarkdownCommandHelp`, `Update-MarkdownCommandHelp`, `Test-MarkdownCommandHelp`) instead of hand-authoring command-help structure, and do not write plain Markdown that `Import-MarkdownCommandHelp` cannot parse.
+- Generate valid PlatyPS help under `docs/NovaModuleTools/en-US/` whenever command help changes. Use the Microsoft.PowerShell.PlatyPS workflow (`New-MarkdownCommandHelp`, `Update-MarkdownCommandHelp`, `Test-MarkdownCommandHelp`) instead of hand-authoring command-help structure, and do not write plain Markdown that `Import-MarkdownCommandHelp` cannot parse.
 - Review `README.md`, `CONTRIBUTING.md`, `CHANGELOG.md`, and `RELEASE_NOTE.md` after every meaningful change.
 - Update tests when behavior changes.
 - Prefer existing helpers and support files over ad hoc duplication.
 - Treat Code Health as authoritative for maintainability in this repository.
 - Target Code Health `10.0` for AI-touched files; `9.x` is not the goal state.
 - Prefer small, incremental refactors over large rewrites when fixing maintainability issues.
 - Keep `docs/*.html`, `docs/NovaModuleTools/en-US/*.md`, and contributor docs clearly separated by audience and syntax.
-- Add or update PlatyPS-compatible command help under `docs/<ProjectName>/en-US/` when public commands or public classes change.
+- Add or update PlatyPS-compatible command help under `docs/NovaModuleTools/en-US/` when public commands or public classes change.
 - For every new or changed `src/**/*.ps1` file, add or update one focused source-mirrored Pester file: use `tests/public/<Name>.Tests.ps1` for `src/public/<Name>.ps1`, `tests/private/<domain>/<Name>.Tests.ps1` for `src/private/<domain>/<Name>.ps1`, and `tests/classes/<Name>.Tests.ps1` for `src/classes/<Name>.ps1`.
 - Use shared helpers under `tests/TestHelpers/` or `tests/*TestSupport.ps1` for repeated setup; do not hide unrelated source-file coverage in broad catch-all test files unless the behavior is genuinely cross-cutting.
 

.github/instructions/platyps-help.instructions.md

@@ -20,29 +20,29 @@ Use this file when creating or updating command help under `docs/NovaModuleTools
 
 ```powershell
 $newMarkdownHelp = @{
-    CommandInfo  = Get-Command -Module '<ProjectName>'
+    CommandInfo  = Get-Command -Module 'NovaModuleTools'
     OutputFolder = './docs'
     WithModulePage = $true
     Force = $true
 }
 New-MarkdownCommandHelp @newMarkdownHelp
 ```
 
-3. Keep the resulting command-help files under `docs/<ProjectName>/en-US/` before handoff. If you generate files in a staging folder first, move the command-help markdown files into the repository's locale folder before you finish.
+3. Keep the resulting command-help files under `docs/NovaModuleTools/en-US/` before handoff. If you generate files in a staging folder first, move the command-help markdown files into the repository's locale folder before you finish.
 4. For existing command help, refresh syntax and parameter metadata with `Update-MarkdownCommandHelp` instead of editing the generated YAML structure by hand.
 
 ```powershell
-Measure-PlatyPSMarkdown -Path ./docs/<ProjectName>/en-US/*.md |
+Measure-PlatyPSMarkdown -Path ./docs/NovaModuleTools/en-US/*.md |
         Where-Object FileType -match 'CommandHelp' |
         Update-MarkdownCommandHelp -Path {$_.FilePath}
 ```
 
 5. Validate the final help with `Test-MarkdownCommandHelp -DetailView`, and inspect `Import-MarkdownCommandHelp` diagnostics when the structure or build result is unclear.
 
 ```powershell
-Test-MarkdownCommandHelp -Path ./docs/<ProjectName>/en-US/*.md -DetailView
+Test-MarkdownCommandHelp -Path ./docs/NovaModuleTools/en-US/*.md -DetailView
 
-Import-MarkdownCommandHelp -Path ./docs/<ProjectName>/en-US/<CommandName>.md |
+Import-MarkdownCommandHelp -Path ./docs/NovaModuleTools/en-US/<CommandName>.md |
         Select-Object -ExpandProperty Diagnostics
 ```
 

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

@@ -15,7 +15,7 @@ Use this file when changing `src/public/`, `src/private/`, or PowerShell build/r
 - Match the file name to that top-level public function name.
 - Public mutating commands should support PowerShell `ShouldProcess` semantics.
 - Preserve existing naming and command model conventions such as `Invoke-Nova*`, `Get-Nova*`, `Update-Nova*`, and the `nova` CLI routing model.
-- Do not create or maintain hand-written module `.psm1` or module `.psd1` files in source. Nova generates the built module root and manifest under `dist/<ProjectName>/` from `project.json` and `src/**/*.ps1`.
+- Do not create or maintain hand-written module `.psm1` or module `.psd1` files in source. Nova generates the built module root and manifest under `dist/NovaModuleTools/` from `project.json` and `src/**/*.ps1`.
 
 ## Internal structure rules
 

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

@@ -24,7 +24,7 @@ Implement the issue in the NovaModuleTools repository using the repository-local
 12. Keep file/function ownership explicit: one externally called function per file, with private-file extras limited to same-file support helpers, and keep the file name aligned to the entry function.
 13. Before handoff, review every changed or generated text file and normalize it to exactly one trailing newline with no extra blank lines at the bottom.
 14. Add or update the matching source-mirrored Pester file for every changed `src/**/*.ps1` file; if the behavior is genuinely cross-cutting, document which integration/guardrail test owns it and why a mirrored unit test is not practical.
-15. Add or update valid PlatyPS-compatible help under `docs/<ProjectName>/en-US/` when public commands or public classes change. Use `New-MarkdownCommandHelp` for new help, `Update-MarkdownCommandHelp` after command-surface changes, and `Test-MarkdownCommandHelp` before handoff; do not replace command help with plain Markdown prose.
+15. Add or update valid PlatyPS-compatible help under `docs/NovaModuleTools/en-US/` when public commands or public classes change. Use `New-MarkdownCommandHelp` for new help, `Update-MarkdownCommandHelp` after command-surface changes, and `Test-MarkdownCommandHelp` before handoff; do not replace command help with plain Markdown prose.
 16. Review `README.md`, `CONTRIBUTING.md`, `CHANGELOG.md`, `RELEASE_NOTE.md`, help docs, and `docs/*.html` as applicable.
 17. If a commit message is requested, derive it from `$GIT_BRANCH_NAME` and the implemented change using the repository's Conventional Commit rules.
 18. Run the relevant validation, then summarize what changed, why, and how it was verified.

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

@@ -8,7 +8,7 @@ Review a NovaModuleTools change set with emphasis on correctness, maintainabilit
 2. Compare the changed files against the relevant repository instructions and skills.
 3. Check changed `src/**/*.ps1` and `tests/**/*.ps1` against `.github/instructions/code-quality-matrix.instructions.md`.
 4. Check changed PowerShell validation flow against `.github/instructions/psscriptanalyzer.instructions.md`; flag direct analyzer usage that bypasses the repository wrapper or repo-approved settings without a clear reason.
-5. Check changed `docs/<ProjectName>/en-US/*.md` against `.github/instructions/platyps-help.instructions.md` when command help was added or updated; flag files that do not follow the `New-MarkdownCommandHelp` / `Update-MarkdownCommandHelp` / `Test-MarkdownCommandHelp` workflow or the required PlatyPS section structure.
+5. Check changed `docs/NovaModuleTools/en-US/*.md` against `.github/instructions/platyps-help.instructions.md` when command help was added or updated; flag files that do not follow the `New-MarkdownCommandHelp` / `Update-MarkdownCommandHelp` / `Test-MarkdownCommandHelp` workflow or the required PlatyPS section structure.
 6. Check whether tests, docs, and changelog updates match the change.
 7. Call out the smallest set of meaningful issues first.
 8. Note any missing validation or follow-up work.

.github/skills/powershell-module-development/SKILL.md

@@ -27,7 +27,7 @@ Use this skill when changing public commands, private helpers, CLI routing suppo
 - Put implementation detail in the correct private domain folder.
 - Treat `project.json` as the source of truth for Nova build, package, manifest, and release metadata.
 - Read `project.json` `Manifest.PowerShellHostVersion` before changing PowerShell code, tests, or examples, and keep new work compatible with that target. A `5.1` project must not receive PowerShell 7.x-only syntax, cmdlets, parameters, or APIs unless the change explicitly adds guarded compatibility handling.
-- Do not create or maintain hand-written module `.psm1` or module `.psd1` files in source; Nova generates those files under `dist/<ProjectName>/`.
+- Do not create or maintain hand-written module `.psm1` or module `.psd1` files in source; Nova generates those files under `dist/NovaModuleTools/`.
 - Preserve native PowerShell semantics and Nova naming patterns.
 - Keep one externally called function per file and match the file name to that function. In `src/private/`, additional functions may stay only as same-file support helpers called by that file's entry function.
 - Use `.github/instructions/code-quality-matrix.instructions.md` as the best-effort source-code matrix. Keep new or heavily changed source functions at or below the warning thresholds for lines of code (`16`), cyclomatic complexity (`6`), complex conditional branches (`6`), max arguments (`4`), and nesting depth (`6`) unless the change explicitly justifies more.
@@ -38,7 +38,7 @@ Use this skill when changing public commands, private helpers, CLI routing suppo
 - Keep `run.ps1`-style local checks ordered as ScriptAnalyzer first, then `Invoke-NovaBuild`, then `Test-NovaBuild`.
 - If `run.ps1` or `Invoke-ScriptAnalyzerCI.ps1` reports ScriptAnalyzer findings, fix them before handoff instead of just reporting the failure.
 - Before handoff, review every changed or generated text file and normalize it to exactly one trailing newline with no extra blank lines at the end.
-- Add or update valid PlatyPS-compatible help under `docs/<ProjectName>/en-US/` when public commands or public classes change. Use `New-MarkdownCommandHelp` for new help, `Update-MarkdownCommandHelp` to refresh existing help metadata, and `Test-MarkdownCommandHelp` to validate structure before handoff instead of writing plain Markdown from scratch.
+- Add or update valid PlatyPS-compatible help under `docs/NovaModuleTools/en-US/` when public commands or public classes change. Use `New-MarkdownCommandHelp` for new help, `Update-MarkdownCommandHelp` to refresh existing help metadata, and `Test-MarkdownCommandHelp` to validate structure before handoff instead of writing plain Markdown from scratch.
 - Add or update the source-mirrored Pester test file for every changed `src/**/*.ps1` file.
 
 ## Common pitfalls
@@ -50,7 +50,7 @@ Use this skill when changing public commands, private helpers, CLI routing suppo
 - Creating a root module `.psm1` or module manifest `.psd1` by hand instead of letting Nova generate them from `project.json`
 - Grouping two externally called private helpers in one file instead of splitting them into separate same-named files
 - Ignoring the source-code matrix and letting new or heavily changed functions grow far beyond the warning thresholds without justification
-- Writing plain Markdown under `docs/<ProjectName>/en-US/` that lacks YAML metadata or the PlatyPS structure expected by `Import-MarkdownCommandHelp`
+- Writing plain Markdown under `docs/NovaModuleTools/en-US/` that lacks YAML metadata or the PlatyPS structure expected by `Import-MarkdownCommandHelp`
 - Editing PlatyPS YAML and section structure by hand when `New-MarkdownCommandHelp` or `Update-MarkdownCommandHelp` should have regenerated it
 - Bypassing the repository analyzer wrapper/settings with ad hoc `Invoke-ScriptAnalyzer`, `-EnableExit`, or broad rule-exclusion changes
 - Ignoring the project's `Manifest.PowerShellHostVersion` target and introducing PowerShell 7.x-only features into a `5.1` project

scripts/build/Sync-AgenticCopilotScaffold.psd1

@@ -110,10 +110,6 @@
             Old = '- `.github/actions/` - reusable workflow actions used by release and coverage flows'
             New = '- `.github/actions/` - reusable workflow actions, when present'
         }
-        @{
-            Old = '- `docs/{{ProjectName}}/en-US/` - command help source'
-            New = '- `docs/<ProjectName>/en-US/` - command help source, when present'
-        }
         @{
             Old = '- `docs/NovaModuleTools/en-US/` - command help source'
             New = '- `docs/{{ProjectName}}/en-US/` - command help source'

src/resources/agentic-copilot/.github/agents/powershell-developer.agent.md

@@ -41,7 +41,7 @@ Implement PowerShell command and helper changes in the {{ProjectName}} style.
 - Preserve existing command names, warning semantics, and output shape.
 - Keep new or heavily changed source functions inside the warning thresholds from `.github/instructions/code-quality-matrix.instructions.md` unless the scope explicitly justifies otherwise.
 - Prefer `./scripts/build/Invoke-ScriptAnalyzerCI.ps1` and `./run.ps1` for normal analyzer loops; use direct `Invoke-ScriptAnalyzer` only for focused local checks that reuse the repository-approved settings.
-- When help files change, keep `docs/<ProjectName>/en-US/*.md` valid for `Import-MarkdownCommandHelp`: use `New-MarkdownCommandHelp` for new files, `Update-MarkdownCommandHelp` after command-surface changes, and `Test-MarkdownCommandHelp` before handoff.
+- When help files change, keep `docs/{{ProjectName}}/en-US/*.md` valid for `Import-MarkdownCommandHelp`: use `New-MarkdownCommandHelp` for new files, `Update-MarkdownCommandHelp` after command-surface changes, and `Test-MarkdownCommandHelp` before handoff.
 
 ## Definition of done