1k-create-pr

OneKey App の PR を作成

OneKey app-monorepo の変更に対する PR 作成ワークフロー全体を自動化します。

クイックリファレンス

手順	アクション	コマンド
1	状態を確認	git status、git branch --show-current
2	ベースブランチを決定	自動検出またはユーザーに確認
3	ブランチを作成（x または release/* 上の場合）	git checkout -b <branch-name>
4	エージェントチェック	yarn agent:check --profile commit
5	ステージングしてコミット	git add .、git commit -m "type: description"
6	リモートにプッシュ	git push -u origin <branch-name>
7	コンテキストを抽出	会話を分析して、意図、判断、リスクを特定
8	PR を作成	gh pr create --base <base> --title "..." --body "..."
9	ブランチを更新	gh pr update-branch <number>
10	自動マージを有効化	gh pr merge <number> --auto --squash
11	PR URL を返す	ユーザーに PR URL を共有

ワークフロー

1. 現在のブランチの状態を確認

git status
git branch --show-current

2. ベースブランチを決定

PR のベースブランチは、現在のブランチがどこから作成されたかによって異なります。

自動検出のロジック：

VERSION=$(grep -E '^VERSION=' .env.version | cut -d '=' -f 2)
RELEASE_BRANCH="release/v${VERSION}"

# Compare distance to both candidate base branches
# (--is-ancestor would give false positives when release branch just forked from x)
release_distance=$(git rev-list --count "origin/$RELEASE_BRANCH"..HEAD 2>/dev/null || echo 999999)
x_distance=$(git rev-list --count origin/x..HEAD 2>/dev/null || echo 999999)

if [ "$release_distance" -lt "$x_distance" ]; then
  BASE="$RELEASE_BRANCH"
else
  BASE="x"
fi

x または release/* に直接いる場合（フィーチャーブランチではない場合）、自動検出では判断できません。この場合、フィーチャーブランチを作成する前に、必ずユーザーに確認してください。

「現在、$current_branch に直接います。PR のターゲットはどこにしますか？」

• x — 通常の開発（バンドル以外）
• $RELEASE_BRANCH — バンドルリリース

これにより、フィーチャーブランチのベースとなるブランチが決まります。

3. ブランチの処理

x または release/* ブランチ上にいる場合（フィーチャーブランチではない場合）：

• まだ決まっていない場合は、ユーザーに PR のターゲットを確認します（上記の手順 2）
• 現在の変更（ステージ済みおよび未ステージの変更）を分析します
• 変更内容に基づいて、内容がわかるブランチ名を生成します：
  • feat/ — 新機能
  • fix/ — バグ修正
  • refactor/ — リファクタリング
  • chore/ — 保守作業
• 作成して切り替えます：git checkout -b <branch-name>
  • ベースが x の場合は、現在の x からブランチを作成します
  • ベースが release/* の場合は、最新の状態を取得し、origin/$RELEASE_BRANCH からブランチを作成します

すでにフィーチャーブランチ上にいる場合： ブランチの作成をスキップし、自動検出したベースを使用します。

4. エージェントチェックを実行

yarn agent:check --profile commit

コミットする前に、報告された lint または型エラーを修正してください。低レベルの lint／型チェックコマンドは、agent:check が報告したログパスのデバッグ時にのみ使用してください。

5. 変更をステージングしてコミット

git add .
git commit -m "<type>: <description>"

コミット形式：

• Conventional Commits に従ってください
• Claude の署名や Co-Authored-By は追加しないでください

6. リモートにプッシュ

git push -u origin <branch-name>

PR の作成後は、統合された PR 準備状況チェックを使用してください：

yarn agent:check --profile pr

7. コンテキストと意図を抽出（重要）

PR を作成する前に、会話履歴全体を分析して、以下を抽出してください：

• 意図：なぜこれらの変更を行いましたか？どのような問題を解決しようとしていましたか？
• 根本原因：バグ修正の場合、根本原因は何でしたか？
• 設計上の判断：どのようなアプローチを検討しましたか？なぜこのアプローチを選びましたか？
• トレードオフ：妥協した点や既知の制限はありますか？
• リスクのある箇所：変更のうち、最もリスクが高い箇所や複雑な箇所はどこですか？
• プラットフォームへの影響：どのプラットフォームが影響を受けますか（デスクトップ／モバイル／ウェブ／拡張機能）？
• 関連する Issue：会話中に言及された OK-{number} 形式の Issue ID はありますか？

コンテキスト抽出のガイドライン：

1. ユーザーの最初の依頼 — ユーザーは何を依頼しましたか？必要に応じて、重要な表現を引用してください。
2. 問題の診断 — 問題はどのように特定され、理解されましたか？
3. 実装の根拠 — 他の方法ではなく、このアプローチを選んだのはなぜですか？
4. 話し合われた制約 — ユーザーが言及した制約や要件はありますか？
5. 検討したエッジケース — 開発中に話し合われたエッジケースはありますか？
6. セキュリティ上の考慮事項 — 話し合われたセキュリティ上の影響はありますか？
7. パフォーマンス上の考慮事項 — 話し合われたパフォーマンス上のトレードオフはありますか？

8. コンテキストを含めてプルリクエストを作成する

gh pr create --base $BASE --title "<title>" --body "<description>"

手順 2 で特定した $BASE（x または release/v{X.Y.Z}）を使用します。

Issue ID の処理：

• コミットの概要／説明と会話履歴から OK-{number} を抽出します
• PR タイトルに追加します：fix: description(OK-49185)
• 開き括弧の前にスペースを入れません

PR 本文のテンプレート：

PR 本文には必ずこのテンプレートを使用してください。該当しないセクションは省略します（「N/A」とは書きません）。

## Summary
<1-3 bullet points describing WHAT changed>

## Intent & Context
<WHY these changes were made. What problem was being solved? What was the user's original request or the bug report that triggered this work?>

## Root Cause
<For bug fixes: What was the root cause? How was it diagnosed?>

## Design Decisions
<Key decisions made during implementation and WHY. Alternatives considered and reasons for the chosen approach.>

## Changes Detail
<Brief description of each significant file change and its purpose>

## Risk Assessment
- **Risk Level**: Low / Medium / High
- **Affected Platforms**: Extension / Mobile / Desktop / Web
- **Risk Areas**: <Which parts of the change are riskiest?>

## Test plan
- [ ] <Testing steps to verify the changes>

9. ブランチを更新する

CI がマージ後の状態で実行されるように、PR ブランチを最新のベースブランチと同期します。

gh pr update-branch <PR_NUMBER>

これは、GitHub の PR ページで「Update branch」ボタンをクリックするのと同じです。

10. 自動マージを有効にする

gh pr merge <PR_NUMBER> --auto --squash

11. PR の URL を返す

PR の URL をユーザーに表示し、ブラウザーで開きます。

open <PR_URL>

重要な注意事項

• ベースブランチは自動検出されます。バンドルリリースブランチでは release/*、それ以外では x が選択されます。x または release/* に直接いる場合は、フィーチャーブランチを作成する前に、使用するターゲットをユーザーに確認してください。
• Conventional Commits 形式を使用します：type: description
• Issue ID（OK-{number}）を抽出し、PR タイトルに追加します
• コンテキストの抽出は必須です：PR の説明には、会話のコンテキストを必ず反映してください。一般的な説明を作成しないでください。コードレビュー AI は、変更の意図を理解するためにこのコンテキストを参照します。
• PR の内容はすべて英語にしてください：タイトル、本文（概要、変更内容、テスト計画）、ブランチ名、コミットメッセージが対象です。中国語など、英語以外の言語は使用しないでください。