---
name: release-workflow
description: Use when the user asks to release, bump version, update changelog/version files, or commit/push a repository release for the Planet repo. Applies the repo's versioning rules, updates all required version-bearing files, updates changelog/version-history, runs minimal relevant validation, and then commits/pushes when requested.
---

# Release Workflow

Use this skill for release-oriented work in this repository.

## When To Use

- The user asks to `发版`
- The user asks to bump a version
- The user asks to update `CHANGELOG`, `version-history`, or version files as part of a release
- The user asks to commit/push a release or a publishable bugfix/feature bundle

Do not use this skill for ordinary commits that are not being released.

## Versioning Rules

- `feature` -> bump `+0.1.0`
- `bugfix` -> bump `+0.0.1`
- `docs`, `maintenance`, and `refactor` do not bump by default unless the user explicitly wants a release

When intent is mixed, prefer the user’s stated release intent. If they ask to release a bugfix bundle, use a patch bump.

## Required Files

Every release bump must update these files together:

- `/home/ray/dev/linkong/planet/VERSION`
- `/home/ray/dev/linkong/planet/frontend/package.json`
- `/home/ray/dev/linkong/planet/pyproject.toml`
- `/home/ray/dev/linkong/planet/uv.lock`
- `/home/ray/dev/linkong/planet/docs/CHANGELOG.md`
- `/home/ray/dev/linkong/planet/docs/version-history.md`

## Workflow

1. Inspect the current worktree and current version.
2. Decide the release type from the user request:
   - feature
   - bugfix
   - release without code changes
3. Compute the next version.
4. Update all required version-bearing files.
5. Add a concise but specific changelog entry:
   - highlights
   - important added/improved/fixed items
   - mention the highest-signal files only
6. Update `docs/version-history.md`:
   - current dev version
   - new timeline row with summary
7. Run the smallest relevant validation available.
8. Before commit, verify the target version is present in all required files.
9. If the user asked for commit/push:
   - stage the release files and code changes
   - commit with a conventional message
   - push to the requested branch, usually `dev`

## Validation Guidance

- Prefer scope-matched validation over broad expensive checks
- Typical examples:
  - Python backend edits: `python3 -m py_compile ...`
  - Frontend edits: use the project-standard frontend build/check if available
- If the environment prevents a check, say that explicitly in the final summary

## Release Checklist

Before closing the task, confirm:

- version bump applied consistently
- changelog updated
- version history updated
- generated/runtime artifacts are not accidentally staged
- validation status recorded
- commit and push completed if requested