lfg

重要: 以下の各ステップを「順番通りに」実行する必要があります。必須ステップをスキップしないでください。コーディングや実装に飛び込まないでください。計画フェーズ (ステップ 1) は作業開始前に完了および検証されなければなりません。この順序に違反すると、不適切な出力が生成されます。

以下で参照されるスキルを呼び出す際は、ホストプラットフォームが提供する available-skills リストに対して名前を解決し、その正確なエントリを使用してください。一部のプラットフォームはスキルをプラグイン名前空間の下に列挙し (例: compound-engineering:ce-plan)、他のプラットフォームはベア名を列挙しています。リストに含まれていない短縮形の推測で呼び出すと失敗します — Skill/Task ツールを呼び出す前に必ずリスト済みエントリと完全一致させてください。

1. $ARGUMENTS を使用して ce-plan スキルを呼び出します。

   ゲート: 停止。ce-plan がこのタスクがソフトウェアではなく、パイプラインモードで処理できないと報告した場合は、パイプラインを停止し、LFG がソフトウェアタスクを必要とすることをユーザーに通知してください。それ以外の場合は、ce-plan ワークフローが docs/plans/ に計画ファイルを生成したことを確認してください。計画ファイルが作成されなかった場合は、$ARGUMENTS を使用して ce-plan を再度呼び出してください。書面による計画が存在するまで、ステップ 2 に進まないでください。計画ファイルパスを記録してください — ステップ 3 の ce-code-review に渡されます。

2. ce-work スキルを呼び出します。

   ゲート: 停止。実装作業が実行されたことを確認してください — 計画以上にファイルが作成または変更されています。コード変更が行われなかった場合は、ステップ 3 に進まないでください。

3. ce-code-review スキルを mode:autofix plan:<plan-path-from-step-1> で呼び出します。

   ステップ 1 の計画ファイルパスを渡してので、ce-code-review は要件の完全性を検証できます。スキルが出力する残存実行可能作業サマリーを読んでください。

4. レビューオートフィックスを永続化 (ステップ 3 後、残存ハンドオフ前に必須)

   git status --short を確認してください。ce-code-review mode:autofix がファイルを変更した場合は、それらのレビュー修正ファイルのみをステージし、fix(review): apply autofix feedback でコミットし、続行前に現在のブランチをプッシュしてください。アップストリームが存在する場合は、git push を実行してください。アップストリームが存在しない場合は、書き込み可能なリモートを動的に解決してください: 存在する場合は origin を優先し、それ以外の場合は git remote を使用して最初に構成されたリモートを選択してください。その後 git push --set-upstream <remote> HEAD を実行してください。レビューオートフィックス編集が作業ツリーにのみ存在する間は、ステップ 5、ブラウザテスト、または DONE 出力に進まないでください。ファイルが変更されなかった場合は、レビューオートフィックスの永続化がなかったことを明示的に記録してください。

5. 自動残存ハンドオフ (ステップ 3 が 1 つ以上の残存 downstream-resolver 検出結果を報告した場合のみ; Residual actionable work: none. を報告した場合はスキップ)

   ユーザーにプロンプトを表示しないでください。このステップはオートパイロット契約を採用しています: 残存は DONE 前に耐久性を持つ必要がありますが、エージェントは決して停止して質問しません。

   1. references/tracker-defer.md を 非対話モード でロードしてください。ステップ 3 のサマリーから残存実行可能検出結果を渡してください (またはサマリーが切り詰められた場合は実行アーティファクト)。

   2. 構造化された戻り値を収集してください: { filed: [...], failed: [...], no_sink: [...] }。

   3. 構造化された戻り値から ## Residual Review Findings マークダウンセクションを作成してください:

      • filed の各アイテムについて: 重大度、file:line、タイトル、およびトラッカーチケット URL へのリンクを含む箇条書き。
      • failed の各アイテムについて: 重大度、file:line、タイトル、および失敗理由を含む箇条書き (例: Defer failed: gh returned 401 — tracker unavailable)。
      • no_sink の各アイテムについて: 重大度、file:line、およびタイトルをインライン逐語的に含む箇条書きであり、PR 本文またはフォールバックファイルが耐久的な記録になります。

   4. プロンプトなしで現在のブランチのオープン PR を検出してください:

      gh pr view --json number,url,body,state
      

   5. オープン PR が存在する場合は、gh で直接更新してください。確認駆動 PR 更新スキルをロードしないでください。現在の PR 本文で ## Residual Review Findings セクションを追加または置換し、新しい本文を OS テンポファイルに書き込み、その後以下を実行してください:

      gh pr edit PR_NUMBER --body-file BODY_FILE
      

   6. オープン PR が存在しない場合は、docs/residual-review-findings/<branch-or-head-sha>.md にトラッキング対象フォールバックファイルを作成し、作成されたセクションとソース PR レビュー実行コンテキストを含めてください。そのファイルのみをステージし、docs(review): record residual review findings でコミットし、現在のブランチをプッシュしてください。アップストリームが存在する場合は、git push を実行してください。アップストリームが存在しない場合は、書き込み可能なリモートを動的に解決してください: 存在する場合は origin を優先し、それ以外の場合は git remote を使用して最初に構成されたリモートを選択してください。その後 git push --set-upstream <remote> HEAD を実行してください。これが PR なしの耐久的なシンクです。既存の PR 本文が更新されるか、このフォールバックファイルコミットがプッシュされるまで DONE を出力しないでください。両方のパスが失敗した場合は、停止して失敗したコマンドを報告してください。黙って続行しないでください。

   残存がdurably記録されると、トラッカーファイリング失敗で DONE をブロックしないでください。no_sink の結果は、PR 本文またはプッシュされたフォールバックファイルに検出結果が存在する場合のみ成功です。

6. ce-test-browser スキルを mode:pipeline で呼び出します。

7. ce-commit-push-pr スキルを呼び出します。

   これは残りの変更をコミットし、ブランチをプッシュし、プルリクエストを開きます。ステップ 5 が既に PR を開いた場合は (gh pr view --json number,url,state 2>/dev/null で確認)、PR 作成をスキップしますが、まだコミットされていない変更をコミットしてプッシュしてください。

8. CI 監視とオートフィックスループ (現在のブランチに対してオープン PR が存在する場合のみ)

   PR を検出してください; 存在しない場合または gh が利用できない場合は、このステップ全体をスキップしてステップ 9 に進んでください。

   gh pr view --json number,url,state
   

   最大 3 回の修正イテレーション の場合、繰り返してください:

   1. CI の完了を待機してください:

      gh pr checks --watch
      

      コマンドが 0 で終了する場合、すべてのチェックに合格しました。ループから抜け出してステップ 9 に進んでください。

      0 以外で終了する場合、1 つ以上のチェックが失敗しました。(2) に進んでください。

   2. 失敗しているチェックを特定し、失敗ログをプルしてください。gh pr checks --json name,state,conclusion,workflow,link を使用して失敗を列挙し、各失敗チェックについて実行ログを読んでください:

      gh run view <run-id> --log-failed
      

      ここで <run-id> はチェックの詳細 URL またはワークフロー実行から解析されます。

   3. 失敗ログを読み、根本原因を特定し、作業ツリーで修正を適用してください。失敗するアサーションを弱体化、スキップ、またはモック化して合格させるというわけにはいきません — 実際の問題を修復してください。失敗がフレーキーテストで修正パスがない場合は、コード変更なしで再試行するのではなく、それを以下の残存結果として文書化してください。

   4. 変更したファイルのみをステージし、コミットしてプッシュしてください:

      git add <changed-files>
      git commit -m "fix(ci): <one-line summary of the failure repaired>"
      git push
      

   5. 次の試行カウンターで反復 (1) に戻ってください。

   ゲート: 失敗した 3 回の試行後、イテレーションを停止してください。3 修正サイクル後も CI がレッドのままの場合:

   • 各残存失敗チェック、失敗サマリー、および実行/チェック URL をリストする ## CI Failures Unresolved マークダウンセクションを作成してください。

   • PR 本文でこのセクションを追加または置換し、新しい本文を OS テンポファイルに書き込み、その後以下を実行してください:

     gh pr edit PR_NUMBER --body-file BODY_FILE
     

   • ループを継続しないでください。オートパイロット契約は「残存をdurable にしたら、終了する」です。ステップ 9 に進んでください。

9. 完了したら <promise>DONE</promise> を出力してください

ステップ 1 から今すぐ開始してください。記憶: 最初に計画、その後に作業。計画をスキップしないでください。