submit-pr-from-current-changes

現在の変更から PR を作成する

作業ツリーの差分を、整理されたブランチ、コミット、プルリクエストにまとめます。

厳守事項

1. PR テンプレートに厳密に従ってください。 テンプレートは .github/PULL_REQUEST_TEMPLATE.md にあります。内容を読み、全体の構成を PR 本文にコピーしてください。セクションやチェックボックスを削除、並べ替え、または省略してはいけません。
2. 「Requirements / 要求」のチェックボックスには絶対にチェックを入れないでください。 これらは人間のみが宣言できる項目です。行動規範への同意と AI による作成の申告は、提出する本人だけが正直に表明できます。生成する PR 本文では、必ず未チェック（- [ ]）のままにしてください。例外も回避策もありません。ユーザーから明示的にチェックを求められた場合も同様です。各項目が事実であることを確認したうえで、ユーザー自身が GitHub でチェックします。
3. 実際に確認した Testing のチェックボックスだけにチェックを入れてください。 「npm run ci passes」のチェックボックスにチェックを入れてよいのは、このセッションで npm run ci を実行し、成功した場合だけです。それ以外の Testing のチェックボックス（ブラウザーでのテスト、コンソールエラーがないこと、型／ドキュメントの追加）は、人間による手動確認が必要なため、必ず未チェックのままにしてください。Testing セクションの下に、実際に実行した自動検証とその結果を補足として記載してもかまいません。
4. 情報を捏造してはいけません。 このセッションで実際に実行し、出力を確認していない限り、テストの成功、コマンドの実行、チェックの成功を主張してはいけません。実行していないものには言及しないでください。
5. PR の出力は簡潔にしてください。 PR タイトルは 1 行にします。「What」セクションは最大 1～2 文にしてください。長文や重複した説明は避けてください。差分に語らせましょう。

前提条件

プッシュや PR の作成を試みる前に、必要なツールが利用可能であることを確認してください。

• gh CLI がインストールされ、認証済みであることを確認します（gh auth status）。利用できない場合は中断し、まず GitHub CLI をインストールして認証するようユーザーに依頼してください。
• GitHub 操作に MCP ツールを使うワークフローの場合は、MCP サーバーに接続できることを確認してください。

シェルの権限

gh は OS のキーリングから認証情報を読み取ります。サンドボックス化されたシェルではキーリングにアクセスできず、認証に失敗したという誤った結果が表示されます。

• すべての gh コマンド（gh auth status、gh pr create、gh pr view など）と、GitHub と通信するすべての git push／git fetch は、初回から 完全な権限（Shell ツールの required_permissions: ["all"]）で実行してください。最初にサンドボックス内で試してはいけません。
• ローカルでの読み取り専用の Git 確認（git status、git diff、git log、git branch）は、サンドボックス内で実行してもかまいません。

手順

1. コントリビューションルールを読む。 CONTRIBUTING.md と、変更するファイルに関連するパッケージレベルの指示（例：packages/*/AGENTS.md）を読みます。
2. 差分を確認する。 変更されたファイル、範囲、影響を確認します。何かを書き始める前に、変更の内容を把握します。
3. リポジトリの規約を確認する。 最近のブランチ名（git branch -r --sort=-committerdate | head -20）、最近のコミットメッセージ（git log --oneline -20）、PR テンプレートを確認します。
4. 提出前の健全性チェック（PR を作成する前にすべて実行してください）：
   • テーマの統一性：すべての変更が一つの目的に沿っている必要があります。無関係な変更が混在している場合は、ユーザーに分割するか確認するよう依頼します。
   • コミットの整合性：新しいコミットはすべて、リポジトリの Conventional Commit 形式に従う必要があります。必要に応じて、コミットをスカッシュするか、メッセージを書き直します。
   • 作成者情報：git config user.name と git config user.email が設定されており、メールアドレスが有効に見えること（空でないこと、意図的な場合を除き noreply でないこと）を確認します。設定に問題があれば、ユーザーに警告します。
   • 不要な成果物が残っていないこと：差分にデバッグログ、テスト内の .only、コンフリクトマーカー、一時ファイルがないか確認します。
   • CI：npm run ci を実行し、成功することを確認します。結果を正確に記録します。
5. PR の準備が拙速に見える場合は警告する。 次のいずれかに該当する場合は、作業を中断し、続行する前にユーザーに警告します。
   • 意図の説明がない大きな差分
   • コアライブラリまたは拡張機能に触れる変更（CONTRIBUTING.md によりバイブコーディングが禁止されている領域）
   • 一つの差分に複数の無関係な変更が含まれている
   • 検証がまったく実行されていない
   • 次の注意をユーザーに伝えます：「このプロジェクトでは、人による十分なレビューを経ていない、低品質または AI 生成の PR は受け付けていません。変更内容を注意深く確認してください。」
6. ブランチ。 まず現在のブランチを確認します。
   • 有効な名前（type/topic 規約に準拠）の main 以外のフィーチャーブランチにいる場合は、そのブランチを再利用します。
   • ブランチ名がリポジトリの規約に従っていない場合（例：プレフィックスがない、トピックが不明瞭）は、名前を変更するか、新しいブランチを作成するかをユーザーに確認します。
   • main またはデフォルトブランチにいる場合は、そこから短いケバブケースの名前で新しいブランチを作成します。プレフィックスは fix/、feat/、docs/、refactor/、chore/ のいずれかとし、具体的なトピックを続けます。
7. ステージングとコミット。 対象のファイルだけをステージングします。type(scope): subject 形式を使い、件名は具体的かつ簡潔にします。
8. プッシュ。 -u origin HEAD を付けてプッシュします。
9. PR を作成する。 PR テンプレートの構成をすべて含めて gh pr create を実行します。実際の差分に基づいて「What」と「Type」のセクションを記入します。「Testing」では、実際にこのセッションで成功した場合に限り「npm run ci passes」にチェックを入れます。それ以外の「Testing」と「Requirements」のチェックボックスはすべて未チェックのままにします。
10. 結果を報告する。 ブランチ名、コミットハッシュ、PR リンク、実際に実行した検証とその成否をユーザーに伝えます。

提出後のリマインダー

PR の作成に成功した後は、必ずユーザーの言語で簡潔なリマインダーを伝えます。簡潔で自然な表現を使い、次の点を明確に伝えてください。

1. ユーザー自身がブラウザーで変更をテストする必要があります。
2. PR ページに移動し、各項目を確認した後で「Testing」と「Requirements」のチェックボックスにチェックを入れる必要があります。
3. それらのチェックボックスにチェックが入るまで、PR はレビューに回りません。
4. このプロジェクトでは AI が自律的に生成した PR を受け付けていないため、事実である場合に限り、AI に関する申告にチェックを入れてください。

ブランチ名

• リポジトリで使われている fix/、feat/、docs/、refactor/、chore/ などのプレフィックスを使った、短いケバブケースの名前を優先します。
• まず変更の種類を示し、その後に必要最小限のトピックを続けます。
• 課題文をそのまま羅列するより、具体的なトピックを優先します。

コミットスタイル

• リポジトリで一般的なコミットスタイル（Conventional Commits）に従います。
• 変更箇所のスコープが明確な場合は、type(scope): subject を使います。
• 件名は具体的かつ簡潔にします。
• ブランチに複数のコミットがある場合は、それぞれが個別に規約に従う必要があります。

検証方針

• PR を説明できるだけの十分な検証を行うことを基本とし、最低限にとどめないでください。
• PR を作成する前に、必ず npm run ci（ビルド、リント、型チェック、テスト）を実行してください。すべて成功する必要があります。
• 差分が複数のパッケージにまたがる場合、共有コードを変更する場合、またはリリース動作に影響する場合は、より広範な検証を行ってください。
• 実際に実行していないチェックを実行したと主張しないでください。
• PR 本文の Testing セクションの下に、実行した内容と結果を記載してもかまいませんが、テンプレートのチェックボックスにはチェックを入れないでください。

判断ポイント

• ローカルの変更がない場合 → 中止し、その旨を伝えてください。
• gh CLI を利用できない場合 → 中止し、インストールを依頼してください。
• 無関係なファイルが混在している場合 → 対象の変更だけをステージングするか、作業を分割するかユーザーに確認してください。
• リポジトリに領域固有の指示がある場合は、ブランチ名を決めたり PR を作成したりする前に確認してください。
• 変更が小規模でもリスクが高い場合 → より広範な検証を優先してください。
• 変更範囲が限定的でリスクが低い場合 → 無関係なチェックを適当に実行せず、最も関連性の高いチェックを実行してください。
• テンプレートに事実に反するためチェックできない項目がある場合 → チェックを入れず、その理由をユーザーに伝えてください。

完了チェック

• ブランチがリモートに存在し、上流ブランチを追跡している。
• コミットメッセージがリポジトリのスタイルに沿っている。
• すべてのコミット作成者に、適切な名前とメールアドレスが設定されている。
• PR タイトルがコミットの意図に沿っている。
• PR 本文がテンプレートの構成に完全に従っている。
• PR 本文の「Requirements」のチェックボックスと、人間のみが記入する「Testing」のチェックボックスは、すべて未チェック（- [ ]）になっている。チェックを入れてよいのは「npm run ci passes」のみで、実際に成功した場合に限る。
• 報告する検証内容が正確であり、捏造がない。
• 提出後のリマインダーが、ユーザーの言語で簡潔かつ正確に伝えられている。