@mutmutco/codex-plugin 3.139.12 → 4.0.1

package/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "mmi",
-  "version": "3.139.12",
+  "version": "4.0.1",
   "mmiCompat": "3.x",
   "description": "MMI workflow skills and org gates delivery.",
   "author": {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@mutmutco/codex-plugin",
-  "version": "3.139.12",
+  "version": "4.0.1",
   "description": "MMI workflow skills and org gates delivery.",
   "author": {
     "name": "MMI Future",

package/skills/release/SKILL.md

@@ -440,11 +440,22 @@ Before running `--apply` for MMI-Hub, resolve the real tag first:
 `v2.43.0`) in summaries, Slack, chat, and the final report; never a placeholder like `vX.Y.0` or
 `v0.x.0`.
 
-Write a curated summary — 3-6 very short plain lines, one change per line, dev-readable, no PR-dump —
-to a fresh temp file (`f=$(mktemp tmp/release-summary.XXXXXX)`, so a stale prior summary is never reused).
-Source from **Hub PR titles only** (`origin/main..origin/development` on `mutmutco/MMI-Hub`), but **rewrite**
-each line in neutral Hub-subsystem terms (CLI, skills, plugin, workflows, registry, deploy hub) — **never**
-a product or brand name (FoFu, Katip, etc.) anywhere in the summary file, Slack post, chat, or release
+**Write the announcement per `docs/Guides/release-notes.md`** — the canonical org guide for every
+release type. It is the authoritative contract; follow it and its checklist before posting. Key rules:
+
+- **Audience is the whole org** — no issue/PR numbers, repo names, commit SHAs, or internal tool jargon.
+- **Scale length and depth by release type** (major > minor > patch > hotfix): a major is a broad,
+  migration-focused announcement; a minor is scannable grouped bullets; a patch is factual and minimal;
+  a hotfix is incident-style (impact/status/workaround) with a concise durable note.
+- **Front-load**: one lead sentence stating the most important thing, then grouped bold sections;
+  breaking changes and required actions get their own visible section.
+- **Benefits, active voice, addressed to the reader** — no hype, no internal identifiers.
+
+Write the curated summary to a fresh temp file (`f=$(mktemp tmp/release-summary.XXXXXX)`, so a stale prior
+summary is never reused). Source from **Hub PR titles only** (`origin/main..origin/development` on
+`mutmutco/MMI-Hub`), but **rewrite** each line in neutral Hub-subsystem terms (CLI, skills, plugin,
+workflows, registry, deploy hub) and to the release-type depth the guide demands — **never** a
+product or brand name (FoFu, Katip, etc.) anywhere in the summary file, Slack post, chat, or release
 report. Product names are allowed only when releasing **that product's repo**. Then pass the file through:
 `mmi-cli devops release --apply --announce-summary-file "$f"`. After the GitHub Release publishes, the CLI posts
 the summary to the org alerts channel as the MMI-Future Slack app (token + channel from SSM at run time).