Release Manager

Overview

Prepare Django4Lyfe promotions and releases, validate deploy candidates, or publish an authorized release.

This skill ships inside the Backend Release Manager plugin and can be installed through the Claude Code marketplace or directly in Codex from its skill path.

Parent Surface

Modes and permissions

release PRs. Report verified PR URLs, direct commits, ambiguities, and the recommended next version; do not create PRs, tags, or deployments.

exact merge commit. Publication does not imply deployment permission.

disclose cached-ref freshness. Do not fetch, edit, push, publish, or deploy.

Ask for the intended mode if ambiguous. Require explicit authorization for merges, deploys, RLS policy writes, and branch synchronization. Never interpret check, PR creation, or GitHub publication as permission to deploy.

• check: inspect pending release scope, version, recent releases, and open release PRs. Report verified PR URLs, direct commits, ambiguities, and the recommended next version; do not create PRs, tags, or deployments.
• create / release-prod: prepare release → master.
• promote-staging: prepare dev → release.
• publish PR_NUMBER: publish the already-merged production release at its exact merge commit. Publication does not imply deployment permission.
• --hotfix: use the hotfix title convention without bypassing scope or gates.
• --dry-run: show the intended actions using read-only inspection only; disclose cached-ref freshness. Do not fetch, edit, push, publish, or deploy.

Prerequisites and shared scope evidence

Read repo-local workflow docs and verify the target repository, clean working state, remotes, branch policy, and installed tools before changes. Require Git, gh authentication and jq. Scope capture needs Python 3.9+; the publication TOML command needs Python 3.11+. Version/lock updates need uv. These helper minimums do not replace the target repository's Python requirements for its application, validation, or deployment.

gate with a missing binary is a blocker, not permission to skip it.

only the documented repo-local validation/deploy path; otherwise stop.

Require its scripts/get_release_scope.py; stop if installation is incomplete.

Read captured release scope before check or candidate preparation. It owns snapshot capture, PR attribution, legacy cherry-pick reconciliation, and candidate verification. Use its helper for both promotion and production scopes; do not substitute timestamps or a capped PR search. Preserve full source/base/head SHAs in the PR body.

• Detect local-ci with command -v local-ci and .local-ci.toml. A configured gate with a missing binary is a blocker, not permission to skip it.
• Detect scripts/deploy/trigger_validated_backend_deploy.sh. If absent, use only the documented repo-local validation/deploy path; otherwise stop.
• Set SKILL_DIR to the absolute directory containing this loaded SKILL.md. Require its scripts/get_release_scope.py; stop if installation is incomplete.

Prepare a staging candidate

Capture origin/release as BASE_SHA and origin/dev as SOURCE_SHA with the shared scope procedure. Review the diff and attributed PRs; an empty content diff is not a new release. Create the branch from those captured commits:

Feature PRs merge to dev; promotion is the intentional move onto release. The open promotion branch's local-ci run is a preflight only. In Django4Lyfe it can run the full parity lanes; failures block readiness. It does not replace validation of the exact merged release head. Validate staging before preparing production. Fix staging issues on dev and promote again, not by patching release directly.

git checkout -b promote/YYYY.MM.DD[-N] "$BASE_SHA"
git merge "$SOURCE_SHA" --no-edit
git push -u origin promote/YYYY.MM.DD[-N]
gh pr create --base release --title "Promotion: DDth Month YYYY" --body-file /path/to/reviewed-promotion-notes.md

Prepare a production candidate

Capture origin/master as BASE_SHA and origin/release as SOURCE_SHA with the shared scope procedure. Reconcile legacy patch duplicates and unresolved PR attribution before claiming a complete release list.

Use merge commits, not cherry-picks or squash merges. Cherry-picks create new SHAs for old patches; squash merging the release PR destroys the ancestry needed for subsequent scope checks. Preserve original source commits through the promotion and release PRs. Still inspect actual content and conflict resolutions: ancestry alone does not prove patch novelty or preservation.

Read detailed procedures for date-based versions, Promotion/Release/Hotfix titles, notes format, and conflict recovery.

git checkout -b releases/YYYY.MM.DD[-N] "$BASE_SHA"
git merge "$SOURCE_SHA" --no-edit
uv lock
git add pyproject.toml uv.lock
git commit -m "Version bump to YYYY.MM.DD[-N]"
git push -u origin releases/YYYY.MM.DD[-N]
gh pr create --base master --title "Release: DDth Month YYYY" --body-file /path/to/reviewed-release-notes.md

Resources

Declared allowed tools:

Installation

Switch between Claude Code and Codex, then copy the install command for the runtime you use.

claude plugin marketplace add DiversioTeam/agent-skills-marketplace
claude plugin install backend-release@diversiotech

CODEX_HOME="${CODEX_HOME:-$HOME/.codex}"
python3 "$CODEX_HOME/skills/.system/skill-installer/scripts/install-skill-from-github.py" \
  --repo DiversioTeam/agent-skills-marketplace \
  --path plugins/backend-release/skills/release-manager

Invocation:

/backend-release:check
/backend-release:create
/backend-release:publish

name: release-manager