prgen-linear

name	pr:gen-linear
description	Linear統合されたプルリクエスト作成。現在のgit状態とLinear issueを分析し、 標準フォーマットに準拠したPRを自動生成する。ブランチ名からLinear issue IDを抽出し紐付ける。
disable-model-invocation	true

PR Generation Command for Linear Integration

あなたはLinear統合されたプルリクエスト作成のエキスパートです。現在のgit状態とLinear issueを分析し、toridori標準フォーマットに準拠したPRを自動生成します。

実行手順

1. Linear Issue情報の特定

   • 現在のブランチ名から Linear issue ID を抽出（例: fujitani/BPO-1984 → BPO-1984）
   • Linear issue URLを構築: https://linear.app/toridori/issue/{ISSUE_ID}/{推定されるslug}
   • ブランチ名や変更内容からissue titleを推定

2. Git状態の詳細分析（push済みのコミットのみを対象）

   • git log --oneline -10 で最近のコミット履歴を確認
   • git diff origin/main...HEAD でmainブランチからの変更内容を確認
   • 変更ファイルの分類と影響範囲の特定
   • 注: 未コミット・未追跡ファイルは無視する

3. 変更内容の構造化

   • 変更をカテゴリー別に分類（コア実装、テスト、ドキュメント、インフラなど）
   • 各カテゴリーに適切な絵文字を付与
   • 変更の目的と影響を明確化

4. PR作成の実行（gh pr createコマンドを使用、push済みの状態から作成）

   タイトルフォーマット:

   {LINEAR_ID}: {変更の本質を表す日本語タイトル}
   

   説明文フォーマット:

   {Linear issue URL}
   
   ## 📋 概要
   [変更の目的と背景を簡潔に記述]
   
   ## 🔧 主な変更内容
   
   ### [カテゴリー名]
   - **[機能名]**: [詳細説明]
     - [サブ項目があれば箇条書き]
   - **[別の機能]**: [詳細説明]
   
   ### [別のカテゴリー]
   - **[機能名]**: [詳細説明]
   
   ## 🗂️ 変更ファイル
   - **[グループ名]**: `file1.ts`, `file2.ts`
   - **[別グループ]**: `file3.md`, `file4.yml`
   
   ## 🧪 テスト手順
   
   ### テスト実行方法
   ```bash
   # 環境設定
   [セットアップコマンド]
   
   # テスト実行
   [テストコマンド]
   

   検証項目

   • [完了した検証項目]
   • [別の検証項目]
   • [未完了の項目があれば]

   📦 破壊的変更

   [ありorなし - 詳細があれば記載]

   🔄 移行手順

   [必要な場合のみ記載]

   🤖 Generated with Claude Code

   Co-Authored-By: Claude [e-mail]

5. フォローアップ

   • 作成されたPR URLの提供
   • レビュアーの自動アサイン（可能な場合）
   • CI/CDステータスの確認

カテゴリー別の絵文字ガイド

• 📋 概要・サマリー
• 🔧 実装・機能追加
• 🐳 Docker/コンテナ関連
• 📝 ドキュメント更新
• 🧪 テスト関連
• 📦 パッケージ・ビルド
• 🔄 破壊的変更・移行
• ⚙️ 設定・環境
• 🚀 デプロイ・CI/CD
• 🐛 バグ修正
• ♻️ リファクタリング
• 🗂️ ファイル一覧

注意事項

• 重要: git add, commit, pushは一切行わない（既にpush済みの状態からPRを作成）
• 重要: 未追跡ファイルは一切意識しない（無視する）
• Linear issue IDが特定できない場合はユーザーに確認
• PR作成はpush済みのコミットのみを対象とする
• テスト手順は実際に実行可能なコマンドを提供
• 破壊的変更がある場合は明確に記載
• 日本語と英語の使い分け：タイトルと説明は日本語、コード・コマンドは英語

成功基準

• Linear issueとの紐付けが明確
• 変更内容が構造化され理解しやすい
• テスト手順が再現可能
• レビュアーが変更の影響を把握できる