Add module template reconciliation skill

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

Author: MariusStorhaug

.github/plugin/README.md

@@ -29,7 +29,10 @@ skill for migrating every Pester test set in a PSModule repository to Pester
 skill for upgrading Process-PSModule consumer repositories to framework v8.
 It also provides
 [`psmodule-zensical-migration`](./psmodule/skills/psmodule-zensical-migration/SKILL.md)
-for migrating legacy MkDocs sites to the Process-PSModule Zensical design.
+for migrating legacy MkDocs sites to the standard Zensical design, and
+[`psmodule-template-reconciliation`](./psmodule/skills/psmodule-template-reconciliation/SKILL.md)
+for comparing or reconciling module repositories with the current
+Template-PSModule baseline.
 Verify the installation with:
 
 ```console

.github/plugin/marketplace.json

@@ -6,13 +6,13 @@
   },
   "metadata": {
     "description": "Agent plugins for the PSModule repository process.",
-    "version": "1.0.0"
+    "version": "1.1.0"
   },
   "plugins": [
     {
       "name": "psmodule",
       "description": "PSModule process guidance and reusable skills for PowerShell module repositories.",
-      "version": "1.0.0",
+      "version": "1.1.0",
       "source": ".github/plugin/psmodule"
     }
   ]

.github/plugin/psmodule/plugin.json

@@ -2,7 +2,7 @@
   "$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
   "name": "psmodule",
   "description": "PSModule process guidance and reusable skills for PowerShell module repositories.",
-  "version": "1.0.0",
+  "version": "1.1.0",
   "author": {
     "name": "PSModule",
     "url": "https://github.com/PSModule"
@@ -14,6 +14,7 @@
     "powershell",
     "psmodule",
     "pester",
+    "repository-template",
     "testing",
     "github-actions"
   ],

.github/plugin/psmodule/skills/psmodule-template-reconciliation/SKILL.md

@@ -0,0 +1,169 @@
+---
+name: psmodule-template-reconciliation
+description: Compare or reconcile a PSModule repository with the current Template-PSModule baseline while preserving repository-owned code, tests, settings, and content. Use for one-repository audits and fleet-wide template alignment.
+---
+
+# Reconcile a PSModule repository with Template-PSModule
+
+Use this skill when checking or updating an established PowerShell module
+repository against the standard files in
+[`PSModule/Template-PSModule`](https://github.com/PSModule/Template-PSModule).
+Use the same procedure for one repository or as the repository-level operation
+inside a fleet campaign.
+
+## Authority and precedence
+
+Apply sources in this order:
+
+1. The [MSX Repository Standard](https://msx.no/docs/Ways-of-Working/Repository-Standard/)
+   owns enterprise policy.
+2. The [PSModule Repository Standard](https://psmodule.io/docs/reference/repository-standard/)
+   adds or overrides requirements for PowerShell module repositories.
+3. The default branch of `PSModule/Template-PSModule` owns the executable
+   implementation of those requirements.
+4. The target repository owns its module code, tests, documentation content,
+   settings, secrets, and justified additions.
+
+Resolve and record the template default-branch commit before comparing files.
+Use that one commit throughout the run. Do not embed a snapshot of template
+file contents in this skill.
+
+When a higher-precedence standard and the template disagree, do not propagate
+the discrepancy. Correct the template first, then reconcile consumers against
+the corrected template commit. When prose and template implementation merely
+express the same requirement differently, use the template as the byte-level
+source.
+
+## Modes
+
+- **Audit** reports drift without changing the target.
+- **Reconcile** applies confirmed template-owned changes to one target
+  repository.
+- **Maintain the template** changes `Template-PSModule` itself when the
+  executable baseline does not satisfy the governing standards.
+
+State the selected mode before editing. A fleet run invokes Audit or Reconcile
+once per repository; it does not combine many repositories into one branch or
+pull request.
+
+## Inventory
+
+Before comparing:
+
+1. Read the target repository's local guidance, README, workflow, settings,
+   documentation configuration, tests, and validation commands.
+2. Confirm that the target is a PowerShell module repository. Do not force the
+   module template onto framework, documentation, action, archive, or other
+   repository types.
+3. Resolve the current default branch and commit of `Template-PSModule`.
+4. Inventory every template path, including hidden files.
+5. Inventory every target path and any explicit local ownership or exception.
+6. Record the Process-PSModule caller version, Pester requirement, and
+   documentation configuration.
+
+## Classify before comparing
+
+Classify every template path. Never infer that every template file can safely
+overwrite an established repository.
+
+| Class | Treatment |
+| --- | --- |
+| Template-owned standard | Compare with the template and replace drift unless a documented target exception applies. |
+| Parameterized standard | Compare after applying only the substitutions declared by the template or framework. |
+| Configurable standard | Keep supported repository-specific values; compare the remaining structure and defaults. |
+| Creation scaffold | Use for new repositories. Do not overwrite established module source, tests, examples, or content. |
+| Repository-owned addition | Preserve it unless it violates a governing standard or breaks the framework contract. |
+
+Treat governance files, caller workflows, linter settings, dependency
+configuration, agent entry points, and documentation-site defaults as
+template-owned or parameterized unless the template or PSModule standard says
+otherwise. Treat `src/`, established `tests/`, `examples/`, documentation
+content, and module-specific assets as repository-owned after creation.
+
+Configuration is not automatically consumer-owned. For example,
+`.github/PSModule.yml` may contain valid module-specific overrides while its
+schema and unaffected defaults still come from the template. Compare fields,
+not only whole-file hashes, when the standard permits overrides.
+
+## Zensical contract
+
+For module repositories, `.github/zensical.toml` comes from the matching path
+in `Template-PSModule`.
+
+- Preserve the template's repository placeholders when the framework resolves
+  them during site staging.
+- Do not add a `nav` setting. Zensical generates navigation from the staged
+  folder structure, places index pages first, and sorts the remaining pages
+  alphabetically.
+- Keep the template's theme, palette, typography, icons, plugins, Markdown
+  extensions, and supported assets together as one baseline.
+- Do not copy path-specific settings from `MSXOrg/docs` or
+  `Process-PSModule/docs` directly into a generated module site. Their shared
+  behavior must first be represented in `Template-PSModule` in a form the
+  Process-PSModule site staging pipeline supports.
+- Preserve repository-specific documentation content. A deliberate visual or
+  functional exception must be documented in the target and reported as an
+  accepted difference.
+
+Use
+[`psmodule-zensical-migration`](../psmodule-zensical-migration/SKILL.md) when
+the target still uses MkDocs or requires a documentation layout migration.
+
+## Pester and workflow contracts
+
+Template comparison does not prove that an established test suite is compatible
+with the template's Pester version. If the target does not already meet the
+template's Pester baseline, invoke
+[`psmodule-pester-migration`](../psmodule-pester-migration/SKILL.md) and migrate
+every test set before declaring reconciliation complete.
+
+When the Process-PSModule caller requires a major-version migration, invoke
+[`psmodule-v8-upgrade`](../psmodule-v8-upgrade/SKILL.md). Preserve supported
+`TestData` and repository-owned automation instead of replacing them with
+template examples.
+
+## Reconciliation output
+
+Report each compared path with:
+
+| Field | Meaning |
+| --- | --- |
+| Path | Repository-relative path. |
+| Class | One of the comparison classes above. |
+| Status | Aligned, missing, drifted, extra, accepted difference, or blocked. |
+| Action | None, add, update, preserve, remove, or fix template first. |
+| Evidence | Template commit and governing standard or documented exception. |
+
+Do not count an extra repository-owned file as drift. Do not call a repository
+aligned when a required template-owned file is absent, a Pester migration is
+incomplete, or validation did not execute.
+
+## Fleet operation
+
+Follow the MSX Fleet Orchestration standard:
+
+1. Discover repositories from authoritative organization metadata, such as the
+   `Type: Module` custom property.
+2. Use one Task or Bug, branch, draft pull request, and review loop per
+   repository.
+3. Put the campaign slug in every delivery issue and pull request title.
+4. Adopt an existing matching pull request instead of opening a duplicate.
+5. Store campaign state on GitHub. Local JSON or dashboards are disposable
+   projections, not sources of truth.
+6. Record the template commit in every report and pull request so a later run
+   can distinguish new template changes from unfinished work.
+
+## Validation
+
+1. Repeat the comparison against the same recorded template commit.
+2. Confirm no repository-owned content or secrets changed unintentionally.
+3. Run the target's smallest repository-native checks for every changed
+   surface.
+4. Run Pester with the declared version when tests changed.
+5. Build the Zensical site when documentation settings or assets changed.
+6. Review the diff for unresolved placeholders, generated output, and unrelated
+   changes.
+
+Report blocked checks and their causes. A clean file comparison is not a
+substitute for repository tests, and a green build is not a substitute for
+checking template drift.