# Release Workflow

> Use when cutting or merging branches, making commits, opening pull requests, preparing release notes, or triggering GitHub release updates in an OpenArc-governed repository.

- Skill: `yipxiyi/release-workflow` (Agent Skill)
- Install (CLI): `npx skillmds@latest add yipxiyi/release-workflow`
- Raw SKILL.md: https://api.skillmd.com/api/skills/yipxiyi/release-workflow/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: Yipxiyi (https://skillmd.com/u/yipxiyi)
- Updated: 2026-09-21
- Page: https://skillmd.com/skills/yipxiyi/release-workflow

---


# Release Workflow

Use this skill when the user wants standardized branch, commit, PR, merge, or GitHub release work.

## Preconditions

Before changing git state:

1. Inspect current branch and working tree.
2. Identify user changes and do not overwrite them.
3. Confirm the target base branch.
4. Use `version-governance` when the change affects release version.
5. Run relevant validation before PR or release.

## Branch Rules

Default branch name:

```txt
<type>/<version-or-ticket>-<short-slug>
```

Allowed types:

- `feature`
- `fix`
- `docs`
- `refactor`
- `chore`
- `release`
- `migration`

Examples:

- `feature/0.2.0-workspace-migration`
- `fix/0.2.1-prd-clarification-flow`
- `release/0.2.0`

## Commit Rules

Use conventional commits:

```txt
<type>(<scope>): <summary>
```

Examples:

- `feat(openarc): add workspace migration skill`
- `docs(brand): clarify brainstorming flow`
- `fix(release): require validation before pr`

Keep commits focused. Do not mix unrelated changes.

## PR Rules

PR body should include:

- Summary
- Version impact
- Validation
- Risks
- Rollback
- Release notes

Use `templates/RELEASE.template.md` for release-facing content when useful.

Update `CHANGELOG.md` for user-visible changes before opening the PR.

## GitHub Release Update

PR completion is the default stopping point. Preparing release notes, making a branch, committing, or opening/merging a PR does not authorize a release.

Only trigger the repository's release update mechanism when the user explicitly requests a release and confirms the version and publish behavior:

1. Prefer the repo's existing GitHub Actions workflow, release-drafter config, semantic-release setup, or documented release script.
2. Inspect whether the trigger publishes immediately or creates a draft, then confirm that behavior before running it.
3. Trigger the workflow with the confirmed version and release notes, or create/update a draft release when no automation exists.
4. Never trigger or publish a final release from an implied follow-on step.

## Merge Rules

- Merge only after required checks pass or the user explicitly accepts the risk.
- Use the repository's preferred merge strategy.
- After merge, verify release automation only when a release was explicitly requested; otherwise stop at the merge result.

## Final Report

Report:

- Branch
- Commit(s)
- PR URL
- Confirmed version
- Validation
- Changelog entry
- Release update trigger/result
- Any blockers