GitHub PR Workflow

• ローカルの変更をリリース準備完了の状態にして、ブランチの作成、コミットのステージング、そして構造化された説明を含むPRのオープンを一連のフローで行いたい。
• オープン中のPRに対するCIチェックの実行を監視し、GitHub UIを見続けることなく、失敗したログを自動的に表示させたい。
• 自動修正ループを実現したい：失敗したlintまたはテストのチェックを検出し、修正を適用してプッシュし、すべてのチェックがグリーンになるまど再ポーリングする。
• マージの準備が整い、特定のマージ戦略（squash、rebase、またはマージコミット）を適用して、その後ソースブランチを削除したい。

• gitリモートとしてGitHubを使用するgitリポジトリで作業していない場合 — このスキルは全体を通してそのセットアップを前提としています。
• gh CLIが認証されていないか、GitHub PATが利用できない場合；そのいずれかがなければ、APIコールは失敗します。
• GitLab、Bitbucket、またはその他の非GitHubリモートを管理する必要がある場合 — このスキルはGitHub専用です。

規則に沿った名前のスラグを持つフィーチャーブランチを自動的に作成し、生成されたコミットメッセージとともに変更をステージングします。手動でメッセージを記述することなく、コミット履歴をクリーンに保ちます。

ブランチをoriginにプッシュし、組み込みの説明テンプレート（references/pr-template.md）を使用してプルリクエストを作成します。同じステップでレビュアーのリクエスト、ラベルの割り当て、およびissueのリンクをサポートします。

scripts/watch_ci.sh を通じてGitHubのチェック実行をポーリングし、失敗したチェックのログをセッションに直接出力します。エラーを見つけるためにActions UIをクリックして回る必要はもうありません。

チェックが失敗した場合、スキルは修正を適用して新しいコミットをプッシュし、チェックを再ポーリングすることができます。これを、必須チェックがすべて通過するまで繰り返します。リントやフォーマットの失敗に対処する際に、何度もプッシュし直す手間を省くことができます。

スカッシュマージ、リベースマージ、および標準的なマージコミットをサポートしています。マージ後は、リモートをきれいに保つためにソースブランチを削除します。

認証済みの場合、gh CLIをプライマリドライバーとして使用します。gh が利用できない場合は、references/api-fallback.md およびcurlベースのスクリプトが $GITHUB_TOKEN を使用してGitHub REST APIに対するすべての操作を処理します。

あるデベロッパーがローカルの変更を加えた状態で、次のように依頼します：「『/api/search にレート制限を追加』というタイトルで、main をターゲットにした PR を開いて。」 このスキルはブランチを作成し、コミットをステージングしてプッシュし、説明文付きで PR を開きます — 手動で git コマンドを実行する必要はありません。

PRを開いた後、開発者は次のように依頼します：「PRのチェックを監視して、Lintが失敗したら修正して再度プッシュして。」 このスキルはチェックの実行状況をポーリングし、Lintの失敗を検出して修正を適用し、プッシュした後、テストスイートが全て通るまで再チェックを繰り返します。

レビューが承認されると、開発者はこう依頼します：「PR #142をスカッシュマージして、ブランチを削除してください。」 GitHub PR Workflowはスカッシュマージを実行し、リモートブランチを1つのアクションで削除します。

ある開発者がこう質問します：「私のブランチをレビューしてください — どのチェックが失敗していて、誰がまだ承認していませんか？」 このスキルは、GitHub APIから現在のCIステータスと未対応のレビュアー承認状況を取得して表示します。