release

$npx mdskill add openai/symphony/release

Bumps version, lands PR, tags commit, and verifies Burrito release.

  • Automates cutting a new Symphony release from a clean main branch.
  • Depends on Git, GitHub PRs, and the Burrito release workflow.
  • Picks next patch version if none specified; updates mix.exs only.
  • Creates annotated tag on merged commit and monitors Burrito CI.

SKILL.md

.github/skills/releaseView on GitHub ↗
---
name: release
description: Cut a Symphony release by bumping the committed version, landing it, tagging the merged commit, and verifying the Burrito release workflow. Use when asked to release, tag, or retag Symphony.
---

# Release

1. Start from fresh `origin/main` in a clean worktree. Never disturb unrelated
   local changes.
2. Pick the requested version. If none is given, use the next patch after the
   latest `vX.Y.Z` tag.
3. Update `elixir/mix.exs` so `version: "X.Y.Z"` matches the intended tag.
   Search the old version and change other files only when they are true
   release-version sources, not examples.
4. Run `make -C elixir all`, then commit, push, create a PR, and land it.
5. Fetch the merged `main` commit. Verify its `mix.exs` version, then create an
   annotated tag on that exact commit:

   ```sh
   git tag -a vX.Y.Z <merged-commit> -m "Symphony vX.Y.Z"
   git push origin vX.Y.Z
   ```

6. Watch `burrito-release` until it finishes. Verify the build, smoke, and
   release jobs pass and that the GitHub release has all expected assets.

Do not tag an uncommitted or unmerged revision. Do not move a published tag
without explicit user approval.

More from openai/symphony

SkillDescription
commit- Produce a commit that reflects the actual code changes and the session context. - Follow common git conventions (type prefix, short subject, wrapped body). - Include both summary and rationale in the body.
debug- Find why a run is stuck, retrying, or failing. - Correlate Linear issue identity to a Codex session quickly. - Read the right logs in the right order to isolate root cause.
land- Ensure the PR is conflict-free with main. - Keep CI green and fix failures when they occur. - Squash-merge the PR once checks pass. - Do not yield to the user until the PR is merged; keep the watcher loop running unless blocked. - No need to delete remote branches after merge; the repo auto-deletes head branches.
linear|
pull1. Verify git status is clean or commit/stash changes before merging. 2. Ensure rerere is enabled locally: - `git config rerere.enabled true` - `git config rerere.autoupdate true` 3. Confirm remotes and branches: - Ensure the `origin` remote exists. - Ensure the current branch is the one to receive the merge. 4. Fetch latest refs: - `git fetch origin` 5. Sync the remote feature branch first: - `git pull --ff-only origin $(git branch --show-current)` - This pulls branch updates made remotely (for example, a GitHub auto-commit) before merging `origin/main`. 6. Merge in order: - Prefer `git -c merge.conflictstyle=zdiff3 merge origin/main` for clearer conflict context. 7. If conflicts appear, resolve them (see conflict guidance below), then: - `git add <files>` - `git commit` (or `git merge --continue` if the merge is paused) 8. Verify with project checks (follow repo policy in `AGENTS.md`). 9. Summarize the merge: - Call out the most challenging conflicts/files and how they were resolved. - Note any assumptions or follow-ups.
push- `gh` CLI is installed and available in `PATH`. - `gh auth status` succeeds for GitHub operations in this repo.