Add release note authoring skill

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

Author: MariusStorhaug

.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,61 @@
+<!--
+This title and description become the GitHub Release notes by default. Write for the people who use the released
+artifact. See docs/content/guides/writing-release-note-prs.md and the psmodule-release-note-authoring skill.
+Delete headings that do not apply. Remove every placeholder and comment before marking the pull request ready.
+-->
+
+<One concise paragraph: what users receive and why it matters.>
+
+## New: <capability>
+
+<What users can now do and the result they get.>
+
+## Changed: <behavior>
+
+<What users experience differently.>
+
+## Fixed: <problem>
+
+<What now works and how users benefit.>
+
+## Breaking Changes
+
+<What no longer works, who is affected, and the compatible replacement.>
+
+## Adopting this release
+
+1. <First action from the currently supported version, reference, configuration, or invocation.>
+2. <Next action and how the user verifies the outcome.>
+
+<Or: No configuration, code, or invocation change is required. Update to this version normally.>
+
+## Release impact
+
+- **Configured label:** `<label that selects this release>`
+- **SemVer change:** `<Major | Minor | Patch>`
+- **Version transition:** `<current published version> -> <planned release version>`
+- **Release name:** `<planned release version>`
+
+<!--
+For a skip/no-release label, say that no artifact is published and no version transition occurs.
+For a prerelease, state the selected bump and that it is not the latest stable version.
+-->
+
+---
+<details>
+<summary>Technical details</summary>
+
+<Implementation approach, compatibility evidence, validation, and standards alignment.>
+
+</details>
+
+<details>
+<summary>Relevant issues (or links)</summary>
+
+- Resolves Owner/Repository#123
+
+### Related work
+
+- References Owner/Repository#456
+
+</details>

.github/plugin/README.md

@@ -38,6 +38,10 @@ The
 [`psmodule-skill-authoring`](./psmodule/skills/psmodule-skill-authoring/SKILL.md)
 skill keeps plugin skills thin and points shared authoring guidance to the
 documentation site.
+The
+[`psmodule-release-note-authoring`](./psmodule/skills/psmodule-release-note-authoring/SKILL.md)
+skill writes release-bound pull requests as user-facing release notes with
+adoption steps and verified version transitions.
 Verify the installation with:
 
 ```console

.github/plugin/psmodule/skills/psmodule-release-note-authoring/SKILL.md

@@ -0,0 +1,37 @@
+---
+name: psmodule-release-note-authoring
+description: Write or review release-bound pull requests as user-facing release notes with adoption steps and a verified version transition.
+---
+
+# Author release-note pull requests
+
+Use this skill when authoring, rewriting, or reviewing a pull request whose title and description will be published as
+release notes. Read the [release-note pull request guide](../../../../../docs/content/guides/writing-release-note-prs.md)
+before editing the pull request. That guide owns the release-note structure and the user-facing writing rules.
+
+## Operating contract
+
+1. Identify the artifact users consume, its current published version or reference, its configured version-label
+   mapping, and the users affected by the change.
+2. Write the title and leading paragraph around the user outcome. Group changes by what users experience, not by files
+   or implementation activity.
+3. Include an ordered `Adopting this release` section for every affected user. State that normal updating is sufficient
+   when no configuration, code, or invocation change is required.
+4. Verify the configured label, SemVer effect, current published version, and planned release version together. Refresh
+   the numeric transition before the pull request is ready if another release may have changed the baseline.
+5. Put implementation, validation, compatibility evidence, and standards alignment in the final `Technical details`
+   block. Preserve the MSX `Relevant issues (or links)` block at the end.
+6. Rework the title, adoption path, and release impact whenever the diff, selected label, or compatibility impact
+   changes. Do not leave placeholders, stale version values, or reviewer-oriented prose in the published body.
+
+## Stop conditions
+
+Stop and report when the release label mapping, current published version, artifact consumer, or compatibility impact
+cannot be determined. Do not infer a version transition from conventional label names, describe routine adoption as a
+migration, or claim that no user action is needed without inspecting the delivered behavior.
+
+## References
+
+- [Writing release-note pull requests](../../../../../docs/content/guides/writing-release-note-prs.md)
+- [Versioning and releases](../../../../../docs/content/guides/versioning-and-releases.md)
+- [MSX PR format](https://msx.no/docs/Ways-of-Working/PR-Format/)