yeet

前提条件

• GitHub CLI gh が必要です。gh --version を確認してください。見つからない場合は、ユーザーに gh のインストールを依頼して終了してください。
• 認証済みの gh セッションが必要です。gh auth status を実行してください。認証されていない場合は、続行する前に gh auth login を実行し（その後、gh auth status を再実行するよう）ユーザーに依頼してください。

命名規則

• ブランチ：main/master/default から開始する場合は {description}。
• コミット：{description}（簡潔に）。
• PR タイトル：差分全体を要約した {description}。

PR テンプレートの検出

PR を作成する前に、リポジトリのルートを解決し、その場所から有効な GitHub PR テンプレートを探してください。

repo_root="$(git rev-parse --show-toplevel)"

テンプレート候補の優先順位：

• .github/pull_request_template.md
• .github/PULL_REQUEST_TEMPLATE.md
• .github/pull_request_template/ 内の *.md ファイル 1 つ
• .github/PULL_REQUEST_TEMPLATE/ 内の *.md ファイル 1 つ

パスは、./.github/pull_request_template.md ではなく、.github/pull_request_template.md のようにリポジトリのルートからの相対パスを使用してください。

テンプレートがちょうど 1 つ見つかった場合は、最終的な PR 本文を作成する前にそのテンプレートを読み、--template "$template" を指定して gh pr create に渡してください。

テンプレートファイルが複数見つかった場合は、PR を作成する前に停止し、どのテンプレートを使用するか確認してください。テンプレートが見つからない場合は、このスキルのフォールバック本文形式を使用してください。

ワークフロー

• main/master/default にいる場合は、ブランチを作成します：git checkout -b "{description}"
• それ以外の場合は、現在のブランチを使用します。
• 状態を確認してから、すべてをステージングします：git status -sb の後に git add -A。
• 説明を指定して簡潔にコミットします：git commit -m "{description}"
• チェックがまだ実行されていない場合は実行します。依存関係やツールの不足が原因でチェックに失敗した場合は、依存関係をインストールして一度だけ再実行します。
• トラッキングを設定してプッシュします：git push -u origin $(git branch --show-current)
• ワークフローの認証エラーが原因で git push に失敗した場合は、master からプルしてプッシュを再試行します。
• リポジトリの PR テンプレートがあれば検出して読み込みます。
• 現在のブランチにすでに PR があるか確認します：gh pr view "$(git branch --show-current)" --json number,isDraft,url
• すでに PR がある場合は、その PR を更新します。別の PR を作成したり、既存の PR がドラフトかレビュー可能かを変更したりしないでください。
• PR がない場合は、新しいドラフト PR を作成します：
  • テンプレートが 1 つある場合：GH_PROMPT_DISABLED=1 GIT_TERMINAL_PROMPT=0 gh pr create --draft --fill --template "$template" --head "$(git branch --show-current)"
  • テンプレートがない場合：GH_PROMPT_DISABLED=1 GIT_TERMINAL_PROMPT=0 gh pr create --draft --fill --head "$(git branch --show-current)"
• PR のタイトルと本文を、差分の実際の変更内容に合うよう編集します。
• PR の説明は実際の改行を含む一時ファイルに書き込み、\n でエスケープされた Markdown を避けるため、--body-file または gh pr edit --body-file で渡します。

PR の特定

このフローの前に作成された PR を更新する場合は、可能であれば現在のブランチから PR を特定します：

git branch --show-current
gh pr view "$(git branch --show-current)" --json number --jq '.number'

既存の PR が見つかった場合は、現在のレビュー状態を維持してください。yeet の一環として、レビュー可能な状態の既存 PR をドラフトに戻さないでください。このフローで新しく作成する PR のみ、ドラフトとして開始してください。

PR タイトル

形式：<type>(<scope>): <subject>

<scope> は省略可能です。コードベース内のセクション（コンポーネント、サービス、サブシステムなど）を表す名詞を指定します。

例

feat: add hat wobble
^--^  ^------------^
|     |
|     +-> Summary in present tense.
|
+-------> Type: chore, docs, feat, fix, refactor, style, or test.

その他の例：

• feat：（ビルドスクリプトではなく、ユーザー向けの新機能）
• fix：（ビルドスクリプトではなく、ユーザー向けのバグ修正）
• docs：（ドキュメントの変更）
• style：（フォーマットやセミコロンの不足など。本番コードの変更なし）
• refactor：（変数名の変更など、本番コードのリファクタリング）
• test：（不足しているテストの追加やテストのリファクタリング。本番コードの変更なし）
• chore：（grunt タスクの更新など。本番コードの変更なし）

PR 本文の内容

呼び出されたら、gh を使ってプルリクエストの本文とタイトルを編集し、指定された PR の内容を反映してください。既存のプルリクエスト本文を確認し、残すべき重要な情報がないか確かめてください。たとえば、既存のプルリクエスト本文にある画像は絶対に削除しないでください。削除すると、作成者が復元できない場合があります。

リポジトリに PR テンプレートがある場合は、最終的な PR 本文をそのテンプレートに合わせてください。意味のある見出し、必須のチェックリスト、リポジトリ固有の質問項目は残しつつ、プレースホルダーテキストを変更後の差分に即した内容、またはテンプレートで求められている場合は N/A に置き換えてください。以下の代替形式のほうが短いという理由だけで、テンプレートのセクションを削除しないでください。

変更を行う 理由 を説明することは、極めて重要です。このスキルが呼び出された会話で変更の動機が話し合われている場合は、必ずその内容をプルリクエスト本文に反映してください。

本文では変更点についても説明しますが、理由 の後に記載してください。

説明はコミットの 最終的な変更 に限定してください。プルリクエストの作成過程で試したものの、後で取り消した変更について触れることは、一般に好ましくありません。プルリクエスト本文を書き直す際は、今となっては適切でなく、今後の読者にも関係のない詳細を削除する必要があるかもしれません。

ローカルディスク上の絶対パスへの言及は避けてください。リポジトリ内のパスを説明する場合は、リポジトリ相対パスを使用してください。

レビュー担当者にとって残す価値のある動作上の証拠（再現したバグ、変更前後の確認、変更した動作を対象とするテスト、または入力と観察結果を伴う手動シナリオ）がある場合を除き、デフォルトでは Verification を省略してください。汎用的なコマンドや、自動化の結果（パッケージテスト、型チェック、リンター、フォーマッター、pre-commit/pre-push フック、CI の状況など）には使用しないでください。

リポジトリのテンプレートで検証セクションが必須の場合は、そのセクションを残し、意味のあるコマンドと結果、対象を絞った手動シナリオ、または理由を添えた Not run を記載してください。ありきたりな内容で埋めないでください。

プロフェッショナルな Markdown を使用してください。

• コード、パス、コマンド、フラグ、識別子はバッククォートで囲んでください。
• シェルの実行記録や複数行の例には、フェンス付きコードブロックを使用してください。
• 変更に関連する既存コードを引用する場合は、GitHub のパーマリンクを使用してください。
• 関連する Issue や他の PR に言及してください。ただし、本文を書いている PR 自身には言及しないでください。

推奨する PR 本文の形式

リポジトリに PR テンプレートがない場合は、次の形式を代替として使用してください。

## Why

Describe the user-facing or maintainer-facing problem, including cause and effect where useful.

## What Changed

Describe the net implementation change in concise prose.