Expand module standard: Usage section, agent files, module types, PS 7.6+

- Rename README showcase heading Capabilities -> Usage (Examples allowed); disallow Capabilities and add to README validation.
- Each repo stands on its own: carries own governance files, no reliance on org .github fallback; README has no Contributing section (repo ships self-contained CONTRIBUTING.md).
- Add agent onboarding files (AGENTS.md, CLAUDE.md, .github/copilot-instructions.md) to required files + Distributor mandatory sets, pointing to PSModule/docs and MSXOrg/docs.
- Placeholder guard: a module exporting any real command is not a placeholder.
- Modern PowerShell only: minimum 7.6, track current + LTS; drop 5.1 accommodation.
- New Module-Types.md (integration/API + data modules) + Naming.md rules (REST->verb, ConvertTo/From + Format/Import/Export); Hashtable is the data-module reference; Context for user + module settings.

Author: MariusStorhaug

src/docs/PowerShell/Modules/Module-Types.md

@@ -0,0 +1,95 @@
+# Module types
+
+Most PSModule modules fall into one of a few archetypes. The general rules in
+[PowerShell module standard](Standards.md) and [Naming](../Standard/Naming.md) 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.
+
+Two archetypes have enough shared shape to standardize:
+
+- **Integration (API) modules** wrap an external service's REST or GraphQL API.
+- **Data modules** convert or manage a data format or in-memory structure.
+
+A module can be both (for example, an integration module that also exposes conversion helpers).
+Apply each relevant section.
+
+## Integration (API) modules
+
+Integration modules are the PowerShell face of an external service. `GitHub`, and the
+service-client modules such as `Anthropic`, `OpenAI`, `Bluesky`, and `Domeneshop`, are integration
+modules.
+
+### Command naming maps to the resource, not the HTTP method
+
+Name commands after the resource and the intent, using approved verbs. Never name a command after
+the HTTP method or the endpoint path. Map REST methods to verbs:
+
+| REST method | PowerShell verb | Example |
+| ----------- | --------------- | ------- |
+| `GET` | `Get-` | `Get-GitHubRepository` |
+| `POST` (create) | `New-` / `Add-` | `New-GitHubRepository` |
+| `PUT` / `PATCH` (update) | `Set-` / `Update-` | `Set-GitHubRepository` |
+| `DELETE` | `Remove-` | `Remove-GitHubRepository` |
+| Non-CRUD action | Approved verb for the intent | `Invoke-`, `Start-`, `Stop-`, `Enable-`, … |
+
+Prefix the noun with the service's term of art (`GitHubRepository`, not `Repository`). See
+[integration command naming](../Standard/Naming.md#integration-commands-and-rest-methods).
+
+### Transport stays private
+
+Public functions accept resolved inputs and typed objects; private helpers own the concrete
+`Invoke-RestMethod` / GraphQL / HTTP calls. This is the Dependency Inversion rule from
+[Standards](Standards.md#solid-applied) applied to the network boundary.
+
+### Use Context for user and module settings
+
+Integration modules persist state with the [`Context`](https://github.com/PSModule/Context) module
+rather than inventing bespoke storage. Two kinds of state are both standard:
+
+- **User settings and secrets** — accounts, tokens, sessions, and per-user configuration. Store these
+  in a per-user context. `Context` encrypts secrets at rest (via `Sodium`), so a user can resume work
+  without reconfiguring or logging in again when the service supports session refresh.
+- **Module settings** — module-wide defaults, endpoints, and feature flags that are not tied to a
+  single user. Store these in a module-scoped context.
+
+Persisting both through `Context` gives every integration module the same, discoverable settings
+model, and keeps secrets out of source, logs, and plain files.
+
+## Data modules
+
+Data modules convert between representations or manage an in-memory structure. `Hashtable` is the
+reference shape; `Base64`, `Json`, `Lua`, `Hcl`, `Sodium`, and `Uri` follow the same pattern.
+
+### The neutral object is the pivot
+
+Every conversion goes through the neutral PowerShell object model
+(`[PSCustomObject]` / `[hashtable]` / `[PSObject]`). `ConvertFrom-<Format>` parses a
+format-specific representation *into* an object; `ConvertTo-<Format>` renders an object *into* the
+format. Converting through the object as a common pivot means any format interoperates with any
+other, instead of writing a direct converter for every pair.
+
+Always ship **both** directions so data round-trips.
+
+### Verb vocabulary
+
+| Verb pattern | Purpose |
+| ------------ | ------- |
+| `ConvertFrom-<Format>` | Format-specific text/representation → `[PSCustomObject]` / `[hashtable]` |
+| `ConvertTo-<Format>` | Object → format-specific text/representation |
+| `Import-<Noun>` | Read from a file or store into objects |
+| `Export-<Noun>` | Write objects to a file or store |
+| `Format-<Noun>` | Produce a normalized or pretty rendering |
+| `Merge-<Noun>` | Combine two structures |
+| `Compare-<Noun>` | Diff two structures |
+| `Test-<Noun>` | Validate a value or structure |
+| `Remove-<Noun>Entry` | Remove elements by criteria |
+
+The `Hashtable` module demonstrates the full set: `ConvertFrom-Hashtable`, `ConvertTo-Hashtable`,
+`Import-Hashtable`, `Export-Hashtable`, `Format-Hashtable`, `Merge-Hashtable`, and
+`Remove-HashtableEntry`. See [data conversion and I/O verbs](../Standard/Naming.md#data-conversion-and-io-verbs).
+
+## Where this connects
+
+- [Naming](../Standard/Naming.md) — the concrete verb rules for both types.
+- [PowerShell module standard](Standards.md) — layout, private functions, and the mandatory context parameter.
+- [Repository Defaults](Repository-Defaults.md) — repository files, README shape, and agent onboarding.

src/docs/PowerShell/Modules/Repository-Defaults.md

@@ -2,7 +2,7 @@
 
 This page defines the default repository contract for PowerShell module repositories in the PSModule organization. It describes what a newly created or maintained module repository should look like before module-specific code, tests, documentation, and managed repository files are considered.
 
-The implementation standard still lives in [PowerShell module standard](Standards.md). This page covers repository defaults: files, metadata, README shape, release integration, placeholder handling, shared community files, and managed-file distribution.
+The implementation standard still lives in [PowerShell module standard](Standards.md). Type-specific conventions for integration (API) and data modules live in [Module types](Module-Types.md). This page covers repository defaults: files, metadata, README shape, release integration, placeholder handling, shared community files, agent onboarding files, and managed-file distribution.
 
 ## Scope
 
@@ -62,10 +62,13 @@ Module repositories use the PSModule framework layout:
 | ---- | --------------- |
 | `README.md` | Concise start page for the module. |
 | `LICENSE` | Repository license. PSModule module repositories default to MIT unless a different license is explicitly decided. |
-| `CONTRIBUTING.md` | Contribution workflow or a repository-level pointer to the organization contribution guide. |
+| `CONTRIBUTING.md` | Self-contained contribution workflow for this repository. Does not rely on an organization-level fallback. |
 | `SECURITY.md` | Security support policy and private vulnerability reporting instructions. |
 | `SUPPORT.md` | Support expectations and where users ask for help. |
 | `CODE_OF_CONDUCT.md` | Community conduct expectations. |
+| `AGENTS.md` | Agent onboarding entry point. Points agents to the PSModule and MSX documentation for the why, how, and what. |
+| `CLAUDE.md` | Claude Code entry point. Imports `AGENTS.md` so Claude reads the same instructions. |
+| `.github/copilot-instructions.md` | VS Code and GitHub Copilot repository instructions. Points to the same documentation. |
 | `.github/PSModule.yml` | Module workflow configuration overrides. |
 | `.github/workflows/workflow.yml` | Reusable Process-PSModule workflow entry point. |
 | `.github/dependabot.yml` | Dependency and supply-chain update configuration. |
@@ -102,10 +105,13 @@ Required baseline files for module repositories:
 | ---- | ------------------ |
 | `README.md` | Repository landing page and evergreen context for humans and agents. |
 | `LICENSE` | Clear legal terms for reuse, packaging, and redistribution. |
-| `CONTRIBUTING.md` | Shared contribution workflow and expectations. |
+| `CONTRIBUTING.md` | Self-contained contribution workflow and expectations for this repository. |
 | `SECURITY.md` | Private vulnerability reporting and latest-version support policy. |
 | `SUPPORT.md` | Support channel and issue-routing expectations. |
 | `CODE_OF_CONDUCT.md` | Community participation rules. |
+| `AGENTS.md` | Cross-tool agent instructions pointing to the PSModule and MSX documentation. |
+| `CLAUDE.md` | Claude Code entry point that imports `AGENTS.md`. |
+| `.github/copilot-instructions.md` | VS Code and GitHub Copilot repository instructions pointing to the documentation. |
 | `.github/dependabot.yml` | Supply-chain maintenance for GitHub Actions and PowerShell dependencies. |
 | `.github/CODEOWNERS` | Review routing for source, docs, and GitHub workflow files. |
 | `.github/pull_request_template.md` | Consistent PR Manager-style PR descriptions and change classification. |
@@ -118,6 +124,18 @@ Required baseline files for module repositories:
 
 Repositories can add local files, but they should not remove these baseline files unless the repository is explicitly outside the module standard.
 
+Each repository must stand on its own. It carries its own copy of every file above and does not depend on the organization `.github` fallback: that fallback is only surfaced in GitHub's web UI, and agents, linters, and local tooling do not read it.
+
+## Agent onboarding files
+
+Every repository must be usable by an agent that has never seen it before, without special configuration. Each repository carries its own agent entry points that *point to* the authoritative documentation instead of restating it:
+
+- `AGENTS.md` — the cross-tool entry point, read by the GitHub Copilot coding agent, VS Code, and other AGENTS.md-aware tools. It names what the repository is in a line or two and points to the PSModule documentation (`https://psmodule.io`, source in [`PSModule/docs`](https://github.com/PSModule/docs)) for the module's why/how/what, and to the MSX documentation (`https://msxorg.github.io/docs`, source in [`MSXOrg/docs`](https://github.com/MSXOrg/docs)) for organization-level principles and ways of working.
+- `CLAUDE.md` — a thin file that imports `AGENTS.md` with `@AGENTS.md` so Claude Code reads the same instructions. Claude-specific notes, if any, go below the import.
+- `.github/copilot-instructions.md` — repository instructions for VS Code and GitHub Copilot that point to the same documentation.
+
+These files are the agent equivalent of the README: pointers, not copies. Keep them short so the linked documentation stays the single source of truth. Like the other governance files, they live in the repository itself so it can stand on its own.
+
 ## Managed file distribution
 
 Shared files should be treated as managed files. The current distribution service is [`PSModule/Distributor`](https://github.com/PSModule/Distributor). It keeps source file sets under `Repos/{Type}/{Selection}/` and syncs those files into repositories through pull requests.
@@ -133,7 +151,7 @@ The current Distributor model is subscription-based:
 Two follow-up Distributor capabilities define the desired direction:
 
 - **Global file sets** should allow common file sets such as `.gitattributes`, `.gitignore`, and `License` to be defined once and made available to all repository types while still requiring subscription.
-- **Mandatory file sets** should allow organization-critical files such as `SECURITY.md`, `CODE_OF_CONDUCT.md`, `CONTRIBUTING.md`, and supply-chain configuration to be pushed to applicable repositories without each repository having to subscribe manually.
+- **Mandatory file sets** should allow organization-critical files such as `SECURITY.md`, `CODE_OF_CONDUCT.md`, `CONTRIBUTING.md`, the agent onboarding files (`AGENTS.md`, `CLAUDE.md`, `.github/copilot-instructions.md`), and supply-chain configuration to be pushed to applicable repositories without each repository having to subscribe manually.
 
 Until mandatory file sets exist, repository owners are still responsible for ensuring the required common files exist. Distributor is the preferred implementation mechanism; this document is the standard that says what must exist and why.
 
@@ -180,7 +198,7 @@ The README answers these questions, in this order:
 | What is it? | Name the module and define its scope in one short paragraph. |
 | Why should I care? | State the value or kind of task the module makes easier. |
 | How do I get it? | Show the PowerShell Gallery install and import commands. |
-| How does it work? | Show one to three representative capabilities or usage examples. |
+| How does it work? | Show one to three representative usage examples. |
 | How do I get more info? | Link to generated module documentation and PowerShell help. |
 
 Module installation examples must use PSResourceGet:
@@ -207,11 +225,11 @@ Install-PSResource -Name <ModuleName>
 Import-Module -Name <ModuleName>
 ```
 
-## Capabilities
+## Usage
 
-Use this section as a short showcase and introduction to how the module works. Show the most important things the module makes possible with one to three realistic examples.
+Use this section as a short showcase and introduction to how the module works. Show the most important things the module makes possible with one to three realistic examples; `### Example: <scenario>` subsections are fine when you have more than one.
 
-The goal is discovery and marketing, not exhaustive command documentation. A reader should understand why the module exists and what kind of tasks it helps with.
+The goal is discovery, not exhaustive command documentation. A reader should understand why the module exists and what kind of tasks it helps with.
 
 ```powershell
 # Replace this with a real example that demonstrates the module's value.
@@ -232,19 +250,19 @@ Get-Help -Name <Command> -Examples
 
 In the documentation examples, replace `<Command>` with a real command exported by the module, for example `Get-Help -Name Get-GitHubRepository -Examples`, so the snippet runs as written. Do not ship placeholder tokens such as `'CommandName'` or `<CommandName>` as if they were runnable commands.
 
-Implemented modules must include the capabilities or usage showcase before the documentation link. Keep it focused on discovery: show one to three representative outcomes, not every command, parameter, or edge case. A landing page with only an installation snippet and a documentation link is not enough for a module that has working commands.
+Implemented modules must include the `## Usage` showcase before the documentation link. Keep it focused on discovery: show one to three representative outcomes, not every command, parameter, or edge case. A landing page with only an installation snippet and a documentation link is not enough for a module that has working commands. Do not title this section `## Capabilities`; use `## Usage` (or `## Examples`).
 
 Keep, trim, or relocate content — do not delete it:
 
-- **Keep on the landing page:** the overview, prerequisites and requirements (PowerShell version, supported platforms, module or native dependencies), installation, the capabilities showcase, and the short operational notes a reader needs before first use.
+- **Keep on the landing page:** the overview, prerequisites and requirements (PowerShell version, supported platforms, module or native dependencies), installation, the usage showcase, and the short operational notes a reader needs before first use.
 - **Trim:** exhaustive command inventories, parameter tables, and repetitive examples that differ only by a parameter. These come from comment-based help — point to `Get-Help` and the documentation site instead of restating them.
 - **Relocate only to a published home — never drop:** long-form guides and unique conceptual content (authentication and setup walkthroughs, deep operational detail, end-to-end scenarios) may move out of the README only into a surface that is actually published: a command group's overview page under `src/functions/public/<Group>/<Group>.md`, or comment-based help. A bare top-level `docs/` folder is not published by the current docs build, so moving content there drops it from the site. When there is no published home for it yet, keep the full content in the README. A longer landing page is acceptable and expected for feature-rich modules; do not shorten by deleting.
 
 Retain upstream attribution and licensing context. Credit, acknowledgements, donation notes, and third-party license notices for wrapped or bundled work must stay in the README, or move to a clearly linked place. The rule below about community and policy sections does not apply to attribution the project is expected to carry.
 
 README pages should not duplicate generated command documentation. Do not add full command inventories, parameter tables, or long reference sections when those details are already produced from comment-based help.
 
-Do not add a community-file or policy link section by default. Readers can find standard repository files such as `LICENSE`, `CONTRIBUTING.md`, `SECURITY.md`, and `CODE_OF_CONDUCT.md` through GitHub conventions and the repository file tree. Link them only when the module has an unusual rule the user must know before using it, or when it carries required upstream attribution.
+Do not add a community-file, policy, or Contributing link section to the README by default, and do not add a `## Contributing` section. Each repository carries its own `CONTRIBUTING.md`, `SECURITY.md`, `SUPPORT.md`, and `CODE_OF_CONDUCT.md`; readers and tools find them through the repository file tree and GitHub renders them in its UI. The README links or restates them only when the module has an unusual rule the user must know before using it, or when it carries required upstream attribution.
 
 ## Placeholder and in-progress repositories
 
@@ -280,13 +298,14 @@ Before opening a README-only PR, check that the README follows the default and d
 Select-String -Path README.md -SimpleMatch -Pattern 'Greet-Entity', 'PSModuleTemplate', 'YourModuleName'
 Select-String -Path README.md -SimpleMatch -Pattern '{{ NAME }}', '{{ DESCRIPTION }}'
 Select-String -Path README.md -SimpleMatch -Pattern "-Name 'CommandName'", '<CommandName>'
-Select-String -Path README.md -Pattern '^## Commands$'
+Select-String -Path README.md -Pattern '^## (Commands|Capabilities)$'
+Select-String -Path README.md -Pattern '^Install-Module\b'
 git diff --check -- README.md
 ```
 
 `Template-PSModule` is the exception: it intentionally keeps `{{ NAME }}` and `{{ DESCRIPTION }}` tokens because those are template inputs.
 
-For an implemented module, also confirm the README keeps a capabilities or usage showcase and that any unique content removed from the previous version — prerequisites, setup or authentication guidance, operational notes, or upstream attribution — was relocated to `docs/`, `examples/`, or comment-based help rather than deleted.
+For an implemented module, also confirm the README keeps a `## Usage` showcase and that any unique content removed from the previous version — prerequisites, setup or authentication guidance, operational notes, or upstream attribution — was relocated to a published surface (`src/functions/public/<Group>/<Group>.md`, `examples/`, or comment-based help) rather than deleted.
 
 ## Documentation ownership
 

src/docs/PowerShell/Modules/index.md

@@ -22,6 +22,7 @@ Version increments are driven by PR labels (`Major`, `Minor`, `Patch`, `Prerelea
 
 - **[Repository Defaults](Repository-Defaults.md)** — Required repository defaults for PSModule PowerShell module repos, including README shape, placeholder handling, metadata, and documentation ownership.
 - **[Standards](Standards.md)** — Repository layout, naming, style, parameter design, comment-based help, and SOLID applied to PowerShell modules.
+- **[Module types](Module-Types.md)** — Type-specific conventions for integration (API) modules and data modules, including function-to-REST naming and using Context for user and module settings.
 - **[Test Specification](Test-Specification.md)** — How we write Pester tests: structure, hierarchy, and naming conventions.
 - **[Versioning](Versioning.md)** — How changes to the public interface determine the SemVer version bump.