ynitto commit-pr-writer
変更内容を解析し、規約に沿った コミットメッセージ / PR 説明文 / CHANGELOG・リリースノート / semver 判定 を生成する。
原則
- diff を根拠にする — 推測でメッセージを書かない。実際の変更（diff・コミット履歴）に基づく
- 規約に従う — リポジトリに既存の規約（直近のコミット履歴・CONTRIBUTING・PR テンプレート）があればそれを最優先で踏襲する。無ければ Conventional Commits をデフォルトとする
- why を一行入れる — what（何を変えたか）は diff から読めるので、本文には why（なぜ変えたか）を残す
- コミット・プッシュは勝手にしない — メッセージ生成が役割。
git commit/git push/ PR 作成は、ユーザーが明示的に依頼した場合のみ実行する
モード判定
依頼内容から以下のいずれかを選ぶ（複数該当時はユーザーに確認）。
| モード | 発動する依頼 | 入力 |
|---|---|---|
commit |
コミットメッセージ生成 | git diff --staged（無ければ git diff） |
pr |
PR タイトル・説明文生成 | ベースブランチとの差分・コミット履歴 |
changelog |
CHANGELOG / リリースノート生成 | 直近タグ以降のコミット履歴 |
version |
semver バージョン判定 | 直近タグ以降のコミット履歴 |
commit モード
Step 1: 対象の差分を取得する
git diff --staged --statでステージ済みの変更を確認する- ステージ済みが空なら
git diff --statを見て、対象をユーザーに確認する（「全部ステージしてからでよいか」等） - 規約把握のため
git log --oneline -10で直近コミットのスタイル（prefix の有無・言語・粒度）を確認する
Step 2: 論理単位に分割すべきか判断する
- 1 つの関心事（1 つの fix / feat / refactor）に収まる → 単一コミット
- 無関係な複数の変更が混在している → コミット分割を提案し、
git add -p相当の分割案（ファイル/ハンク単位）を提示する。分割実行はユーザー承認後
Step 3: メッセージを生成する
Conventional Commits 形式（規約詳細は references/conventions.md）:
<type>(<scope>): <subject>
<body: なぜこの変更が必要だったか>
<footer: BREAKING CHANGE / 課題番号など>
type: feat / fix / docs / style / refactor / perf / test / build / ci / chore / revertsubject: 命令形・50文字程度・末尾ピリオドなしbody: 72文字で折り返し。what より why を書く（任意だが推奨）- 破壊的変更があれば
BREAKING CHANGE:フッターまたはtype!を必ず付ける
Step 4: 提示する
生成したメッセージをコードブロックで提示する。ユーザーが「コミットして」と言った場合のみ:
git commit -m "<subject>" -m "<body>"
を実行する。リポジトリ固有のフッター規約（署名・課題リンク等）があれば踏襲する。
pr モード
Step 1: 差分とコミットを集める
- ベースブランチを特定する（指定が無ければ
git remote show originの HEAD、またはmain/master/developを推定） git log --oneline <base>..HEADでコミット一覧、git diff <base>...HEAD --statで変更範囲を確認する- リポジトリに PR テンプレート（
.github/PULL_REQUEST_TEMPLATE.md）があれば、その節構成に合わせる
Step 2: タイトルと本文を生成する
- タイトル: Conventional Commits 形式 1 行（複数 type が混在するなら主目的の type を採用）
- 本文: テンプレートが無ければ下記の既定構成を使う
## 概要
<この PR が何を解決するか / 背景・why を 2〜4 行>
## 変更点
- <主要な変更を箇条書き（ファイル名ではなく挙動・意図ベース）>
## テスト
- [ ] <どう検証したか / 追加したテスト>
## 影響範囲・注意点
- <破壊的変更・マイグレーション・ロールバック手順など。無ければ「なし」>
## 関連
- <Issue / チケット番号>
Step 3: 提示する
本文を提示する。ユーザーが「PR を作って」と言った場合のみ作成に進む（gh pr create または GitHub MCP ツール。利用可能な手段を確認してから実行）。
changelog モード
Step 1: 範囲を決める
git describe --tags --abbrev=0で直近タグを取得（無ければ全履歴）git log <last-tag>..HEAD --pretty=format:"%s (%h)"でコミット件名を集める
Step 2: 分類して整形する
Keep a Changelog 形式。Conventional Commits の type からセクションへマッピング（詳細は references/conventions.md）:
## [x.y.z] - YYYY-MM-DD
### Added ← feat
### Changed ← refactor / perf / 既存挙動の変更
### Fixed ← fix
### Removed ← 機能削除
### Security ← 脆弱性修正
### Breaking ← BREAKING CHANGE
- ユーザー向けに意味のある変更のみ載せる（
chore/ci/styleや内部リファクタは原則除外、または末尾にまとめる） - 各行は利用者目線の表現に言い換える（コミット件名のコピペにしない）
version モード
直近タグ以降のコミットから次バージョンを判定する（semver: MAJOR.MINOR.PATCH）。
| 含まれる変更 | bump |
|---|---|
BREAKING CHANGE / type! あり |
MAJOR（0.x系は MINOR に倒す選択肢も提示） |
feat あり（破壊的変更なし） |
MINOR |
fix / perf のみ |
PATCH |
docs/chore/ci のみ |
bump 不要（必要なら PATCH を提案） |
判定結果は「現行 vX.Y.Z → 推奨 vX'.Y'.Z'」と根拠（どのコミットが MAJOR/MINOR を引き起こすか）をセットで提示する。
ガードレール
| 制限 | 内容 |
|---|---|
| 自動コミット/プッシュ | 禁止。ユーザーの明示依頼時のみ実行 |
| 規約の優先順位 | リポジトリ既存規約 > Conventional Commits（既定） |
| 事実性 | diff・コミット履歴に無い内容を書かない。不明点は確認する |
| 機密 | diff 内のシークレットらしき値を本文・メッセージに転記しない |