Add comprehensive documentation for Process-PSModule

- Introduced a new settings reference document detailing all available settings in `.github/PSModule.yml` with defaults.
- Created a workflow inputs reference outlining the inputs, secrets, and permissions for the Process-PSModule reusable workflow.
- Developed a design specification document explaining the architecture and workflow of Process-PSModule.
- Established a specification document that outlines the requirements for the PowerShell module pipeline, including functional and non-functional requirements.
- Added principles and practices documentation to guide versioning, branching, and development practices.
- Removed outdated quickstart and workflow overview documents, consolidating information into new structured guides.
- Updated navigation and references in the documentation to reflect the new structure and removed obsolete links.
- Revised links to external coding standards to point to the updated MSX documentation.

Author: MariusStorhaug

docs/content/Modules/Module-Types.md

@@ -1,7 +1,7 @@
 # Module types
 
 Most PSModule modules fall into one of a few archetypes. The general rules in
-[PowerShell module standard](Standards.md) and [PowerShell Standards](../PowerShell/Standard/index.md) always apply; this
+[PowerShell module standard](Standards.md) and [MSX PowerShell Standards](https://msxorg.github.io/docs/Coding-Standards/PowerShell/) always apply; this
 page adds the conventions that are specific to a module's type so that modules of the same kind feel
 the same to use.
 

docs/content/Modules/Process-PSModule/build-test-pack-publish.md

@@ -0,0 +1,37 @@
+---
+title: Get started
+description: Create a module repository from the PSModule template and get the Process-PSModule pipeline running.
+---
+
+# Get started
+
+Start new modules from the PSModule template repository:
+[Template-PSModule](https://github.com/PSModule/Template-PSModule).
+
+## 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, the PowerShell Gallery API key, and the caller workflow.
+3. Replace placeholder metadata and remove scaffold sample files.
+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) and run the full pipeline.
+
+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 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, the PowerShell Gallery API key, permissions, and the caller workflow. |
+| [Your first release](your-first-release.md) | The pull request flow, version labels, and what happens on merge. |
+| [Module bootstrap](module-bootstrap.md) | Getting a brand-new module to its first release with an integration branch. |
+
+For framework-level practices, refer to [MSX Ways of Working](https://msxorg.github.io/docs/Ways-of-Working/).

docs/content/Modules/Process-PSModule/design.md

@@ -1,10 +1,15 @@
-# Module Bootstrap
+---
+title: Module bootstrap
+description: How to get a brand-new module to its first release using a single integration branch for the load-bearing core.
+---
+
+# Module bootstrap
 
 A brand-new module usually has a small **load-bearing core**: the piece(s) every other function will depend on, without which nothing else in the module can work at all. A single feature PR cannot carry that much scope and still be small and focused, so bootstrap uses one integration branch instead.
 
 ## Identify the load-bearing core first
 
-What counts as "load-bearing" follows the module's archetype from [Module types](../Module-Types.md):
+What counts as "load-bearing" follows the module's archetype from [Module types](../../Module-Types.md):
 
 - **Data modules** — the conversion pivot: `ConvertFrom-<Format>` / `ConvertTo-<Format>` (and whatever parser/serializer they wrap). Every other function (`Import-`, `Export-`, `Format-`, `Merge-`, ...) is built on top of this pivot and is meaningless without it.
 - **Integration (API) modules** — a [`Context`](https://github.com/PSModule/Context)-backed credential/config store, the client setup that uses it, and at least one API function that consumes the context end-to-end. Every other API function needs the same context and client to do anything.
@@ -20,7 +25,7 @@ Scope the integration branch to exactly that core, not to everything planned for
 
 ## After the core lands
 
-Once the core has merged as `v1.0.0`, ordinary [SemVer](../Versioning.md) applies: a new function built on the stable core is a **minor** bump, a fix is a **patch** bump, and only a change to the core's own contract (signature, exported class shape, behavior) is a **major** bump. No special versioning exception is needed once the core is in place — the bootstrap phase exists only to get that core to a first release quickly.
+Once the core has merged as `v1.0.0`, ordinary [SemVer](../../Versioning.md) applies: a new function built on the stable core is a **minor** bump, a fix is a **patch** bump, and only a change to the core's own contract (signature, exported class shape, behavior) is a **major** bump. No special versioning exception is needed once the core is in place — the bootstrap phase exists only to get that core to a first release quickly.
 
 ```mermaid
 gitGraph