ワンクリックで
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 ページを確認してインストールできます。
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
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.