Need
Process-PSModule guidance duplicates parts of the module template, permits Zensical and repository-layout drift, and does not make the dedicated Pester 6 migration a required v8 upgrade step. There is also no reusable read-only audit for comparing established module repositories with the current Template-PSModule baseline.
Expected outcome
Module repositories have one executable source for standard files, migration skills consume that source, and documentation sites use the shared MSX presentation profile with native folder-derived navigation.
Acceptance criteria
- A read-only skill audits a module repository against a resolved
Template-PSModule commit without editing the template or consumer.
- Process-PSModule guidance states that every framework change includes a template-impact evaluation; template changes remain normal work in the template repository.
- The v8 upgrade skill requires the dedicated Pester 6.1.0 migration procedure to inventory and validate every test set.
- The v8 and Zensical migration skills use
Template-PSModule/.github/zensical.toml as the generated-module source instead of embedding a second template.
- Shared Zensical presentation follows
MSXOrg/docs where it differs from Process-PSModule, while repository-specific identity and content remain local.
- Standard Zensical configuration omits explicit
nav and [project.extra.consent].
- Repository-local community health files live under
.github/, with no root duplicates.
- Caller-workflow guidance links to the template-owned file instead of duplicating its contents.
- Process-PSModule's documentation site builds successfully with the updated configuration.
- A coordinated Template-PSModule pull request carries the generated-module configuration and community-file changes.
Scope
This task does not build the future fleet agent or managed-file distribution runtime. It establishes the audit operation and canonical template contract they can consume.
References
Need
Process-PSModule guidance duplicates parts of the module template, permits Zensical and repository-layout drift, and does not make the dedicated Pester 6 migration a required v8 upgrade step. There is also no reusable read-only audit for comparing established module repositories with the current
Template-PSModulebaseline.Expected outcome
Module repositories have one executable source for standard files, migration skills consume that source, and documentation sites use the shared MSX presentation profile with native folder-derived navigation.
Acceptance criteria
Template-PSModulecommit without editing the template or consumer.Template-PSModule/.github/zensical.tomlas the generated-module source instead of embedding a second template.MSXOrg/docswhere it differs from Process-PSModule, while repository-specific identity and content remain local.navand[project.extra.consent]..github/, with no root duplicates.Scope
This task does not build the future fleet agent or managed-file distribution runtime. It establishes the audit operation and canonical template contract they can consume.
References