jeffyfung/skills

コミット、プッシュ、PR作成

現在のフィーチャーブランチで作業を出荷します: コミット → プッシュ → PR。確認ゲート（ステップ6）がプッシュを制御します。同じターン内で連続して呼び出された場合でも、これをスキップしないでください。

オプションでベースブランチを1つ引数として取ります。指定がない場合、ステップ5でベースを解決します。

1. ブランチのガード

git branch --show-current を実行します。main/master の場合は停止し、ユーザーに最初にフィーチャーブランチを作成するように伝えます。main に直接コミットまたはプッシュしないでください。

2. コミットのスコープ設定

git status + git diff を実行します。現在のタスクに属するファイルのみをステージングします。スクラッチ出力、生成データ、ローカルテストフィクスチャ（CSV、*_results/*、ログ）のように見える追跡対象外ファイルは自動ステージングしません。それらをリストアップし、ユーザーに含めるか、無視するか、gitignoreに追加するかを尋ねます。

3. コミット前のチェック

リポジトリ独自のフォーマット/リンタコマンドを探します。AGENTS.md、CLAUDE.md、README.md（この順序）で文書化されたフォーマッタ/リンターを確認し、指定されているものを実行します。それらのドキュメントのいずれも指定していない場合、dotnet format やその他のツール固有の推測をデフォルトにしないでください。フォーマッタ/リンターが文書化されていないことをメモして先に進みます。

変更がテスト済みのコードに影響し、高速なターゲットテストの実行が利用可能な場合はそれを実行します。コミットのために全テストスイートを実行しないでください。

4. コミットメッセージ

Conventional Commits（feat|fix|test|docs|refactor(scope): summary）形式で、このリポジトリの git log のスタイルに合わせます。本文は、変更の「理由」が差分から明らかでない場合のみ追加します。

5. ベースブランチの解決

ベースは main ですが、作業が積み上げられている場合（まだマージされていないフィーチャーブランチ上に構築されており、main をベースにすると下位ブランチがこの差分に引きずり込まれる場合）は例外です。

1. 引数が指定された場合 — それがベースです。git rev-parse --verify origin/<base> で確認します。その参照が存在しない場合は、その旨を伝えて main を使用します。
2. 引数がない場合 — 候補を1つ探します。以下のいずれか:
   • 会話の中で、この作業が別のブランチで行われたコミットの上に位置することが示されている。
   • 作業が、別のチケットによってブロックされている、または依存しているチケットから来ている — そのブロッカーを解決するブランチが候補です。
   • git log --oneline origin/main..HEAD にこのタスクが生成しなかったコミットが表示される。git branch -r --contains <sha> でそれらがどこから来たかを示します。
3. 候補を検証します。 リモートに存在し、現在のブランチと異なり、かつ git branch -r --merged origin/main に含まれていない必要があります — すでに main にマージされた候補は無効です。
4. 候補がない、または検証に失敗した場合 — main。

検証済みの候補は決定ではなく提案です。ステップ6のゲートで main と一緒に提示し、ユーザーに選択させます。

6. 確認ゲート — プッシュ

ユーザーにコミットメッセージ、git diff --stat（または作成後のコミット）、およびステップ5のベース（ステップ5が候補を見つけた場合は両方のオプション）を表示します。git push -u origin <branch> の前に明示的な承認を得ます。プッシュするとブランチが公開されます — 一方通行として扱います。PR作成は同じ確認に依存しており（ステップ7参照）、別途承認は必要ありません。

7. PRを開く

まず、このブランチのPRがすでに存在するかどうかを確認します: gh pr list --head <branch> --state all。

• オープン中のPRが見つかった場合 — それを再利用し、重複を作成しません。そのURLを報告します。
• マージ済みのPRが見つかった場合 — ブランチはすでに出荷済みです。停止して、別のPRを作成する前にユーザーにどうしたいか尋ねます（マージ後の新しいコミットは異常であり、デフォルトのケースではありません）。
• 既存/マージ済みのPRがない場合 — ステップ6のプッシュ確認ですでにカバーされています。本文をドラフトし、gh pr create --base <base> --head <branch> --title "<title>" --body "<body>" をそのまま実行します。追加の承認は不要です。

可視的なUI変更のスクリーンショット。 変更がユーザーに見えるもの（新しいテキストフィールド、色の変更、新しいレイアウトやコピー、新しいページやコンポーネント）を変更する場合は、ハッピーパスと変更によって導入されるエッジケース（空の状態やエラー状態、長い/あふれるテキスト、該当する場合はレスポンシブとデスクトップ）のスクリーンショットを撮影します。gh pr create --attach '<path>#<alt text>' でアップロードします（画像ごとに繰り返します。既存のPRの場合は gh pr edit <pr> で追加します）。本文が同じパスを参照している場合（例：## Screenshots 見出しの下の ![Happy path](./pr-shots/happy.png)）、gh はその参照をアップロードされたURLにその場で書き換えます。そうでない場合、添付ファイルは本文の最後に追加されます。これはプライベートリポジトリでも機能します。添付ファイルはリポジトリへのアクセス権を持つ誰でも表示できます。ファイルをコミットに含めないでください（スクラッチディレクトリを使用します）— アップロードされるものであって、バージョン管理されるものではありません。gh 2.99以上が必要です。古いバージョンの場合は、Web UIで画像をPR本文にドラッグしてください。変更がユーザーに見えない場合（ロジック、テスト、設定、ドキュメント、CI）はスキップします。

ドラフトを作成する前に、リポジトリ独自のPR説明テンプレート（.github/PULL_REQUEST_TEMPLATE.md、.github/pull_request_template.md、docs/* または CONTRIBUTING.md のPR本文に関するガイダンス）を確認します。リポジトリに文書化されたテンプレートがある場合は、以下のテンプレートよりも優先されます。それを使用します。

PR本文テンプレート（フォールバック — リポジトリの標準が存在する場合はそれが優先されます）

## 概要
<何が変わったか、なぜ変わったか、1〜6文>

## 変更点
- <注目すべき変更1>
- <注目すべき変更2>

## スクリーンショット
<可視的なUI変更の場合: ハッピーパス + 関連するエッジケース。不可視の変更の場合は省略>

## 設計上の決定
<注目すべきトレードオフや却下された代替案 — 大規模な機能変更の場合のみ。以下参照>

## テスト
<実行したコマンド / 検証方法>

## フォローアップ
<先送りした作業、または「なし」>

ベースが main でない場合、概要をベースブランチの名前と最初にマージする必要があるものを指定して開始します。レビュアーは差分が積み上げられていること、およびベースがマージされたらPRが main に再ターゲットされることを知る必要があります。

設計上の決定セクションは、PRが実際に規模の大きい新しい機能動作（新しいモジュール、非自明なアルゴリズム、レビュアーが他の方法で質問せざるを得ないトレードオフ）を導入する場合にのみ含めます。ドキュメント/設定/雑務/小さな修正の場合はセクション全体を空のままにするのではなく省略します。

8. レビューウォークスルー（広範な変更のみ）

以下のいずれかが当てはまる場合に、自己完結型のHTMLウォークスルーを作成します:

• 差分が複数の異なる非UIモジュールに影響を与える。
• データベーススキーマ（マイグレーション、テーブル、カラム、インデックス、制約）を変更する。
• 大規模なエンドツーエンド機能（複数のレイヤーを横断する新しいフロー）である。

ドキュメント、設定、雑務、小さな修正、および1つのモジュールまたはUIのみに限定された変更の場合はスキップします。ウォークスルーはレビューを短縮するために存在します — すべてのPRに対して自動的に生成しないでください。

コミットの外部にあるスクラッチディレクトリに pr-walkthrough.html という1つのファイルを作成します（ステージングしないでください）。open pr-walkthrough.html でローカルに開き、ユーザーにパスを伝えます。ホストしたり、添付したり、バージョン管理したりしないでください。

ネイティブの <details>/<summary> 折りたたみ見出しを使用してセクションとして構成します。最初のセクションは開いた状態、残りは折りたたんだ状態にします。これにより、レビュアーが見出しをスキャンして必要なものだけを展開できます。JavaScriptは使用しません。

差分を読んでいないレビュアー向けに記述します:

• 何となぜ — 変更を数文で説明し、差分を読む順序を示します。
• 変更マップ — どのモジュールが影響を受け、それらがどのように接続されているか。ファイルリストではなく図です。
• メカニクス — 自明でないロジックやデータフローの各部分を、それが名前を挙げているコード（path:line）の横に説明します。
• スキーマ変更 — 変更前/後のテーブル構造、マイグレーションパス、およびリスク（ロック、バックフィル、ロールバック）。
• 難しい部分 — レビュアーが他の方法で質問せざるを得ない部分と、精査すべき点。

図: モジュールの依存関係、リクエスト/シーケンスフロー、スキーマについては、手書きで内容に合わせたサイズのインラインSVGを使用します。ファイルを自己完結型に保ちます — 外部JS、CSS、画像URLは使用せず、オフラインでも開けるようにします。説明するものが視覚的な場合にのみ、レンダリングされた画像またはスクリーンショットを使用します。

9. 報告

ユーザーにPRのURLとターゲットとするベースを伝えます。何がコミットされ、プッシュされ、開かれたかを明確に述べます。曖昧にしません。