ce-commit-push-pr

Git Commit、Push、PR

ユーザーへの質問： 現在のツール一覧にあるホストのブロッキング質問ツールを使用してください（ホスト固有の名前ではなく、機能で一致させてください）。現在のツール一覧に存在することは、そのツールが利用可能である証拠です。利用可能かどうかを確認するために、ユーザー向け質問ツールを呼び出してはいけません。一致するツールが一覧にあるものの未ロードの場合は、ホストのツール検出プリミティブを使用してその機能をロードしてください。別のホストのツール名を探してはいけません。一覧に該当ツールがない場合、または実際の質問呼び出しでエラーが発生した場合に限り、チャットで質問してください。質問を黙って省略してはいけません。

モード

• 説明のみ — ユーザーが説明だけを求めている場合（「PR の説明を書いて／下書きして」「この PR の説明を書いて」、PR の URL または番号を貼り付けた場合など）。Step 4 のみを実行して出力してください。適用するのは、依頼された場合に限ります。貼り付けられた PR の参照情報は渡し、Pre-A が範囲を解決できるようにしてください。
• 説明の更新 — コミットまたはプッシュの意図を伴わず、既存の PR の説明を更新または書き直す場合。以下の Context のルールに従って PR の有無を解決してください。exit-0 の [] は「オープン PR なし」を意味します（その旨を報告して終了）。終了コードが 0 以外の場合は不明です（認証または接続を解決し、PR の有無が判明するまで終了してください）。オープン PR がある場合は、その URL を使って PR モードで Step 4 を実行し、続けて Step 5 でプレビューし、確認を得て、gh pr edit で適用してください。
• 完全なワークフロー — それ以外の場合は Steps 1-5 を実行します。意図または希望がスタックを求めている場合は、代わりにスタックモードに入ってください。

mode:pipeline 修飾子は、lfg などのオーケストレーションされた呼び出し元によって設定されます。解決したモードを非対話的に実行し、すべてのブロッキング質問を抑制してください。抑制された質問には、それぞれ保守的な既定値を適用します。つまり、既存 PR の書き換えは行わず、ブランチは維持し、解決できないベースは推測せず停止し、説明の更新プレビューは、その呼び出し自体が適用の意図であるため直接適用します。パイプラインのスタックモードでは、呼び出しに含まれる意図とスコープのみを使用し、引き継ぎには姿勢を渡してください。

スタックモード（オプトイン）

オプトインのみです。 複数 PR のスタックを求める意図または継続的な希望がある場合に入ってください。明示的なスタック要求は必須の意図です。カスタムの --base を指定した単一 PR として読み替えてはいけません。PR スタックを先回りして提案してはいけません。ユーザーがスタックを求めていない場合は、無意味なスタック（1 つの論理的変更を人工的に分割するなど）を拒否し、単一 PR のまま進めてください。

スタックモードでは、Step 3 の前に references/stack-submit.md を読み込み、そこに記載された調査、トポロジー、振り返りの作成方法だけに従ってください。レイヤーごとのコミットフローが、通常の Step 3 に置き換わります。そこで送信してはいけません。Step 5 で、送信、gh stack CLI の依存関係と残作業、および引き継ぎ時の姿勢を扱います。既定では posture:stack-ready を使い、明示的なマージ意図がある場合に限り、最下位のオープンかつドラフトではない PR から posture:stack-land を使ってください。このスキルの argument-hint に posture: を追加してはいけません。

コンテキスト

Step 1 の前に references/context.md を読んでください。 ここには、コマンド表、終了コードの意味、フォークと detached HEAD に関する落とし穴、Step 1〜2 で使うブランチと PR の解決方法が定義されています。ここに適用されるルールも 2 つあります。ブランチを作るかどうかを尋ねてはいけません。detached HEAD の場合、またはデフォルトブランチに変更がある場合はブランチを作成し、デフォルトブランチに変更がない場合はその旨を報告して停止します。また、Conventional Commits では、ユーザーが別途指定しない限り、判断が曖昧な場合は feat: ではなく fix: を優先します。

実行には 3 つのルールがあります。

すべての git と gh のプローブは、それぞれ独立した argv 形式の呼び出しとして実行します。 情報の収集時も再検証時も同様で、終了ステータスは制御フローとして扱います。参照ドキュメントにはその理由と、このスキルが固定する 2 つの複合レシピが記載されています。

プローブの出力はスナップショットです。 重要な操作の直前に、ブランチ、リモート、PR の状態を再検証してください。該当する操作は Step 3 のプッシュと Step 5 の作成です。

ベースリポジトリに対するクエリから exit-0 の [] が返された場合に限り、「オープン中の PR なし」と判断できます。 終了コードが 0 以外の場合は「不明」であり、「なし」ではありません。フォークのチェックアウトでは、-R を使ってベースを指定し、ブランチ名だけを渡してください。--head <owner>:<branch> は暗黙に [] を返すためです。結果がある場合は、インデックス 0 の項目をそのまま選ばないでください。head の owner とブランチが一致する項目を探し、一致が曖昧な場合は停止します。その項目の URL と本文を控えてください。Step 5 では URL を使って既存 PR の経路を選択し、Step 4 では既存の本文を書き換えます。

成果物のルート

アーカイブが有効な場合は、<root> を一度だけ解決します。説明資料は <root>/explainers/ に書き込みます。

成果物のパスを組み立てる前に、CE 成果物ルート <root> を解決してください。

• 読み取り：docs_root は <repo-root>/.compound-engineering/config.yaml のみから読み取ってください（<repo-root> = git rev-parse --show-toplevel）。config.local.yaml からは読み取らないでください。未設定の場合、従来どおり <root> は docs です。
• 検証：設定値がある場合は、リポジトリ相対のディレクトリであり、シンボリックリンクを解決した実パスがリポジトリ内にとどまり、リポジトリのルートでも .git/ 配下でもないことを確認してください。それ以外の場合は、docs_root とその値を示すエラーで停止してください。docs にフォールバックしてはいけません。
• 使用：<root> のみを成果物の保存先として使います。存在しない場合は作成し、各パスをこのスキル独自のサブディレクトリを使った <root>/<subdir> として組み立ててください。docs も併せて読み取ってはいけません。

Step 3：コミットとプッシュ

コミットとプッシュの手順、および references/branch-creation.md によるデフォルトブランチの扱いについては、references/commit-and-push.md を読んでください。 スタックモードで各レイヤーをコミット済みの場合は、Step 4 に進んでください。Step 5 で提出します。

プロジェクトの公開前ゲート。 コミットを公開する前に、プロジェクトで有効な指示と、すでにコンテキストに含まれている規約、およびコミット対象のパスに適用される追加のスコープ付き指示から、該当する公開前またはレビュー準備完了の要件をすべて確認してください。送信するコミットの状態そのものに対して有効な証拠だけが、要件を満たします。それ以外の場合は、外部への書き込みを行う前に停止し、不足している点や失敗している点を報告してください。該当する要件がなければ続行します。

git add -A や git add . は決して使わないでください。無関係なステージ済みファイルが含まれないよう、追加とコミットの両方でファイルを指定してください。exclude:<paths> を尊重し、対象外のファイルはそのまま残して報告してください。

Step 4：PR のタイトルと本文を作成する

タイトルと本文の内容に関するルール、および書き換え時に既存の Related: / Fixes を維持するルールを定めているため、references/pr-description-writing.md を最後まで必ず読んでください。 次に、作成前に決めておくべき 3 つの事項について、references/compose.md を読んでください。すなわち、証拠に関する判断、説明に関する判断（pr_teaching_section はデフォルトで on、pr_teaching_archive はデフォルトで off であり、**有効な（コメントアウトされていない）**キーだけがどちらかを変更します）、およびブランディングに関する判断です。今回の呼び出しで branding:on が指定されている場合、またはこのプロンプトでユーザーが Compound Engineering のブランディングを求めている場合を除き、ブランディングは off です。

Step 1 で既存の PR が見つかった場合は、その URL を Step 4 に渡し、PR モードで既存の本文を取得できるようにしてください。

ステップ 5：適用と報告

適用、プレビュー、アーカイブ、引き継ぎについては references/apply-and-handoff.md を読んでください。 gh pr create の前に、PR が存在するか再確認してください。一致する PR があれば既存 PR の手順に進み、終了コード 0 で [] が返された場合は作成し、終了コードが 0 以外の場合はブロックします。本文は --body-file <path> で渡してください。標準入力は使用しないでください。gh は本文が空でも終了コード 0 を返します。

完了するかどうかはここで決まります。 対話形式の完全なワークフロー、またはパイプラインスタックの送信は、公開済み PR の後続対応を ce-babysit-pr が引き継ぐまでは完了していません。PR の URL を報告するだけでは成功ではありません。監視モードを選ぶには、呼び出し先を読み込んでください。このセッションで実行する場合は、その停止条件を満たして最終報告を行えるまで続けてください。

スキップできるのは babysit:off、CE 設定の auto_babysit: false、または references/apply-and-handoff.md にある「実行しない」ケースのみです。他の監視方法で代用することはできません。ci-watcher、gh pr checks --watch、独自に作成したポーリング、「後で」などは代用になりません。ce-babysit-pr を読み込めない、または開始できない場合は、処理を停止し、ブロックされたことを報告してください。