| name | summarize-release-status |
| description | Use when the user asks for a Mage-OS release-prep status update to share with other maintainers — e.g. "summarize release status for Discord", "write a maintainer update", "status of 3.0 prep", "draft a status message about the release branches", or after running the branch audit / PR-prep skills and the user wants the takeaway formatted for sharing. |
Summarize Release Status for Maintainers
Produces a concise, copy-paste-ready maintainer update (Discord-style) summarizing the state of branch coverage and PR readiness for a Mage-OS release. Consumes the output files from [[audit-release-branches]] and/or [[prep-release-prs]].
When to use
- After running an audit / PR-prep pass, when the user wants a shareable update.
- Periodic check-ins to maintainers about release progress.
- Catching up new maintainers on where the release stands.
When NOT to use
- Full release notes (use [[analyze-release-preview]] instead).
- Per-PR status (just link the PRs directly).
- Internal-only tracking (a plain
.txt file is fine).
Input data
Whichever of these exist in the working directory:
repos-with-release-<X>.x.txt — output of find-repos-with-branch.shdevelop-vs-trunk.txt — output of find-unmerged-develop.shrelease-prs-plan.txt — output of open-release-prs.sh (especially after --apply so it contains PR URLs)
Output shape
Markdown chunks suitable for Discord. Aim for short, scannable, no emoji unless the user asks for them. Structure:
- One-sentence header — what release, what was scanned.
release/3.x already cut — bulleted list of repos.develop / 2.4-develop ahead of trunk — table with repo, branch, commits ahead. Order alphabetically.- Next step / status — what automation has run, what's pending, exclusions and why.
- Pointer — where the scripts and outputs live for anyone who wants to re-run.
Keep the whole thing under ~25 lines so it fits in one Discord message. If a section is empty, omit it rather than printing "(none)".
Example
The version numbers below are illustrative for the 3.0 cycle — substitute the actual release the user is preparing (4.0, 5.0, …).
**Mage-OS 3.0 release prep — branch status**
Scanned all non-mirror repos in `mage-os` (65 total, forks included).
**`release/3.x` already cut (5 repos, ready to go):**
- generate-mirror-repo-js
- mageos-inventory
- mageos-magento2
- mageos-magento2-page-builder
- mageos-security-package
**`develop` / `2.4-develop` ahead of `main` (need merging for 3.0):**
| Repo | Branch | Commits ahead |
|---|---|---|
| mageos-PHPCompatibilityFork | develop | 8 |
| mageos-adobe-stock-integration | develop | 33 |
| ...
**Next step:** PR automation ready (12 PRs planned). `mageos-magento2` excluded — pre-merged manually both directions. Will run after maintainer review.
Tips
- Always quote the absolute commit-ahead numbers — maintainers use them to gauge merge complexity.
- Call out diverged branches (high
behind count) explicitly — they may not merge cleanly.
- If [[prep-release-prs]] has been applied, include a flat list of PR URLs at the end so reviewers can jump in directly.
- Re-running the audit before writing the summary keeps numbers current; counts change as PRs merge.
