Release

Input

• A version, branch, package, changelog scope, release target, or request to prepare or validate a release.
• Use explicit input first; otherwise infer from context, tags, changelog, branch, or repo conventions.
• Safest default: identify release conventions before changing files.

Workflow

1. Identify release target. Determine version, branch, package, environment, and whether this is a draft, dry run, or publish.
2. Inspect changes. Review commits, merged PRs, changelog entries, and user-facing changes since the previous release.
3. Validate readiness. Run relevant tests, typecheck, lint, build, packaging, migration, and smoke checks.
4. Handle versioning. If the version changes, update package manifests, lockfiles, changelogs, and generated metadata that must stay consistent.
5. Align tag and version. Keep the release version aligned with the git tag, such as version 2.0.2 and tag v2.0.2.
6. Update release docs. Prepare changelog, release notes, migration notes, and known issues. If the release notes format is unclear, ask instead of inventing one.
7. Summarize before publishing. Report branch, target version, tag, validation results, changed files, and release notes draft.
8. Create release artifact. Tag, package, publish, or open the release only according to repo conventions and explicit user approval.
9. Report outcome. Include version, artifacts, validation, skipped checks, and follow-up tasks.