planet/.codex/skills/release-workflow/SKILL.md

name, description

name	description
release-workflow	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