Align module setup guidance with repository standard

Document the baseline, required workflow credentials, supported site configuration, and exact caller contract consistently across setup and reference guides.

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

Author: MariusStorhaug

docs/content/get-started/index.md

@@ -11,26 +11,28 @@ Start new modules from the PSModule template repository:
 ## Quickstart
 
 1. [Create a new repository from the template](https://github.com/new?template_name=Template-PSModule&template_owner=PSModule&description=Add%20a%20description%20(required)&name=%3CModule%20name%3E).
-2. [Configure the repository](repository-setup.md) — GitHub Pages, `PSGALLERY_API_KEY`, and the caller workflow.
-3. Replace placeholder metadata and remove scaffold sample files.
+2. Complete the [module repository baseline](repository-setup.md#1-complete-the-module-repository-baseline): replace
+   template tokens, remove scaffolding, set `Type: Module`, and confirm required files.
+3. [Configure the repository](repository-setup.md) — GitHub Pages, workflow secrets, the caller workflow, settings, and
+   Zensical.
 4. Add your first public command and tests.
-5. Validate `.github/PSModule.yml` defaults for your module.
-6. [Open a draft pull request](your-first-release.md), then release from its resulting important default-branch push.
+5. [Open a draft pull request](your-first-release.md), then release from its resulting important default-branch push.
 
 If the module needs several interdependent commands before it is usable at all, see
 [Module bootstrap](module-bootstrap.md) instead of shipping them as one command per step.
 
 ## Expected outcomes
 
-- The repository follows the [expected structure](../guides/structuring-your-module.md).
+- The repository follows the [repository standard](../reference/repository-standard.md) and
+  [expected structure](../guides/structuring-your-module.md).
 - The module can be built and tested in CI.
 - The release strategy is ready when functionality is implemented.
 
 ## In this section
 
 | Page | Description |
 | --- | --- |
-| [Repository setup](repository-setup.md) | GitHub Pages, `PSGALLERY_API_KEY`, permissions, and the caller workflow. |
+| [Repository setup](repository-setup.md) | Repository baseline, GitHub Pages, workflow secrets, and the caller workflow. |
 | [Your first release](your-first-release.md) | The pull request flow, version labels, and the resulting default-branch release. |
 | [Module bootstrap](module-bootstrap.md) | Getting a brand-new module to its first release with an integration branch. |
 

docs/content/get-started/repository-setup.md

@@ -6,9 +6,23 @@ description: Configure GitHub Pages, `PSGALLERY_API_KEY`, permissions, and the c
 # Repository setup
 
 Do this once per module repository, after creating it from
-[Template-PSModule](https://github.com/PSModule/Template-PSModule).
+[Template-PSModule](https://github.com/PSModule/Template-PSModule). The template supplies the initial repository
+files and framework wiring; this guide verifies the standard baseline and configures its external services.
 
-## 1. Enable GitHub Pages
+## 1. Complete the module repository baseline
+
+Before configuring the pipeline:
+
+1. Replace every template token, including the README and `.github/zensical.toml`.
+2. Remove scaffold functions, tests, and examples that do not belong to the module.
+3. Set the repository description and its `Type` custom property to `Module`; retain `main` as the default branch.
+4. Confirm the required community, governance, agent, dependency-update, and workflow files are present.
+5. Confirm the README follows the module start-page requirements, including `Install-PSResource` installation guidance.
+6. Keep `.github/PSModule.yml` limited to settings that override the framework defaults.
+
+[Repository standard](../reference/repository-standard.md) defines the required files, metadata, and README shape.
+
+## 2. Enable GitHub Pages
 
 Enable GitHub Pages in the repository settings and set it to deploy from **GitHub Actions**.
 
@@ -18,18 +32,23 @@ This creates an environment called `github-pages` that GitHub deploys the docume
   <img src="../media/pagesEnvironment.png" alt="Remove the branch protection on main">
 </details>
 
-## 2. Create `PSGALLERY_API_KEY`
+## 3. Configure workflow secrets
+
+Create these repository or organization Actions secrets:
 
-1. [Create an API key on the PowerShell Gallery](https://www.powershellgallery.com/account/apikeys). Give it permission
-   to manage the module you are working on.
-2. Create a repository or organization secret called `PSGALLERY_API_KEY` and set the API key as its value.
+| Secret | Purpose |
+| --- | --- |
+| `PSGALLERY_API_KEY` | An [API key](https://www.powershellgallery.com/account/apikeys) authorized to manage the module on the PowerShell Gallery. |
+| `SHELLY_CLIENT_ID` | The GitHub App client ID that the caller maps to `GitHubAppClientId`. |
+| `SHELLY_PRIVATE_KEY` | The GitHub App private key that the caller maps to `GitHubAppPrivateKey`. |
 
-If you plan to create many modules, use a glob pattern for the API key permissions in the PowerShell Gallery and store
-`PSGALLERY_API_KEY` on the organization instead of on each repository.
+Use a glob pattern for PowerShell Gallery API-key permissions and store `PSGALLERY_API_KEY` at the organization level
+when several modules share it. For Dependabot pull requests, add all three secrets to the Dependabot secret store.
+[GitHub App authentication](../guides/github-app-authentication.md) defines the App permissions and token boundaries.
 
-## 3. Add the caller workflow
+## 4. Verify the caller workflow
 
-Create `.github/workflows/Process-PSModule.yml` in the module repository:
+The template supplies `.github/workflows/Process-PSModule.yml`. Replace the caller with this standard form:
 
 ```yaml
 name: Process-PSModule
@@ -96,9 +115,10 @@ cancels obsolete activity and uses the pull-request number for every action, inc
 literal queue value and does not permit cancellation with `queue: max`, so the two jobs use separate compatible
 policies. Keep both groups distinct from the reusable workflow's prefixed group.
 
-## 4. Add the settings file
+## 5. Configure the settings file
 
-Create `.github/PSModule.yml`. An empty file is valid — every setting has a default:
+The template supplies `.github/PSModule.yml`. Keep only the overrides the module needs; an empty file is valid when a
+hand-built repository needs no overrides:
 
 ```yaml
 Name: null
@@ -107,10 +127,10 @@ Name: null
 See [Settings](../reference/settings.md) for the full contract and
 [Configuring the pipeline](../guides/configuring-the-pipeline.md) for worked examples.
 
-## 5. Configure the documentation site
+## 6. Configure the documentation site
 
-Process-PSModule builds documentation with [Zensical](https://zensical.org/) from `.github/zensical.toml`. The template
-ships a working file; update the site name and repository links to match the module.
+The template builds documentation with [Zensical](https://zensical.org/) from `.github/zensical.toml`. Replace each
+template token with the module's name, owner, and repository URL.
 
 ## Next
 

docs/content/guides/calling-the-workflow.md

@@ -5,8 +5,9 @@ description: How to call the Process-PSModule reusable workflow — the caller w
 
 # Calling the workflow
 
-To use the workflow, create a new file in the `.github/workflows` directory of the module repository and add the following content.
-For documentation site generation, use `zensical.toml` as the active site contract.
+Template-PSModule supplies a starter `.github/workflows/Process-PSModule.yml`. Replace it with this standard
+template; repositories created without the template create the file with this content. The template's documentation
+contract uses `.github/zensical.toml`.
 
 For the exact inputs, secrets, and permissions the reusable workflow declares, see
 [Workflow inputs](../reference/workflow-inputs.md).
@@ -35,8 +36,6 @@ on:
       - labeled
       - unlabeled
 
-permissions: {}
-
 jobs:
   Process-PSModule-Production:
     if: ${{ github.event_name != 'pull_request' }}
@@ -230,28 +229,8 @@ settings file:
 ImportantFilePatterns: []
 ```
 
-You can also pass patterns via the workflow input:
-
-```yaml
-jobs:
-  Process:
-    uses: PSModule/Process-PSModule/.github/workflows/workflow.yml@v8
-    with:
-      ImportantFilePatterns: |
-        ^src/
-        ^README\.md$
-        ^examples/
-```
-
-To disable triggering via the workflow input, pass an explicit empty string:
-
-```yaml
-jobs:
-  process:
-    uses: PSModule/Process-PSModule/.github/workflows/workflow.yml@v8
-    with:
-      ImportantFilePatterns: ''
-```
+The standard caller does not add `with:` overrides. Configure
+`ImportantFilePatterns` in `.github/PSModule.yml`.
 
 Note that omitting the `ImportantFilePatterns` key entirely causes the workflow's default patterns (`^src/` and
 `^README\.md$`) to be used. The settings file takes priority over the workflow input, so set

docs/content/guides/github-app-authentication.md

@@ -10,10 +10,11 @@ installation tokens. These workflows do not use `github.token` as a fallback for
 
 ## Caller secret contract
 
-The reusable workflow declares two required secrets at its `workflow_call` boundary:
+The reusable workflow declares three required secrets at its `workflow_call` boundary:
 
 | Name | Purpose |
 | --- | --- |
+| `PSGALLERY_API_KEY` | The API key that publishes the module to the PowerShell Gallery. |
 | `GitHubAppClientId` | The GitHub App client ID passed to the token action. |
 | `GitHubAppPrivateKey` | The GitHub App private key passed to the token action. |
 
@@ -37,13 +38,13 @@ jobs:
       GitHubAppPrivateKey: ${{ secrets.SHELLY_PRIVATE_KEY }}
 ```
 
-The root reusable workflow forwards these two values to the Plan, Build-Module, and Publish-Module reusable jobs.
-Do not use `secrets: inherit` as a substitute for this mapping.
+The root reusable workflow forwards the GitHub App credentials to the Plan, Build-Module, and Publish-Module reusable
+jobs, and passes the Gallery API key to publication. Do not use `secrets: inherit` as a substitute for this mapping.
 
 Dependabot-triggered workflows cannot read regular Actions secrets. To run Process-PSModule on Dependabot pull
-requests, create `SHELLY_CLIENT_ID` and `SHELLY_PRIVATE_KEY` as Dependabot secrets in addition to Actions secrets.
-This is a deliberate trust boundary: review the App's installation scope and every dependency update carefully,
-because the workflow can mint a Shelly token before human review.
+requests, create `PSGALLERY_API_KEY`, `SHELLY_CLIENT_ID`, and `SHELLY_PRIVATE_KEY` as Dependabot secrets in addition
+to Actions secrets. This is a deliberate trust boundary: review the App's installation scope and every dependency
+update carefully, because the workflow can mint a Shelly token before human review.
 
 ## GitHub App installation permissions
 

docs/content/guides/structuring-your-module.md

@@ -27,7 +27,7 @@ The goal is a stable repository anatomy so both humans and automation know exact
 
 ```plaintext
 <ModuleName>/
-├── .github/                                   # Workflow config, doc/site templates, automation policy
+├── .github/                                   # Workflow config, site template, and automation policy
 │   ├── linters/                               # Rule sets applied by shared lint steps
 │   │   ├── .markdown-lint.yml                 # Markdown rules enforced via super-linter
 │   │   ├── .powershell-psscriptanalyzer.psd1  # Analyzer profile for test jobs
@@ -36,22 +36,29 @@ The goal is a stable repository anatomy so both humans and automation know exact
 │   │   └── Process-PSModule.yml               # Consumer hook into this workflow bundle
 │   ├── CODEOWNERS                             # Default reviewers enforced by Process-PSModule checks
 │   ├── dependabot.yml                         # Dependency update cadence handled by GitHub
-│   ├── zensical.toml                          # Site config consumed during site builds
 │   ├── PSModule.yml                           # Settings parsed to drive matrices
-│   └── release.yml                            # Release automation template invoked on publish
+│   ├── pull_request_template.md               # PR description structure
+│   ├── release.yml                            # Release automation template invoked on publish
+│   └── zensical.toml                          # Site config consumed during site builds
+├── AGENTS.md                                  # Agent entry point
+├── CLAUDE.md                                  # Claude Code route to AGENTS.md
+├── CODE_OF_CONDUCT.md                          # Community conduct expectations
+├── CONTRIBUTING.md                             # Repository contribution guidance
 ├── examples/                                  # Samples referenced in generated documentation
 │   └── General.ps1                            # Example script processed by Process-PSModule
 ├── icon/                                      # Icon assets linked from manifest and documentation
 │   └── icon.png                               # Default module icon (PNG format)
+├── LICENSE                                    # Reuse terms
+├── README.md                                  # Module landing page rendered on GitHub and docs
+├── SECURITY.md                                 # Security reporting policy
 ├── src/                                       # Module source, see "Module source code structure" below
 ├── tests/                                     # Pester suites; the Simple layout is shown
 │   ├── AfterAll.ps1 (optional)                # Cleanup script for ModuleLocal runs
 │   ├── BeforeAll.ps1 (optional)               # Setup script for ModuleLocal runs
 │   └── <ModuleName>.Tests.ps1                 # Simple: one root-level module suite
 ├── .gitattributes                             # Normalizes line endings across platforms
 ├── .gitignore                                 # Excludes build artifacts from source control
-├── LICENSE                                    # License text surfaced in manifest metadata
-└── README.md                                  # Repository overview rendered on GitHub and docs landing
+└── SUPPORT.md                                  # Support expectations
 ```
 
 The tree shows the [Simple PowerShell test profile](https://msx.no/docs/Coding-Standards/PowerShell/Testing/#simple), not an exclusive test-file shape. Standard keeps one root-level `tests/<Group>.Tests.ps1` file per public function group. Advanced uses recursively discovered subdirectories, and layouts may mix across directories. Process-PSModule defines the exact [per-directory precedence and sibling suppression](writing-module-tests.md#test-discovery).

docs/content/index.md

@@ -26,7 +26,7 @@ New to Process-PSModule? Work through these in order.
 | Page | Description |
 | --- | --- |
 | [Get started](get-started/index.md) | Create a module repository from the template and get the pipeline running. |
-| [Repository setup](get-started/repository-setup.md) | Configure GitHub Pages, `PSGALLERY_API_KEY`, permissions, and the caller workflow. |
+| [Repository setup](get-started/repository-setup.md) | Repository baseline, GitHub Pages, workflow secrets, and the caller workflow. |
 | [Your first release](get-started/your-first-release.md) | The pull request flow, version labels, and the resulting default-branch release. |
 
 ## Guides