lfg

結果。 リクエストは、その内容に応じた最終状態に到達します。これは、その役割を担う Compound Engineering スキルによって実現され、未解決の事項はすべてユーザーに見える場所に記録されます。ほとんどのリクエストは、そのスキルの結果をもって終了し、分岐はありません。コードを変更する場合だけは、独自の手順をさらに踏みます。実装、簡素化、適格な指摘を反映したレビュー、残りの指摘の記録、永続的な学びの記録、コミット、プッシュを経て、CI の結果が確定した状態のオープンプルリクエストで終了し、その URL を保持します。この実行でマージを許可されていない限り、マージはユーザーに委ねられます。

作業の根拠。 コードを変更するルートでは、この実行で確認された作業の根拠がなければ、何も実装しません。該当するのは次の 2 つだけです。ce-work が実装する実装可能な計画、または ce-debug からの fixed の返却で、この場合は修正内容がそのまま実装となります。計画とは、セッションが特定するものであり、その定義は references/intake.md にあります。計画の候補を探すために plans ディレクトリを検索したり、見つけたファイルに基づいて作業したりしてはいけません。既存の計画がある場合、一から計画を立ててはいけません。

リクエストの内容に応じてルートを選びます。 リクエストを、その役割を担うスキルに割り当てます。ホストのスキル一覧がカタログです。選択する前に references/intake.md を読みます。ルート、その優先順位、各子スキルに渡す内容、各戻り値の解釈方法は、すべてこのファイルだけが定義します。要約すると、次のとおりです。

• 計画のパス、またはこのセッションで ce-plan が作成した計画は、計画ルートに進みます。
• 失敗や誤った動作についての具体的な報告は ce-debug に進みます。再現はそのスキルの役割であり、インテイクの役割ではありません。
• ユーザーが決めていない判断に左右される変更は、まず ce-pov に進みます。その後に進めるのは、変更を支持する結論が出た場合だけです。実装するものがない判断の場合は、その結論をもって終了します。
• 複数の解釈が妥当なプロダクトの方向性は、人間が参加している場合は ce-brainstorm に進み、人間が参加していないパイプラインモードでは ce-plan に進みます。
• 結果がコード変更ではないリクエストは、その結果を担うスキル（ce-explain、ce-prototype、ce-pov、ce-ideate など）に進みます。その実行をもって全工程とし、結果を返して終了します。
• それ以外のコード変更は ce-plan に進みます。

判断に迷う場合は、より多くの根拠を求めるルートを選びます。

やり取り。 ユーザーに質問するのは ce-brainstorm を通じてのみで、人間が参加している場合に限ります。それ以外は待たずに進めます。取り消し可能な作業は実施してユーザーに提示し、後から修正できるようにします。例外は、許可されていない取り消し不能な操作（許可されていないマージ、フォースプッシュ、データ削除）で、この場合は停止します。スケジューラー、ループ、ネストされたオーケストレーターから実行する場合は lfg を使います。もう一つの質問は、references/stage-routing.md で定義されるルーティングの曖昧さを解消するためのものです。会話で計画または実装をモデルやハーネスに割り当てる場合は、ルーティングの前にこのファイルを読みます。引き継ぎ用の文字列とサニタイズ方法は、すべてこのファイルだけに記載されています。

次のいずれかに当てはまる場合は、停止して理由を伝えます。

• 作業の根拠を用意できない場合。計画の結果がブロックされた場合、安全な修正が見つからなかった場合、修正が既存の方針から逸脱する場合、ce-pov が変更を支持しなかった場合、または段階の割り当てを引き継げない場合です。
• 子スキルからの戻り値が、完全かつ根拠を伴うものではない場合。
• 確定した判断が無効になった場合。
• プロジェクトで定められた出荷プロセスを満たせない場合。

停止しても、すでにプッシュ済みのもの以外がプッシュされることはありません。

ここで名前が挙がっている各スキルを、ホストで利用可能なスキル一覧に照らして解決し、その一覧にある該当エントリーを正確に呼び出します。ホストによっては compound-engineering:ce-plan のように名前空間が付いています。開始前に references/task-visibility.md を読みます。このファイルでは、プラットフォームのタスク追跡機能を通じて公開される段階の表示、チャットでの状況説明、完了ルールを定義しています。手順は実行されて初めて完了となり、子スキルから戻ったら同じターン内で次の番号付き手順を再開し、DONE に到達するか停止するまでターンを終了してはいけません。

実行フロー（コードを変更するルート）

1. references/intake.md に従って作業ソースを作成します。計画ルートでは、まず references/plan-brief.md を読みます。このファイルだけが、確定済み決定事項の概要と成果物ルートのルールを定義します。settled-decision-invalidated を含め、status: blocked の明示的な返却があった場合は、実行を停止します。ブロック状態は既存の成果物より優先され、再試行は行いません。ブロッカーもなく、今回の実行で ce-plan が計画ファイルを書き込んだと報告していない場合に限り、作成した概要をそのまま再利用して、同じ引数で ce-plan をもう一度呼び出します。その後、計画は references/plan-brief.md の準備状況チェックに合格する必要があります。計画ルートでは、計画段階の指示が解決された場合、plan_model:<alias> キャリアをリクエストと併せて渡します。以降のすべての手順で作業ソースを記録します。LFG が /goal を直接起動することはありません。ce-work が実装を行い、制御を戻します。

2. まず references/work-return.md を読み、次に mode:return-to-caller <plan-path-from-step-1> を指定して ce-work スキルを呼び出します。不具合ルートではこの手順は実行しません。ce-debug がすでに実装とコミットを行っており、references/debug-return.md がそのゲートになっています。有効な status: complete の場合に限り先へ進めます。それ以外のステータス、または形式不正の返却があった場合は、パイプラインを停止します。

3. ここで references/review-followup.md を読みます。これは手順 3 から 7 を規定します。ブランチの差分に対して、mode:pipeline を指定して ce-simplify-code スキルを呼び出します。ドキュメントのみの変更、またはおおむね 10 行未満の変更の場合に限り、呼び出しを省略します。

4. mode:agent plan:<plan-path-from-step-1> を指定して ce-code-review スキルを呼び出します。不具合ルートでは plan: を省略します。確定済み決定事項が実現不可能、対象が誤っている、または破壊的であるため実行できないことを証拠が示す settled_conflict の指摘があった場合は、その指摘を報告し、出荷前提条件の前にパイプラインをブロック状態で停止します。

出荷前提条件（手順 5 以降のすべてのプッシュに適用）。 git remote を 1 回実行します。リモートがない場合はローカルのみで作業します。各手順で必要なコミットはすべて作成しますが、すべてのプッシュ、PR の作成・編集、CI 監視アクションを省略します。手順 10 も全面的に省略します。これは終端状態であり、エラーではありません。

5. ファイルの定義に従ってレビュー修正を適用し、永続化します。適用対象のレビュー修正が未コミットのまま作業ツリーに残っている間は、残件の引き継ぎに進んだり、ブラウザーテストを実行したり、DONE を出力したりしてはいけません。

6. 自律的な残件の引き継ぎ：未適用の対応可能な指摘、手順 4 の settled_conflict スタンプ、または手順 2 で処理が続行され、フラグが付いた settled_decision_conflicts エントリーのいずれかがある場合は、そのファイルに従って永続的に記録します。PR がある場合は PR の本文に、PR がない場合はチケットまたは DONE レポートに記録します。3 つのいずれもない場合に限り省略できます。残件が永続的に記録されるまで DONE を出力してはいけません。レポートで明示されている場合、トラッカーへの登録失敗を理由に DONE をブロックしてはいけません。ユーザーに確認を求めてはいけません。

7. 実行中に、コード、テスト、計画に含まれていない永続的な推論が得られた場合は、mode:non-interactive を指定して ce-compound スキルを呼び出します。完全な適用条件はそのファイルに記載されています。Documentation skipped は成功として扱います。この手順を実行すると、学びが PR の作成時に PR に反映されます。

8. mode:pipeline を指定して ce-test-browser スキルを呼び出します。

9. まず references/shipping.md を読みます。これは手順 9 から 11 を規定します。次に、mode:pipeline branding:on を指定して ce-commit-push-pr スキルを呼び出します。

10. references/shipping.md の判断に従い、オープン中の PR がある場合は ce-babysit-pr mode:pipeline <pr-url> で CI の判定が出るまで PR を監視します。ここで CI 監視を再実装してはいけません。

11. references/shipping.md のクローズアウト後に <promise>DONE</promise> を出力します。