agentsclimarketplace
Sign in

Cutting a release

Skill gustavo-meilus/superpipelines/.agents/skills/cutting-a-release

Cut a Superpipelines version release (vX.Y.Z) — verify the 5 version targets agree, draft CHANGELOG + RELEASE-NOTES entries, land them via PR (main is branch-protected), then create the GitHub release + tag and verify. Use when the user asks to cut/ship/publish a release, tag a version, do release work, or write release notes for Superpipelines.From its SKILL.md

Install
npx -y skills add gustavo-meilus/superpipelines --skill cutting-a-release

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • 4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
  • runs commandsInstructs the agent to run 6 commands, including `git fetch origin` and 5 more.

SKILL.md

3.9 KB, 939 tokens by cl100k_base, as published. Nobody here has run it

Cutting a Superpipelines Release

Cut a version release after the feature PR(s) are merged into main. Full step detail + gotchas live in RUNBOOK.md — read it before acting.

Hard constraints (read first)

  • main is branch-protected. No direct git push origin main. Every change goes through a PR. gh pr merge <n> --squash --admin bypasses REVIEW_REQUIRED (CI must still be green) — confirm with the user before any --admin override.
  • JSON must be BOM-free. Never Set-Content -Encoding UTF8 for JSON. Use the Edit tool or python3 writes (encoding="utf-8").
  • 5 version targets must agree before tagging: package.json, .Codex-plugin/plugin.json, .Codex-plugin/marketplace.json (plugins.0.version — NOT the top-level 1.0.0), .cursor-plugin/plugin.json, AGENTS.md (- **Project Version**: vX.Y.Z). First 3 listed in .version-bump.json; last 2 are manual.
  • Tag ↔ changelog convention: every tag vX.Y.Z MUST have a matching ## X.Y.Z CHANGELOG entry and a ## vX.Y.Z RELEASE-NOTES entry before gh release create.
  • gh CLI in Bash tool: never --body @'...'@ (PowerShell here-string, fails). Write the body to a temp .md, use --body-file, then rm it. Keep temp files out of commits.

Workflow

  1. Preflight — git fetch origin; confirm origin/main has the feature merge; verify all 5 version targets agree and equal the intended vX.Y.Z (npm run check:versions covers 6 including .codex-plugin); check tag/release naming convention (vX.Y.Z — <Title Case Name>). Profile-drift check: confirm the latest "Profile drift review" issue (opened monthly by .github/workflows/profile-drift.yml) is closed or its findings are consciously deferred in the release notes; a model_tiers_version older than 90 days blocks unless deferred.
  2. Sync local main — ExitWorktree action:keep if in a worktree; git checkout main && git pull --ff-only origin main (clear stale untracked blockers first — diff against origin/main).
  3. Draft doc entries — add ## X.Y.Z to CHANGELOG.md and a <release_entry> to RELEASE-NOTES.md, mirroring the previous entry's format exactly. Source bullets from real changes; do not invent.
  4. Land docs via PR — branch release-notes-X.Y.Z, commit, push, gh pr create (--body-file), wait for CI pass, confirm intent, gh pr merge --squash --admin --delete-branch, re-sync main.
  5. Create release + tag — extract the new CHANGELOG section as the release body, append the install line, gh release create vX.Y.Z --target main --title "vX.Y.Z — <Title>" --notes-file <tmp>.
  6. Verify — tag commit == origin/main; release not draft/prerelease; Closes #N issues CLOSED; follow-up issues still OPEN.
  7. Aiboarding pointer (optional) — if release docs don't touch the 3 AIBOARDING sections, no-op advance last_synced_commit to HEAD via the same PR + --admin flow. Expect one residual drift nag on the bump commit — STOP, do not chase.

Gotchas checklist

  • Bumped plugins.0.version in marketplace.json, not top-level 1.0.0.
  • All 5 version targets agree before tagging (npm run check:versions).
  • Latest profile-drift review issue closed or explicitly deferred.
  • CHANGELOG + RELEASE-NOTES entries exist before gh release create.
  • Used --body-file for all gh bodies (never @'...'@).
  • No direct push to main — everything via PR.
  • Got user OK before any --admin override.
  • Temp files cleaned up, kept out of commits.

What ships with it: 1 file

7.5 KB alongside SKILL.md

Gives 1 of the 12 instructions most ship operate skills give in 939 tokens

Counted across 1,077 of the 1,713 authors here whose files we hold, read 2026-09-06

  • Create GitHub releasehere, and in 44 of 1077, across 43 files
  • Run the test suitein 30 of 1077, across 25 files
  • Create and push git tagin 27 of 1077, across 26 files
  • Push commits and tagsin 27 of 1077
  • Create annotated tagin 25 of 1077, across 22 files
  • Ensure working tree is cleanin 24 of 1077
  • Check for product marketing context firstin 23 of 1077, across 6 files
  • Commit version bump changesin 22 of 1077, across 21 files
  • Update CHANGELOG.mdin 21 of 1077, across 20 files
  • Structure launch marketing across three channel typesin 20 of 1077, across 5 files
  • Commit and tag the releasein 20 of 1077, across 18 files
  • Update the CHANGELOG for new releasesin 19 of 1077

Said here and by no other author read

  • Read RUNBOOK.md before acting
  • Verify five version targets agree before tagging
  • Ensure matching changelog and release notes entries
  • Use body file for gh CLI commands
  • Land documentation changes via pull request

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 325,949. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.