smithery.ai

mflux-release

Prepare a release in mflux (version bump + uv lock; release notes are harvested from PR release-note blocks and live in GitHub Releases). Use when preparing a release branch or release PR.

First seen Apr 4, 2026

Installation

$ npx skills add https://smithery.ai

Similar popular skills

Related neighbors and high-traction skills in the same topics — useful to compare before installing.

Also in this package

Other skills from smithery.ai · top by installs.

npx skills add https://smithery.ai

Browse all from smithery.ai

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 1,521 B
  • docs SUMMARY.md 110 B

History

  1. First seen on skills.sh
  2. First recorded snapshot · 1 installs

SKILL.md

mflux release prep

Releases are prepared in-repo; tagging/publishing is handled by GitHub Actions (release.yml, dispatched from main with the publish confirmation).

How notes work now (#685)

  • Every PR carries a fenced `release-note block in its body (CI enforces it;

none opts a PR out). That block is the only source of release notes.

  • On dispatch, the ungated draft-notes job harvests the blocks for every PR whose

squash commit is in previous-tag..HEAD and fills a DRAFT GitHub release, grouped by label.

  • Whoever approves the pypi deployment reads and edits that draft (fixing any

[needs edit] lines, adding contributor thanks if wanted); the gated job publishes it exactly as edited. A re-dispatch never overwrites an existing draft; delete the draft to re-harvest.

Release-prep PR checklist

  • Bump version in pyproject.toml
  • Update lockfile: uv lock
  • Release-note block of the prep PR itself: none
  • Prefer one commit named release: prepare <version>
  • Sanity checks (optional unless requested): just test-fast, just build
  • Do not tag releases locally unless explicitly requested (normally handled by CI)