24 added, 83 removed. Audit A to A.
---
name: pr-generator
description: |
- 現在のgit状態を分析し、標準フォーマットに準拠したPRを自動生成する。
+ 明示的に `pr-generator` を呼び出した場合のみ使用する。
+ 現在のgit状態を分析し、簡潔なPRを自動生成する。
Linear統合なしのシンプルなPR作成コマンド。
disable-model-invocation: true
---
# PR Generation Command (without Linear Integration)
- 現在のgit状態を分析し、toridori標準フォーマットに準拠したPRを自動生成します。
+ 現在のgit状態を分析し、簡潔なPRを作成します。
## 実行手順
- 1. **Git状態の詳細分析**
+ 1. **Git状態の分析**
- `git status` で未コミットの変更を確認
- - `git diff main...HEAD` でmainブランチとの差分を確認
- - `git log main..HEAD --oneline` でコミット履歴を確認
- - 変更ファイルの分類と影響範囲の特定
+ - `git diff main...HEAD` と `git log main..HEAD --oneline` で差分とコミット履歴を確認
+ - **base ブランチを確認する**: feature 作業では initiative の release ブランチが base のことがある。無指定で main に向けない
- 現在のブランチ名を確認
- 2. **変更内容の構造化**
- - 変更をカテゴリー別に分類（コア実装、テスト、ドキュメント、インフラなど）
- - 各カテゴリーに適切な絵文字を付与
- - 変更の目的と影響を明確化
+ 2. **リポジトリの既存フォーマットに寄せる**
+ - `gh pr list --limit 5` で直近のマージ済みPRを見て、タイトル・本文のセクション構成と粒度を踏襲する
+ - 既存フォーマットが見つからない場合のみ下記の既定フォーマットを使う
3. **PR作成の実行**
- **タイトルフォーマット**:
- ```
- {変更の本質を表す日本語タイトル}
- ```
- 例: `Cookie認証への移行 - Articles API`
+ **既定フォーマット**（What / How / Test を各2〜3項目に絞る。長い説明はレビュアーの負担）:
- **説明文フォーマット**:
```markdown
- ## 📋 概要
- [変更の目的と背景を簡潔に記述]
-
- ## 🔧 主な変更内容
-
- ### [カテゴリー名]
- - **[機能名]**: [詳細説明]
- - [サブ項目があれば箇条書き]
- - **[別の機能]**: [詳細説明]
-
- ### [別のカテゴリー]
- - **[機能名]**: [詳細説明]
-
- ## 🗂️ 変更ファイル
- - **[グループ名]**: `file1.rb`, `file2.rb`
- - **[別グループ]**: `file3.md`, `file4.yml`
+ ## What
+ [何を変えたか、2-3項目]
- ## 🧪 テスト
+ ## How
+ [どう実現したか、2-3項目]
- ### テスト実行方法
- ```bash
- # テスト実行
- docker compose exec app bundle exec rspec spec/requests/api/articles_spec.rb
+ ## Test
+ [実行した検証と結果、2-3項目。再現可能なコマンドを含める]
```
- ### テスト結果
- - テスト件数: XX examples, 0 failures
- - カバレッジ: [必要に応じて記載]
-
- ### 検証項目
- - [x] [完了した検証項目]
- - [x] [別の検証項目]
- - [ ] [未完了の項目があれば]
-
- ## 📦 破壊的変更
- [ありorなし - 詳細があれば記載]
-
- ## 🔄 移行手順
- [必要な場合のみ記載]
-
- ## 関連Issue
- [関連するIssue番号があれば記載]
- 例: Closes #90, Fixes #123
-
- 🤖 Generated with [Claude Code](https://claude.com/claude-code)
-
- Co-Authored-By: Claude <noreply@anthropic.com>
- ```
+ 関連Issueがあれば `Closes #XX` を添える。破壊的変更・移行手順は該当する場合のみ節を足す。
4. **フォローアップ**
- 作成されたPR URLの提供
- CI/CDステータスの確認
- ## カテゴリー別の絵文字ガイド
-
- - 📋 概要・サマリー
- - 🔧 実装・機能追加
- - 🐳 Docker/コンテナ関連
- - 📝 ドキュメント更新
- - 🧪 テスト関連
- - 📦 パッケージ・ビルド
- - 🔄 破壊的変更・移行
- - ⚙️ 設定・環境
- - 🚀 デプロイ・CI/CD
- - 🐛 バグ修正
- - ♻️ リファクタリング
- - 🗂️ ファイル一覧
-
- ## 注意事項
+ ## ルール
+ - **AI署名・絵文字・定型フッターを入れない。** `Generated with Claude Code` や `Co-Authored-By: Claude` は外部に残る文面なので禁止（ユーザーの反復指示）
+ - **言語**: toridori 系リポジトリは日本語。`github.com/sorafujitani/*` や `fs0414/*` などOSS・公開個人リポは英語で書く
+ - **ブランチ名は英数字とハイフンのみ。** 日本語入りブランチ名は GitHub の Hidden character warning を出し、rename すると旧PRが閉じられる副作用がある
+ - 目的外の差分（他アプリの変更・再生成された lock ファイル・未追跡の生成物）が混入していないか push 前に確認する
- コミットされていない重要な変更がある場合は先にコミットを促す
- - テスト手順は実際に実行可能なコマンドを提供
- - 破壊的変更がある場合は明確に記載
- - 日本語と英語の使い分け：タイトルと説明は日本語、コード・コマンドは英語
- - 関連Issueがある場合は必ず記載（Closes #XX, Fixes #XX など）
## 成功基準
- - 変更内容が構造化され理解しやすい
+ - レビュアーが1画面で変更の意図と検証内容を把握できる
- テスト手順が再現可能
- - レビュアーが変更の影響を把握できる
- - 関連Issueとの紐付けが明確（該当する場合）
+ - 既存PRと並べて違和感がない