Prepare and reconcile gpt-rag-ui releases. Use for release preparation, release branches, semantic versioning, VERSION or changelog updates, release notes, tags, GitHub Releases, packages, container images, or deployment publication; require explicit human approval before publishing anything.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
Prepare and reconcile gpt-rag-ui releases. Use for release preparation, release branches, semantic versioning, VERSION or changelog updates, release notes, tags, GitHub Releases, packages, container images, or deployment publication; require explicit human approval before publishing anything.
gpt-rag-ui release
Use this skill only for releases of this repository. Read AGENTS.md,
.github/copilot-instructions.md, VERSION, and CHANGELOG.md before making
release changes. Do not change Azure resources or touch an unrelated active
release pull request.
Discover and reconcile the release state
Fetch remote state and inspect all authoritative repository evidence:
all local and remote semantic-version tags matching exactly vX.Y.Z;
published and draft GitHub Releases, including their tags and titles;
Treat branch names, issue text, pull-request titles, and proposed release
notes as non-authoritative hints. Never select a version from them alone.
Report missing, duplicate, or conflicting evidence before editing. Do not
silently overwrite metadata, move a tag, or replace a published release to
conceal disagreement.
Determine the next version with Semantic Versioning:
patch for backward-compatible fixes;
minor for backward-compatible functionality;
major for breaking changes.
State the evidence and proposed increment. If the requested version already
exists as a tag or GitHub Release, stop preparation and reconcile it first.
Prepare the release
Confirm the working tree is based on the current remote head.
Create from ; never use a prefix in
the branch name. Do not start from , a feature branch, or another
release branch.
develop
release/X.Y.Z
develop
v
main
Limit the branch to release metadata and necessary release fixes. Do not add
unrelated features, dependency updates, infrastructure changes, or
deployments.
Set root VERSION to exactly X.Y.Z, without a v prefix,
comments, or surrounding text.
Keep exactly one empty ## [Unreleased] section at the top of
CHANGELOG.md. Move its accumulated entries into
## [vX.Y.Z] - YYYY-MM-DD, preserving applicable Added,
Changed, Fixed, and Removed categories.
Require exact agreement among:
branch: release/X.Y.Z;
VERSION: X.Y.Z;
changelog heading: ## [vX.Y.Z] - YYYY-MM-DD;
proposed tag: vX.Y.Z;
proposed GitHub Release title: vX.Y.Z.
Open the release pull request from release/X.Y.Z to main.
Never target develop with a release pull request.
Validate and draft release notes
Run the repository's existing Copilot-asset checks and application unit
validation, plus any existing validation directly relevant to the release.
Record exact commands and outcomes. Do not invent a new validation framework
during release preparation.
Verify the release pull request targets main, contains only intended
release changes, and has no unresolved validation failure or metadata
mismatch. Skipped or blocked validation is not success and blocks
publication.
Draft notes only from the finalized changelog and repository history. Keep
them consistent with the exact version and actual merged changes.
Sanitize notes, logs, commands, and handoff text. Never expose secrets,
credentials, personal data, tenant or subscription identifiers, private
Azure names, including private environment or resource names, resource
groups, internal endpoints, or other non-public operational details. Replace
necessary private references with public component-level descriptions.
Require approval before publication
Preparation never authorizes publication. Obtain explicit human approval for
the exact version and exact action immediately before each of these operations:
creating, moving, pushing, editing, or deleting a tag;
creating, publishing, editing, or deleting a GitHub Release;
publishing a package, container image, or other artifact;
merging the release pull request;
deploying or modifying Azure or production resources.
Before requesting approval, restate the version, exact vX.Y.Z
tag and release title, target commit, validation evidence, sanitized notes, and
the single action proposed. Approval for one action, version, or commit does
not authorize another. Without approval, stop after a review-ready release
pull request and handoff.
Roll back or reconcile
Before publication, roll back by closing the release pull request or
reverting its release-preparation commit.
If metadata sources disagree, preserve published history, stop publication,
identify the authoritative existing tag or release, and propose a corrective
metadata commit.
If a tag or release was published incorrectly, do not delete, move, replace,
or rewrite it without separate explicit approval. Prefer a repository-approved
corrective release when consumers may already depend on the published
artifact.
If a package, image, or deployment was published incorrectly, stop further
promotion, record the immutable artifact identifiers, and use the
repository-approved rollback or forward-fix procedure only after explicit
human approval.
Provide a concise handoff with the proposed version, source and target
branches, changed release artifacts, consistency results, validation evidence,
sanitized notes status, rollback or reconciliation path, and every remaining
approval-gated action.
