従来のコミットチェンジログビルダースキル

--- name: conventional-commits-changelog-builder description: Conventional Commits形式のgitログを、貼り付け可能なKeep a Changelogリリースセクション（Added、Changed、Deprecated、Removed、Fixed、Security）に変換します。スコープ、Issue・コミットリンク、破壊的変更ブロックを含みます。移行ノートのない破壊的変更、非準拠コミット、fixupコミット、リバート、重複をフラグ付けし、次のSemVerバージョンを提案します。オフラインのstdlib Pythonビルダーと--self-testを含みます。 --- # Conventional Commits Changelog Builder あなたはメンテナが最後のタグ以降のコミットを、実際に読めるチェンジログエントリに変換するのを支援します。手作業で書くということは、ログをスクロールし、どのコミットが重要かを推測し、フッターに隠れた破壊的変更を忘れることを意味します。盲目的に生成すると、すべてのタイプミス、WIPコミット、リバートされた機能がリリースにコピーされます。あなたはコミットを解析し、Keep a Changelogセクションにマッピングし、何が除外されたかとその理由を正確にリストアップし、リリースがどのバージョンになるべきかを示します。 ## このスキルのファイル - `scripts/changelog_build.py` - `git log`（デフォルト形式）、`git log --oneline`、または`%x1f`/`%x1e`レコードエクスポートを読み取ります。`type(scope)!: description`ヘッダーと`BREAKING CHANGE:`フッターを解析し、BREAKING CHANGESブロック付きのAdded / Changed / Deprecated / Removed / Fixed / Securityにグループ化します。範囲内のリバートをキャンセルし、マージをスキップし、重複を削除し、fixup/WIPおよび非準拠コミットを提案ヘッダー付きでフラグ付けします。Issue、コミット、比較範囲にリンクし、SemVerバンプ（0.x対応）を提案します。既存のCHANGELOG.mdにセクションを挿入できます（Python 3.8+標準ライブラリのみ） - `references/commit-to-changelog-mapping.md` - タイプからセクションへのテーブル、破壊的変更ルール、バンプルール、および検出コードCC01-CC10 - `references/release-hygiene.md` - ユーザー向けエントリの書き方、移行ノート、非準拠履歴への対処法、CIチェック - `templates/release-notes-review.md` - セクションと一緒に返すレビュー - `examples/git-log.txt` - v2.3.1以降の架空のCLI（tidyq）の21コミット：2つの破壊的変更、セキュリティ修正、非推奨、リバート、重複チェリーピック、fixup、WIP、およびプレーンな「Fixed ...」コミット - `examples/CHANGELOG.md` - プロジェクトの既存チェンジログ（Unreleased + 2.3.1 + 2.3.0） - `examples/changelog-report.md` - そのログに対する実際のビルダー出力 ## ワークフロー ### 1. コミット範囲を取得する 最後にリリースされたタグを尋ね、それ以降のすべてを新しい順にエクスポートします： ``` git log v2.3.1..HEAD > commits.txt git log v2.3.1..HEAD --format='%H%x1f%s%x1f%b%x1e' > commits.txt # 最も安全：ボディを保持し、解析の推測を回避 ``` また、現在のバージョン、リリース日、リポジトリURL（リンク用）、タグプレフィックス（デフォルトは`v`）、および内部コミット（refactor、docs、ci、chore、test）をリストアップするかどうかを尋ねます。スカッシュマージワークフローが理想的です：1 PR = 1コミット = 1行。 ### 2. ビルダーを実行する ``` python3 scripts/changelog_build.py examples/git-log.txt --current 2.3.1 --date 2026-11-03 --repo-url https://github.com/tidyq/tidyq python3 scripts/changelog_build.py commits.txt --current 2.3.1 --insert CHANGELOG.md > CHANGELOG.new.md python3 scripts/changelog_build.py commits.txt --current 0.9.4 --include-internal --json python3 scripts/changelog_build.py --self-test ``` 終了コード0 = タグ付け準備完了、1 = 高優先度の検出、2 = 不正な入力。シェルがない場合は、`references/commit-to-changelog-mapping.md`を手動で適用します：各ヘッダーを解析し、タイプをセクションにマッピングし、`!`と`BREAKING CHANGE:`フッターを収集し、リバートをキャンセルし、最高のバンプを選択します。 ### 3. タグ付け前に検出を修正する - CC03（高）：`!`コミットに`BREAKING CHANGE:`フッターがない場合、ユーザーに移行パスがありません。ノート（何が壊れるか、代わりに何をすべきか）をセクションに書きます。 - CC08（高）：機能や修正のように見える非準拠コミットがチェンジログにありません。提案されたヘッダーで手動で追加し、コミットlintチェックを有効にします。 - CC07：fixup/WIPコミットはリリース前にスカッシュする必要があります。CC04：古いリリースのリバートには理由を説明する文が必要です。 - CC01/CC02/CC05/CC06：文言と準拠性。公開済み履歴を書き換えるのではなく、チェンジログテキストで修正します。 ### 4. 人間向けに編集する ビルダーは正しい構造を提供しますが、良い散文は提供しません。エントリをユーザーに見える効果として書き直し（「リファクタリングライター」ではなく「エクスポートはデフォルトでParquetを書き込む」）、1つの変更を説明するエントリを統合し、ユーザーが認識するスコープを維持し、BREAKING CHANGESブロックを誰も見逃せない場所に置きます。`references/release-hygiene.md`を参照してください。 ### 5. 納品する `templates/release-notes-review.md`を記入します：バージョンとその理由、最終セクション、移行ノート、除外されたもの、およびフォローアップ（commitlint、PRタイトルチェック）。`--insert`を使用した場合は、更新されたCHANGELOG.mdを返します。元のファイルは決して変更されません。 ## 結果の例 `examples/git-log.txt`（現在2.3.1）では、ビルダーは21コミットを読み取り、85%が準拠し、**3.0.0**を提案します：`feat(export)!`はParquetをデフォルトにし（適切なBREAKING CHANGEフッター付き）、`fix(config)!`は移行ノートなしでINI設定ファイルを削除します（CC03、高）。「設定ファイルが空のときのクラッシュを修正」はConventional Commitではなく、チェンジログに静かに欠落します（CC08、高。提案：`fix: 設定ファイルが空のときのクラッシュ`）。トークン漏洩修正はSecurityの下に置かれ、`--legacy-dates`の非推奨はDeprecatedの下に置かれ、カラーテーマ機能とそのリバートは相殺され、チェリーピックされたBOM修正は1回リストされ、マージ、fixup、WIP、および5つの内部コミットは除外としてリストされます。 ## ルール - エントリを決して発明しないでください：すべての行はコミットから来ており、すべてのコミットはセクションまたは「除外」リストのいずれかにあります。 - 破壊的変更には常に移行ノートとメジャーバンプ（0.xの間はマイナー）が必要です。決してChangedに隠さないでください。 - セキュリティ修正は、コミットタイプが`fix`であってもSecurityの下に置かれます。 - コミットメッセージを修正するために公開済み履歴を書き換えないでください。チェンジログテキストを修正し、将来のためにlintチェックを追加します。 - 最新のリリースを一番上に保ち、日付はYYYY-MM-DD形式、各バージョンに1つの比較リンクを置きます。 - バージョンは提案です：メンテナが決定します。特に`fix`として型指定された動作変更の場合。