create-pr

プルリクエストの作成

現在のブランチに対して、タイトルと概要を自動生成した GitHub プルリクエストを作成します。

前提条件

gh auth status を実行し、gh がインストールされ、認証済みであることを確認します。失敗した場合は、gh auth login を実行するようユーザーに伝えてください。

ワークフロー

1. 現在の状態を把握する

次のコマンドを並列で実行します。

• git status - 未コミットの変更を確認します
• git log --oneline -20 - 最近のコミット履歴を確認します
• git rev-parse --abbrev-ref HEAD - 現在のブランチ名を確認します
• git remote show origin | grep 'HEAD branch' - デフォルトのベースブランチ（通常は main または master）を検出します

2. 未コミットの変更に対応する

ステージ済みまたは未ステージの変更がある場合は、プルリクエストを作成する前にコミットするかどうかをユーザーに尋ねます。明示的な承認なしにコミットまたはプッシュしないでください。

3. プッシュに対応する

現在のブランチにリモート追跡ブランチがあり、最新の状態かどうかを確認します。

git rev-parse --abbrev-ref --symbolic-full-name @{u} 2>/dev/null

ブランチがプッシュされていない場合、またはリモートより先に進んでいる場合は、プッシュする前にユーザーに尋ねます。追跡を設定するため、-u を付けてプッシュします。

4. 変更を分析する

このリポジトリのコードの大半は LLM によって生成されているため、レビュアーは差分よりもプルリクエストの説明を重視します。ここでは、ステップ 5 のテンプレートのすべてのセクションを埋めるのに十分な情報を集めてください。変更点を列挙するだけでは不十分です。

最新のコミットだけでなく、ブランチ上のすべてのコミットを確認します。

git log <base-branch>..HEAD                 # full messages, not just --oneline
git diff <base-branch>...HEAD
git rev-parse --abbrev-ref HEAD             # branch name often carries a ticket ID

読みながら、次の情報を意識して集めます。

• 変更の理由（コミットメッセージ、ブランチ名、関連チケット）
• 大まかな仕組み（モジュールやレイヤー、データや制御の流れ）
• 一見してわかりにくい判断（レビュアーが疑問に思いそうな点）
• 動作、インターフェース、スキーマの変更（マージ後にシステムがどう変わるか）
• 実際に行ったテスト（追加されたテストファイルを確認し、ユーザーまたは実行履歴で検証します）
• リスク（破壊的変更、移行、影響範囲）

あるセクションの情報が得られない場合は、作り上げず、ステップ 5 でそのセクションに N/A — <one-line reason> と記載します。

5. プルリクエストを作成する

変更を大まかに説明する、簡潔なタイトル（70 文字未満）を作成します。

本文は、以下のテンプレートに厳密に従う必要があります。8 つのセクション見出しをすべて、順番どおりに含めます。該当しないセクションがある場合は、その見出しの下に N/A — <one-line reason> と記載します。見出しを省略したり、セクションを空のままにしたりしないでください。

テンプレート（各見出しの下に記入します）。

## Context
Why this change exists. What problem it solves or capability it adds.
Reference the trigger (bug, feature request, incident, refactor goal).
One short paragraph — not a changelog.

## Linked Issues
Linear tickets, GitHub issues, incident IDs, or prior PRs this builds on.
`N/A — <reason>` if none.

## Design
The high-level shape of the implementation. How the pieces fit together,
which modules/layers are touched and in what role, and the data/control
flow for the main path. Aim for what a reviewer would draw on a
whiteboard. Avoid restating the diff line-by-line.

## Key Decisions
Non-obvious choices and the trade-offs behind them. Alternatives
considered and why they were rejected. Anything a reviewer might
otherwise flag as "why did you do it this way?" — answer it here
pre-emptively. `N/A — <reason>` only for trivial/mechanical changes.

## Changes
Logical/semantic changes — not a file-by-file inventory. Focus on:
- Interface changes (new/changed/removed commands, flags, public APIs)
- Schema changes (config, data model, API request/response shapes)
- Behavioral changes (what `cx` does differently now)
Skip mechanical detail (which files moved, which libs bumped) unless
it materially affects reviewers. Rollout concerns (migrations,
breaking-change handling) belong in Risks & Rollout, not here.
Bullet list.

## Testing
How the change was verified. List the exact commands run (unit,
integration, e2e, manual `cx` invocations). If a layer was skipped,
say why. Aspirational tests don't count — only what was actually
executed.

## Risks & Rollout
Backwards compatibility, breaking changes, migrations, feature flags,
performance impact, blast radius if this goes wrong. How to roll back.
`N/A — <reason>` for low-risk changes (e.g. pure docs, isolated
refactor).

## Out of Scope / Follow-ups
What this PR deliberately does *not* do, and any follow-up work that
should land separately. `N/A — <reason>` if the PR is fully
self-contained.

次のコマンドで実行します。

gh pr create --title "the title" --body "$(cat <<'EOF'
## Context
...

## Linked Issues
...

## Design
...

## Key Decisions
...

## Changes
- ...

## Testing
- ...

## Risks & Rollout
...

## Out of Scope / Follow-ups
...
EOF
)"

ベースブランチがデフォルトと異なる場合は、--base <branch> を渡します。

6. 送信前のチェックリスト

gh pr create を実行する前に、作成した本文を確認します。

• 8 つのセクション見出しがすべて順番どおりにある：Context、Linked Issues、Design、Key Decisions、Changes、Testing、Risks & Rollout、Out of Scope / Follow-ups
• 空のセクションがない。各セクションに実際の内容、または N/A — <reason> が記載されている
• Testing には、一般的な提案ではなく、このブランチで実際に実行したコマンドが記載されている
• Changes では、ファイルの一覧ではなく、論理的・意味的な違いが説明されている
• Design では、差分よりも高いレベルで変更の仕組みが説明されている

問題がある場合は、送信する前に本文を修正します。

7. 結果を報告する

ユーザーがクリックして開けるよう、プルリクエストの URL を出力します。