turntuptechnologies-ai リリース（release）
このスキルがやること
前回リリースからの変更を棚卸しし、バージョン決定 → バージョンファイル更新 → CHANGELOG → タグ → GitHub Release を漏れなく一貫して行う。
手順
前回リリースを特定する:
git describe --tags --abbrev=0。タグが無ければ初回リリースとして扱い、初期バージョン（v0.1.0かv1.0.0か）をユーザーに確認する。変更を収集する:
git log <last-tag>..HEAD --oneline。リリース対象の変更が無ければその旨を報告して終了する。バージョンを判定する（Conventional Commits から機械的に）:
前回タグ以降のコミット bump BREAKING CHANGE/<type>!:を含むmajor feat:を含む（BREAKING なし）minor fix:/ その他のみpatch 0.x系は breaking でも minor に留める慣習があるため、major 相当の変更がある場合はどちらにするかユーザーに確認する。
バージョンファイルを更新する: リポジトリ内の全バージョン記載箇所（
package.json/pyproject.toml/Cargo.toml/deno.json/.claude-plugin/plugin.json等、存在するもの）を grep で洗い出し、全て新バージョンで一致させる。CHANGELOG.md を更新する（無ければ Keep a Changelog 形式で新規作成）:
## [X.Y.Z] - YYYY-MM-DDの節に Added / Changed / Fixed で振り分け、PR/Issue 番号を添える。リリースする:
- リリースコミット
chore: release vX.Y.Zを作る。main が保護されていれば PR 経由でマージする（create-pr） - マージ後の main のコミットにタグ
vX.Y.Zを打って push する（git tag vX.Y.Z && git push origin vX.Y.Z） gh release create vX.Y.Z --title "vX.Y.Z" --notes "<CHANGELOG の該当節>"で GitHub Release を作成する
- リリースコミット
URL を報告する。
ルール・コツ
- タグは必ず merge 後の main のコミットに打つ（PR ブランチのコミットに打たない）。
- バージョンファイルとタグに既に不一致がある場合（タグだけ進んでいる等）は、勝手に整合させず現状を報告して方針を確認する。
- CHANGELOG には「利用者に見える変化」を書く。内部リファクタは Changed に 1 行で足りる。コミットログの丸写しをしない。
- CI にリリースワークフロー（tag push トリガーで publish 等）がある場合はそれに従い、手動 publish と二重にしない。ワークフローの有無を
.github/workflowsで確認する。 - リリース直前に main の CI が green であることを確認する（落ちていたら pr-babysit / 修正が先）。
完了条件
以下を全て満たしたら完了。満たせない項目があれば、黙って省略せず理由を報告する。
- バージョン判定の根拠（該当コミットと適用した semver 規則）を報告した
- リポジトリ内の全バージョン記載箇所を洗い出し、新バージョンで一致していることを確認した
- CHANGELOG に今回リリース分の節（日付・Added/Changed/Fixed）がある
- タグが main のリリースコミットに打たれ、push されている
- GitHub Release を作成し URL を報告した（作成できない場合は理由を報告）
補足
- 社名・内部 URL・認証情報などの固有情報は扱わない。
- パッケージレジストリへの publish（npm publish 等）はこのスキルの範囲外。必要ならユーザーに確認してから行う。