一键导入
smaqitrelease-prepare-files
Validate git state and prepare all files (CHANGELOG.md, version files) for release
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Validate git state and prepare all files (CHANGELOG.md, version files) for release
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
Collect changes, assess severity, and suggest next version for a release
Execute git operations for PR-based releases (commit, push via report_progress)
End session by documenting the entire conversation. Use at session completion to create history entries.
Start a new chat with full project context. Use when beginning a session to load README, recent history, and task planning.
Generate a succinct title for the current session based on work accomplished. Use when finishing sessions to create history file titles.
Mark a task as completed with verification. Use when finishing tasks to update status and verify criteria.
基于 SOC 职业分类
| name | smaqit.release-prepare-files |
| description | Validate git state and prepare all files (CHANGELOG.md, version files) for release |
| metadata | {"version":"0.2.0"} |
Validate the repository state and prepare all necessary files for a release, including CHANGELOG.md and optional version files.
Use this skill after obtaining version approval and before executing git operations to:
A. Verify current branch:
git branch --show-current
main or user-specified release branchB. Check version doesn't exist in CHANGELOG.md:
grep "## \\[X.Y.Z\\]" CHANGELOG.md
grep "## \\[0.3.0\\]" CHANGELOG.md)Note: Uncommitted changes are acceptable - they will be handled during git operations step.
A. Move Unreleased content to new version section:
Find the ## [Unreleased] section and move its content to a new version section with current date (YYYY-MM-DD):
## [Unreleased]
(empty or minimal content)
## [X.Y.Z] - YYYY-MM-DD
### Added
- Feature X
### Fixed
- Bug Y
B. Update comparison links at bottom of CHANGELOG.md:
Update the link structure:
[Unreleased]: https://github.com/owner/repo/compare/vX.Y.Z...HEAD
[X.Y.Z]: https://github.com/owner/repo/releases/tag/vX.Y.Z
[Previous]: https://github.com/owner/repo/releases/tag/vPrevious
C. If creating CHANGELOG.md from scratch:
Use Keep a Changelog format:
# Changelog
All notable changes to this project will be documented in this file.
The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
## [Unreleased]
## [X.Y.Z] - YYYY-MM-DD
### Added
- Initial release
[Unreleased]: https://github.com/owner/repo/compare/vX.Y.Z...HEAD
[X.Y.Z]: https://github.com/owner/repo/releases/tag/vX.Y.Z
A. Ask user for version files:
Common version files by ecosystem:
package.jsonpyproject.toml, setup.py, __init__.pyCargo.tomlB. If repository has obvious version file:
C. If user confirms version files:
X.Y.Z, not vX.Y.Z)Example updates:
package.json:
{
"version": "0.3.0"
}
pyproject.toml:
[project]
version = "0.3.0"
D. If user declines or no version files exist:
Before completing:
Provide a summary of files prepared:
files_modified:
- CHANGELOG.md
- package.json
validation_passed: true
version_synced: true
Output fields:
files_modified: List of files changed during preparationvalidation_passed: Boolean indicating all validations passedversion_synced: Boolean indicating if version files were updated| Error | Suggested Action |
|---|---|
| Version already exists in CHANGELOG.md | Stop and report: "Version X.Y.Z already exists" |
| Not on main branch (local release) | Warn and request confirmation before proceeding |
| Version file has different format | Ask user how to update it (may need custom logic) |
| CHANGELOG.md doesn't exist | Create from scratch using Keep a Changelog template |
This skill modifies files but does NOT commit them (git operations are separate)
All file modifications are reversible with git checkout
Version files are optional - CHANGELOG.md is the only required file
Keep a Changelog format uses version WITHOUT 'v' prefix in headers (e.g., ## [0.3.0]), but git tags use 'v' prefix (e.g., v0.3.0)
For PR-based releases, validation rules are slightly relaxed (feature branch OK)
Uncommitted changes in working tree are acceptable - release-git-local handles commit grouping