Reconcile contradictory contribution and PowerShell examples

[MariusStorhaug]

Contributors and agents use the MSX documentation as one canonical instruction set, but several pages on the live default branch currently disagree. Following one page can therefore violate another:

• PR-Format.md requires the related-issues block at the end, while Repository-Standard.md places issue links before user-facing change sections.
• Branching-and-Merging.md requires <type>/<issue>-<slug> branch names, while Git-Worktrees.md says the branch name matches a <issue>-<slug> folder.
• Issue-Format.md says implementation-plan tasks put tests last, while the testing standard defines test-first development.
• The framework-test skip example uses return, omits complete help and output metadata, and leaves a parameter untyped even though it demonstrates a PowerShell function.

Request

Make these pages internally consistent so a reader can follow the repository, workflow, testing, and PowerShell standards together without choosing between contradictory instructions.

Acceptance criteria

• The repository-standard PR description order matches the canonical PR format, including the final related-issues block
• Worktree folder naming is distinguished from the required branch naming convention
• Implementation-plan ordering does not imply that tests are implemented after behavior
• The framework-test skip example follows the PowerShell function standard except for the one rule it intentionally demonstrates skipping
• Existing links, generated indexes, linting, and the documentation build remain valid

---

Technical decisions

Canonical precedence: Specialized pages remain authoritative. PR-Format.md, Branching-and-Merging.md, Testing.md, and PowerShell/Functions.md define their respective rules; summary and example pages align to them.

Worktree naming: Keep the concise <issue>-<slug> folder example, but use the standard <type>/<issue>-<slug> branch name and state explicitly that the folder and branch do not need identical names.

Test planning: Organize implementation plans by dependency and place each behavior's tests with that behavior. Preserve test-first execution rather than using a blanket “tests last” rule.

Skip example: Keep multiple functions because the example intentionally skips FunctionCount; make every shown function otherwise compliant and state that only the named framework rule is exempted.

Validation: Run the documentation index check, link validator, clean Zensical build, and repository CI.

---

Implementation plan

Workflow consistency

• Align the PR description order in src/docs/Ways-of-Working/Repository-Standard.md
• Distinguish worktree folder names from branch names in src/docs/Ways-of-Working/Git-Worktrees.md
• Align the root AGENTS.md worktree setup instruction with the same folder and branch distinction
• Align implementation-plan task ordering with test-first development in src/docs/Ways-of-Working/Issue-Format.md

PowerShell example

• Correct the intentionally skipped framework-test example in src/docs/Frameworks/Process-PSModule/skipping-framework-tests.md
• Point the example's .LINK entries to the generated psmodule.io public function page and document the canonical URL pattern

Validation

• Verify generated documentation indexes
• Validate links and build the site cleanly

[MariusStorhaug]

Completed the documented implementation and validation plan. All four consistency corrections are pushed in the linked draft pull request, and the index, link, clean-build, and repository CI checks are green.

[MariusStorhaug]

Expanded the completed workflow-consistency checklist after Copilot identified the same stale worktree-equals-branch instruction in AGENTS.md. The root agent guidance now uses the canonical folder/branch distinction, and the review thread was answered and resolved.

[MariusStorhaug]

Updated the completed implementation plan after clarification that PSModule framework .LINK help entries must target the generated online command reference. The example and canonical PowerShell function guidance now use the psmodule.io/<Module>/Functions[/<Group>]/<Function> convention.