@@ -1,63 +1,136 @@
 <!--
-This is the final content-control plan for the pull request author. The automated release process reuses this title
-and description as the GitHub Release notes by default; it does not create a separate release-note document. Format
-the title, description, and selected version label for the people who use the released artifact. See
-docs/content/guides/formatting-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.
+Follow docs/content/guides/formatting-release-note-prs.md and the shared MSX PR format.
+The release-bound title and complete description are the authored release record. Cover the entire delivered range,
+including prior merged or skipped deltas entering the artifact. Write an audience-first title without an icon/type prefix.
+Keep only applicable classifier sections in the order shown; repeat a section for each distinct result.
+Put complete upgrade instructions and necessary old-to-new examples in each result's prose. PRs/diffs are optional depth.
+Keep supporting blocks scoped to their result. For internal-only work without a classified result, place them after the marker.
+Remove placeholders, empty blocks, and authoring comments; keep the ANNOUNCEMENT STOP marker.
 -->
 
-<One concise paragraph: what users receive and why it matters.>
+{{ Concise summary: what changes, why, who is affected, and required action or an explicit no-action result.
+Lead with breaking impact when applicable. }}
 
-## New: <capability>
+<!-- ANNOUNCEMENT STOP -->
 
-<What users can now do and the result they get.>
+## Breaking: {{ Reader-facing result }}
 
-## Changed: <behavior>
+{{ Explain the result, rationale, affected consumers, compatibility, and verified release/source baseline.
+Give exact adoption or migration actions, prerequisites, order, and verification. Include necessary old-to-new examples.
+Require intermediate installations or runs only when needed. State the no-action result for unaffected consumers. }}
 
-<What users experience differently.>
+<details>
+<summary>Technical details</summary>
+
+{{ Implementation, validation commands and results, compatibility evidence, and standards alignment for this result.
+When an integration template applies, identify its repository and verified immutable compatible commit,
+producer-source compatibility evidence, and linked template work or a justified no-change result. }}
 
-## Fixed: <problem>
+</details>
 
-<What now works and how users benefit.>
+<details>
+<summary>Related references</summary>
 
-## Breaking Changes
+- References Owner/Repository#123
 
-<What no longer works, who is affected, and the compatible replacement.>
+</details>
 
-## Adopting this release
+## Removed: {{ Reader-facing result }}
 
-1. <First action from the currently supported version, reference, configuration, or invocation.>
-2. <Next action and how the user verifies the outcome.>
+{{ Explain what is removed and why, affected consumers, compatibility, and verified release/source baseline.
+Give the supported replacement, exact actions or explicit no-action result, prerequisites, order, and verification.
+Keep required transition examples here; require intermediate installations or runs only when needed. }}
 
-<Or: No configuration, code, or invocation change is required. Update to this version normally.>
+<details>
+<summary>Technical details</summary>
 
-## Release impact
+{{ Implementation, validation commands and results, compatibility and standards evidence for this result.
+Include applicable verified immutable template evidence and linked work or a justified no-change result. }}
 
-- **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>`
+</details>
 
-<!--
-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>Related references</summary>
+
+- References Owner/Repository#123
+
+</details>
+
+## New: {{ Reader-facing result }}
+
+{{ Explain what consumers gain and why, applicability, compatibility, and verified release/source baseline.
+Distinguish optional feature use from required upgrade actions. Give exact actions or an explicit no-action result,
+prerequisites, order, verification, and any required intermediate installations or runs. }}
+
+<details>
+<summary>Technical details</summary>
+
+{{ Implementation, validation commands and results, compatibility and standards evidence for this result.
+Include applicable verified immutable template evidence and linked work or a justified no-change result. }}
+
+</details>
+
+<details>
+<summary>Related references</summary>
+
+- References Owner/Repository#123
+
+</details>
+
+## Changed: {{ Reader-facing result }}
+
+{{ Explain what changes and why, affected consumers, compatibility, and verified release/source baseline.
+Give exact adoption or migration actions or an explicit no-action result, prerequisites, order, and verification.
+Keep required transition examples here; require intermediate installations or runs only when needed. }}
+
+<details>
+<summary>Technical details</summary>
+
+{{ Implementation, validation commands and results, compatibility and standards evidence for this result.
+Include applicable verified immutable template evidence and linked work or a justified no-change result. }}
+
+</details>
+
+<details>
+<summary>Related references</summary>
+
+- References Owner/Repository#123
+
+</details>
+
+## Fixed: {{ Reader-facing result }}
+
+{{ Explain what works correctly and why it matters, affected consumers, compatibility, and verified release/source baseline.
+Give exact actions or an explicit no-action result, prerequisites, order, verification, and any required intermediate
+installations or runs. Keep necessary old-to-new examples in this prose. }}
 
----
 <details>
 <summary>Technical details</summary>
 
-<Implementation approach, compatibility evidence, validation, and standards alignment.>
+{{ Implementation, validation commands and results, compatibility and standards evidence for this result.
+Include applicable verified immutable template evidence and linked work or a justified no-change result. }}
 
 </details>
 
 <details>
-<summary>Relevant issues (or links)</summary>
+<summary>Related references</summary>
+
+- References Owner/Repository#123
 
-- Resolves Owner/Repository#123
+</details>
 
-### Related work
+<!--
+Keep Release decisions only when the target route invokes Release Management.
+Use the actual publisher's configured labels/defaults; this template does not migrate them.
+For no release, keep only Release and Labels, and state that no artifact or version is produced.
+The publisher resolves final numeric coordinates; do not predict them.
+-->
+<details>
+<summary>Release decisions</summary>
 
-- References Owner/Repository#456
+- **Release:** {{ Yes or No, with evidence from the artifact, target route, and supported consumer contracts. }}
+- **Version bump:** {{ Patch, Minor, or Major, with verified semantic impact and the configured decision source. Omit for No. }}
+- **Mode:** {{ Stable or Prerelease, with route or override evidence. Omit for No. }}
+- **Labels:** {{ Exact applied labels, or None when effective configuration supplies the decision without an override. }}
 
 </details>
@@ -41,7 +41,8 @@ documentation site.
 The
 [`psmodule-release-note-authoring`](./psmodule/skills/psmodule-release-note-authoring/SKILL.md)
 skill formats pull request titles, descriptions, and labels as user-facing
-release notes with adoption steps and verified version transitions.
+release records with complete upgrade instructions, verified semantic impact,
+and publisher-resolved versions.
 Verify the installation with:
 
 ```console
 
@@ -1,38 +1,21 @@
 ---
 name: psmodule-release-note-authoring
-description: Format pull request titles, descriptions, and labels as user-facing release notes with adoption steps and a verified version transition.
+description: Author or review pull requests as complete consumer upgrade records using the shared release-note guidance.
 ---
 
 # Format release-note pull requests
 
-Use this skill when formatting, rewriting, or reviewing a pull request whose title and description will be published
-as release notes. This skill controls the author-facing pull request message; it does not create separate release
-notes. Read the [pull-request formatting guide](../../../../../docs/content/guides/formatting-release-note-prs.md)
-before editing the pull request. That guide owns the release-note structure and the user-facing writing rules.
+Use when formatting, rewriting, or reviewing a pull request whose title and complete description become release
+notes. First read the [authoring guide](../../../../../docs/content/guides/formatting-release-note-prs.md);
+it owns the release-record content, replay check, evergreen-documentation boundary, and validation.
+The linked [MSX PR format](https://msx.no/docs/Ways-of-Working/PR-Format/) owns the shared title and description structure.
 
-## Operating contract
+If the repository-relative guide is unavailable from an installed plugin, read its
+[published page](https://psmodule.io/docs/guides/formatting-release-note-prs/) instead.
 
-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. Format the title, description, and selected label around one user outcome. Group description 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.
+## Agent-specific contract
 
-## 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
-
-- [Formatting release-note pull requests](../../../../../docs/content/guides/formatting-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/)
+- Read the target repository's instructions and PR template before editing its metadata.
+- Apply the guide's authoring and replay checks to the full delivered range.
+- Report the edited PR URL, relevant baseline, verified impact, and validation outcomes to the owning session.
+- Stop and report when the cited guidance or required source evidence is unavailable; identify the evidence gap.