docs: formalize release workflow and frontend layout guardrails

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

@@ -0,0 +1,78 @@
+---
+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