pr

プルリクエストの作成

ブランチ戦略

• 対象ブランチ：canary（開発ブランチ、クラウド本番環境）
• main はリリースブランチです。main に直接プルリクエストを作成しないでください。

手順

1. コンテキストを収集する（並列で実行）

• git branch --show-current — 現在のブランチ名
• git status --short — 未コミットの変更
• git rev-parse --abbrev-ref @{u} 2>/dev/null — リモート追跡の状態
• git log --oneline origin/canary..HEAD — 未プッシュのコミット
• gh pr list --head "$(git branch --show-current)" --json number,title,state,url — 既存のプルリクエスト
• git diff --stat --stat-count=20 origin/canary..HEAD — 変更の概要
• タスクに記載された受け入れ確認リンクが、提供する動作を対象としている場合は再利用してください。確認が必要な場合は、まず Publish auth preflight に従い、その後 publish_lh acceptance run list --json を実行して branch で照合してください。API キーを安易に解除しないでください。本番用の認証情報が環境内にしか存在しない場合があります。確認のために新しいラウンドを作成する必要はありません。

2. デフォルトブランチ上の未コミット変更を処理する

現在のブランチが canary（または main）で、かつ未コミットの変更がある場合：

1. 差分（git diff）を分析して変更内容を把握します
2. 変更内容からブランチ名を推測します。形式：<type>/<short-description>（例：fix/i18n-cjk-spacing）
3. 新しいブランチを作成して切り替えます：git checkout -b <branch-name>
4. 関連ファイルをステージします：git add <files>（git add . より明示的なファイルパスを優先してください）
5. 適切な gitmoji メッセージでコミットします
6. 手順 3 に進みます

現在のブランチが canary／main で、未コミットの変更も未プッシュのコミットもない場合は、中止してください。プルリクエストを作成する変更がありません。

3. 必要に応じてプッシュする

• アップストリームがない場合：git push -u origin $(git branch --show-current)
• アップストリームがある場合：git push origin $(git branch --show-current)

4. 関連する GitHub の Issue を検索する

• gh issue list --search "<keywords>" --state all --limit 10
• スコープが一致する Issue のみリンクしてください（大規模な包括的 Issue は避けてください）
• 一致する Issue が見つからない場合は省略してください

5. 受け入れ確認ゲート

機能追加や修正では、プルリクエストを開く前に公開済みの受け入れ確認ラウンドが必要です（AGENTS.md → Acceptance）。手順 1 でこのブランチのラウンドが見つからなかった場合は、まず acceptance スキルを実行し、https://app.lobehub.com/acceptance/<id> のリンクを取得してから戻ってください。セッション中に実際の製品で提供内容をすでに検証済みの場合は、そのスキルの取り込み手順により既存の観察結果と成果物が直接公開されます。再実行も再計画も不要です。ユーザーから見える結果のない純粋なリファクタリングやツール変更では省略できます。その場合は記載を省くのではなく、プルリクエスト本文に理由を明記してください。

6. gh pr create --base canary でプルリクエストを作成する

• タイトル：<gitmoji> <type>(<scope>): <description>
• 本文：プルリクエストテンプレート（.github/PULL_REQUEST_TEMPLATE.md）に基づいて作成します
• テンプレート内の AGENT-INSTRUCTIONS HTML コメントに従ってください。コメントはコメントのまま残し、表示される説明にコピーしないでください。
• 関連する GitHub の Issue はマジックキーワードでリンクします（Fixes #123、Closes #123）
• 該当する場合は Linear の Issue もリンクします（Fixes LOBE-xxx）
• Summary セクションの Test に、受け入れ確認リンク（または明示的な省略理由）を記載してください。
• プルリクエストの作成または更新時は、以下の PR Template に記載されているソースラベル、プライバシー、AI 支援に関するルールに従ってください。プロンプトの開示を求めたり、会話を公開することへの同意を待って通常のプルリクエスト作成フローを止めたりしないでください。
• 書式を保持するため、本文を一時ファイルに書き込み、--body-file を使用してください。

7. PR をアクセプタンスにリンクする

PR の作成前に公開されたアクセプタンスラウンドには PR が紐付いておらず、そのラウンドを再利用するのは正しいため、アクセプタンスについて PR を知らせる手段がほかにありません。gh pr create の直後に、本番公開環境を通じてリンクを記録してください。手順 1 で既知のアクセプタンスを再利用して検索を省略した場合は、まだ publish_lh が定義されていません。公開認証の事前確認を今実行して、定義と確認を行ってください。

publish_lh acceptance link-pr <acceptanceId> "$(gh pr view --json url --jq .url)"

スタック内の各 PR について実施してください。アクセプタンスは共通です。PR にアクセプタンスは不要と記載されている場合は省略してください。後続のラウンドが自らリンクするのは、その result.json に PR（pullRequest）が記載されている場合のみです。ブランチから推定された PR はラウンドに記録されますが、リンクはされません。インストール済みの CLI に link-pr がない場合、またはサーバーが未知のコマンドとして拒否した場合は、再試行せず、その旨を返信に記載してください。

8. ブラウザーで開く

gh pr view --web

PR テンプレート

本文の構成、貢献の分類、開示の適用条件、必須項目の正本として、.github/PULL_REQUEST_TEMPLATE.mdを使用してください。これらのセクションを記入する際は、テンプレートのAGENT-INSTRUCTIONSに従ってください。

• 概要：必須の貢献元ラベルを含め、すべての PR で記入してください。組織のメンバーは詳細の開示が免除される場合でも、AI 支援による作業は引き続きAI-assistedと表示してください。人間によるレビューがあっても、人間のみで作成したことにはなりません。貢献元を特定できない場合はUnknownを使用してください。
• AI 支援：組織メンバーの免除は詳細にのみ適用し、貢献元ラベルには適用しないでください。記入が必要な場合は、プライベートな会話の要約ではなく、最終差分と検証の証拠に基づいて6つの項目を記入してください。PR ごとに1つのセクションを設け、複数のセッションで使用したツールやモデルをまとめてください。不明なメタデータや未実施のレビュー・確認は、正直に報告してください。

プロンプトやトランスクリプトは、デフォルトでプライベートであり、必須項目ではありません。作成者が共有を明示的に求めた場合に限り、公開を提案する正確なテキストに機密情報が含まれていないか確認し、そのテキストを公開する前に承認を得てください。PR の作成や更新を許可されたことは、会話を公開することへの同意ではありません。添付されたログやスクリーンショットにも機密情報が含まれていないか確認してください。

本番データの識別子を含めない

PR のタイトル、本文、コメント、レビューへの返信は公開されます。バグが見つかった場所であっても、本番データから取得した識別子や詳細を記載してはいけません。

• レコード ID：トピック（tpc_…）、メッセージ（msg_…）、操作（op_…）、エージェント（agt_…）、ドキュメント（docs_…）、ユーザー、デバイス、ボットの ID。これには、エージェントベント ID や内部再現レポートの ID も含まれます。
• ユーザーの詳細：デバイス名やホスト名、ローカルパス、ファイル名、ユーザーの発言の引用、ユーザーのエージェントやトピックへのアプリリンク。

証拠の内容を説明してください。「本番環境のトピックで確認」「2台のデスクトップ（デバイス A とデバイス B）を持つユーザー」などと記述します。明らかなプレースホルダー（tpc_xxx、C:\Users\user）は、例の中で使用できます。コミットハッシュ、デプロイ ID、コード識別子は本番データではありません。同じルールはコミットメッセージとコードコメントにも適用されます。

注意事項

• 言語：すべての PR コンテンツは英語で記述してください。
• ブランチにすでに PR がある場合は、重複して作成せず、その旨をユーザーに伝えてください。

---

スタック PR（レイヤーをまたぐ機能）

上記の手順で作成される PR は、現在のブランチに対して1つです。1つのブランチで複数のレイヤーにまたがる変更（packages/databaseのスキーマ／モデル → 共通のpackages/*ライブラリ → src/serverのTRPC → apps/desktopとapps/cliの呼び出し元 → src/featuresの UI）を含む場合、1つの PR として出すと安全にマージできません。クライアントが呼び出すエンドポイントは、その PR がマージされるまで trunk に存在しないため、部分的な適用やロールバック、独立したレビューによって問題が生じます。レイヤーの低いものから順に、複数の PR に分割してください。

順序のルール

PR は、呼び出すすべてのレイヤーがすでに trunk に反映されてからでないと、マージできません。

• サーバーコントラクト（新しい TRPC プロシージャ、戻り値の形式変更、新しいテーブル／モデル）を最初にマージします。
• 呼び出し元（デスクトップ、CLI、UI）はその後にマージします。これらはコントラクトを呼び出します。
• 判断に迷ったら、次の質問で決めます。「これだけを今すぐ canary にマージした場合、ビルドできて、想定どおりに動作するか？」 いいえなら、後の PR に含めます。

PR ごとのファイルの振り分け

判断が難しいケースは次のとおりです。

• コントラクト変更に対応するフロントエンドの変更は、サーバー PR と一緒に含めます。 TRPC の戻り値の形式を拡張する場合（例：listDevices が platform: string | null を返すようになる場合）、それを利用するコンポーネントも_同じ_ PR で変更する必要があります。そうしないと、サーバー PR 単独ではビルドが失敗します。コントラクトと、リポジトリ内でそれを利用するコードは一緒にマージします。
• 新しい共有パッケージは、サーバーもインポートする場合を除き、サーバーではなく利用側と一緒に含めます。 デスクトップ／CLI だけがインポートする @lobechat/* パッケージは、クライアント PR でマージします。下位 PR に未使用のパッケージを含めないでください。
• ワークスペースの依存関係宣言（package.json の workspace:*、pnpm-workspace.yaml）は、そのパッケージをインポートするコードと一緒に含めます。

Git の手順 — 既存の完全なブランチを分割する

開始時の状態：すべてを含む単一のコミット <FULL> があるブランチ（feat/x）があり、すでにプッシュ済み（そのためリモートにも安全に保存されています）。

# 1. Safety nets — make the full work unloseable before rewriting anything
git branch backup/x-full <FULL>          # local ref to the full commit
git branch feat/x-clients <FULL>         # the higher-layer branch starts here

# 2. Rewrite the lower-layer branch to lower-layer files only
git checkout feat/x                      # this becomes the SERVER PR
git reset --hard origin/canary
git checkout <FULL> -- <server/db files…>   # stages just those paths
git commit -m "✨ feat(...): <server half>"
git push --force-with-lease origin feat/x   # never --force; never push to canary

# 3. Build the higher-layer branch STACKED on the lower branch
git checkout feat/x-clients
git reset --hard feat/x                  # base = the just-rewritten server HEAD
git checkout backup/x-full -- <client/ui files…>   # only the remaining paths
git commit -m "✨ feat(...): <client half>"
git push -u origin feat/x-clients

次に、上位の PR を trunk ではなく、下位のブランチをベースにして作成します。

gh pr create --base feat/x --head feat/x-clients --title "…" --body "…"

--base feat/x によって差分がクライアントの変更だけになり（サーバーのファイルが混入せず）、サーバーより先にクライアントをマージできない状態を確実に作れます。サーバー PR が canary にマージされた後、クライアント PR のベースを canary に変更します（GitHub は通常、ベースブランチがマージされると自動で変更します。人が確認できるよう、PR の本文にも記載してください）。

依存関係が実際に満たされていることを確認する

上位レイヤーが下位レイヤーを必要とすることが、分割する理由です。実際に確認してください。積み上げた上位ブランチで呼び出し元の型チェックを行い、下位レイヤーで追加したシンボルが解決されることを確かめます。

cd apps/cli && bun run type-check 2>&1 | grep -iE "connect\.ts|device\.register"
# empty (re: your change) = the stacked base supplies device.register ✓

変更したファイルに絞ってください。このリポジトリの単独での型チェックでは、既存の環境に起因するノイズ（__ELECTRON__、@/types/llm、ビルドされていない @lobechat/types）が出力されますが、これらは今回の変更によるものではありません。

PR と Linear の記録

• 各 PR でクローズするのは、その PR が担当するレイヤーの課題だけです。 サーバー PR：Closes LOBE-<server>。クライアント PR：Closes LOBE-<pkg> / <desktop> / <cli>。ある PR の本文で、別のレイヤーの課題までクローズすると記載しないでください。
• 両方の PR に Part of LOBE-<parent> を付けます。
• PR の作成時に、クローズする各サブ課題を In Review（Done ではありません）に移動し、完了コメントを追加します。linear スキルを参照してください。

注意点

• canary には絶対にプッシュしないでください。 git checkout -b feat/x origin/canary で作成した分割ブランチは origin/canary を追跡するため、引数なしの git push は canary にプッシュします。必ずブランチ名を明示して git push origin feat/x を実行してください。
• 下位ブランチを書き換えるときは、--force ではなく --force-with-lease を使います。リモート側が更新されていた場合に処理が中止されます。
• reset --hard の前にバックアップを取ります。 ステップ 1 の backup/x-full とプッシュ済みのリモートブランチにより、書き換え前は完全なコミットが 3 つ以上の参照先から参照されます。git branch --contains <FULL> で確認してください。
• ロックファイル： このモノレポではルートの pnpm-lock.yaml をコミットしていないため、新しい workspace:* 依存関係を追加しても、ロックファイルの変更は不要です。ロックファイルをコミットしているリポジトリでは、分割後に各ブランチで再生成してください。
• 分割しすぎないでください。 通常、PR は 2 つ（コントラクト／呼び出し元）で十分です。既存のエンドポイントを読み取るだけの UI ページは、後続の独立した PR にできますが、それだけの理由で単一のレイヤーを複数の PR に分割しないでください。