steve-swanson/execute-work

作業の実行

合意された作業を自律的に、develop から派生した意味のある単一のブランチで実行します。 実装をサブエージェントに委譲し、それぞれを独立したワーカーツリーで行わせ、その後、完了したブランチを調整用ブランチに fast-forward マージし、クリーンアップして、完了した調整用ブランチから develop へのレビュー準備完了のプルリクエストを作成します。

この呼び出しにより、ローカルのタスクブランチ、ワーカーツリー、コミット、未公開のタスクブランチのリベース、調整用ブランチへの fast-forward マージ、クリーンで完全に統合されたタスクワーカーツリーとブランチの削除、完了した調整用ブランチのプッシュ、および develop への PR 作成が許可されます。これらのアクションについては、再度確認を求めずに進めてください。ユーザーのスコープおよびリポジトリの指示に従い、明示的なローカル専用または PR なしのオーバーライドを含めます。PR のマージとデプロイはこのスキルの権限外です。既存の禁止事項はそのまま維持してください。

1. 調整用ブランチの準備

合意された計画、該当する AGENTS.md、および必要なプロジェクトガイダンスを読んでください。 作業がすでに定義されている場合は、新たな設計や承認ラウンドなしで実行してください。重大な不足要件についてのみ、1つの焦点を絞った質問をしてください。

ステータス、参照、および既存のワーカーツリーを検査します。無関係な編集やチェックアウトは保持し、リセット、スタッシュ、または再利用しないでください。設定されたリモートから develop をフェッチし、利用可能な場合はそのフェッチされた先端を使用します。フェッチが利用できない場合は、制限事項を開示し、既存のローカル develop 参照を使用します。どちらも存在しない場合は、ベースを尋ねてください。決して暗黙的に別のブランチに代用しないでください。

ブランチまたはワーカーツリーを作成する前に、git worktree list --porcelain、ローカルブランチ名、および利用可能な場合は管理対象ワーカーツリーのアタッチメントをキャプチャします。タスクチェックリストに、実行所有のインベントリ（ブランチ、絶対パス、所有者/エージェント、管理タイプとID、最終コミット、クリーンアップステータス）を保持します。この実行のために作成されたすべてのタスク、ヘルパー、レビューアー、リトライ、および子孫エージェントのチェックアウトを含めます（放棄されたものや変更が含まれていない場合でも）。コーディネーターは、このインベントリ全体のクリーンアップを所有します。既存の無関係なブランチ/ワーカーツリーは保持します。一致する名前のプレフィックスは所有権の証明にはなりません。

専用の調整用ワーカーツリーとブランチを作成します。Conventional Branch スタイル <type>/<short-description> で命名し、小文字でハイフンを使用します（例：feat/store-invitation-recovery）。作業に適したタイプを選択します：feat（新しい動作）、fix（バグ修正）、refactor、perf、docs、test、chore（ツールやメンテナンス）、または ci。ユーザーまたはリポジトリが別の規則を指定している場合（たとえば AGENTS.md 内）、代わりにそれに従ってください。名前に integration を含めないでください。 調整用ベースコミットを記録します。再開された呼び出しでは、この実行の調整用ブランチ/ワーカーツリーとインベントリを再利用し、最初からやり直すのではなくその状態を検査します。

2. 分割と委譲

成果物とファイルの所有権に基づいて分割します。独立したタスクは、利用可能なエージェント容量内で並行して実行します。依存関係と重複する編集は順序付けます。各タスクブランチ/ワーカーツリーは、調整用ブランチの現在の先端から作成します。依存関係が統合された後は、更新された先端から依存タスクを開始します。

タスク要件、関連する計画セクション、絶対ワーカーツリーパス、ブランチ、所有ファイル、依存関係コントラクト、受け入れ基準、および必要なチェックを指定して、実際のサブエージェントを起動します。各エージェントは割り当てられたチェックアウト内でのみ作業し、変更をコミットし、そのコミット、チェック、残りの懸念事項、および作成した追加のブランチ/ワーカーツリーを報告します。これらをすぐに実行所有インベントリに登録します。コーディネーターのみがワーカーツリーの統合と削除を行います。サブエージェントは、このオーケストレーションスキルを再帰的に呼び出したり、自分のブランチをプッシュしたりしてはなりません。明示的な作業ディレクトリまたは git -C を使用します。エージェントはデフォルトディレクトリを共有する場合があります。委譲が利用できない場合は、黙って単独実行に代用するのではなく、その制限を報告してください。

3. 完了タスクのレビュー

各タスクの実際の差分とコミットを受け入れ基準に対して検査します。失敗した場合は、所有エージェントに対処します。統合前に、クリーンなタスクチェックアウト、完了したコミット、および関連する合格チェックを要求します。既存または環境的なブロッカーは正確に報告します。エージェントが完了を報告したという理由だけで作業をマージしないでください。

4. Fast-forward マージによる逐次統合

リベースする前に、完了したタスクブランチへの書き込みを停止します。各タスクについて、祖先を調整用ブランチの現在の先端に対して検査します。最初のマージ後、パラレルな兄弟ブランチは分岐します。残りの未公開タスクブランチをそれぞれ更新された調整用ブランチにリベースしてからマージします。合意された要件に基づいて競合を解決し、すでに統合された動作を維持し、影響を受けるチェックをリベースまたは競合解決後に再実行します。

記録された絶対パスとブランチ名を使用した例：

git -C "$task_path" rebase "$work_branch"
git -C "$task_path" status --short
# タスク_pathで必要なチェックを実行し、祖先を確認します。
git -C "$work_path" merge-base --is-ancestor HEAD "$task_branch"
git -C "$work_path" merge --ff-only "$task_branch"

各コマンドの結果を続行する前に検査します。fast-forward が失敗した場合は、祖先を再検査し、必要に応じて再度リベースします。マージコミット、スカッシュ、チェリーピック、フォースプッシュ、または調整用ブランチのリセットを代用しないでください。安全な解決にプロダクト上の判断が必要な場合は、両方のブランチを保持して質問してください。各タスク統合とその必要なチェックが成功した後、そのタスクについて直ちに以下の必要なクリーンアップを実行します。調整用チェックアウトから結合された作業をレビューします。マージされたタスクチェックアウトは PR レビューには必要ありません。放棄された、または置き換えられた実行所有のヘルパーについても、その作業が考慮された後は同じクリーンアップを適用します。

5. 検証、クリーンアップ、PR の作成

最終的な調整用ブランチで関連する結合チェックを実行し、結果を計画全体と照合します。完了前に統合のリグレッションを修正します。

必要なクリーンアップ: 実行と確認

クリーンアップは成果物の一部であり、ユーザーが後で実行するための提案ではありません。この呼び出しはすでに、この実行のクリーンで完全に統合されたタスク/ヘルパーワーカーツリーとブランチの削除を許可しています。それらの削除について再度尋ねないでください。

1. 所有エージェントとチェックアウトに書き込んでいるバックグラウンドプロセスを停止します。リベース後のブランチの最終コミットを記録し、それが現在の調整用先端の祖先であることを確認し、追跡済み、追跡対象外、および無視されたファイルを検査します。コミットのないヘルパーの場合、その先端がすでに含まれていることを確認します。所有者とともに未完了の作業を調整します。必要な変更を統合し、貴重なローカルアーティファクトを保持する場所に保持してから進みます。使い捨ての実行生成キャッシュやログは正確なパスで削除できます。これらは、そうでなければ完成したチェックアウトを無期限に残す理由にはなりません。

2. プレーンな Git ワーカーツリーの場合、記録された正確なパスと名前を使用してこれらの操作を実行し、続行する前に各結果を確認します。

   git -C "$work_path" merge-base --is-ancestor "$task_tip" "$work_branch"
   git -C "$task_path" status --porcelain --untracked-files=all
   git -C "$work_path" worktree remove "$task_path"
   git -C "$work_path" branch -d "$task_branch"
   

   ワーカーツリーの削除はそのブランチを削除しません。両方の操作が必要です。残っているワーカーツリーがない実行所有ブランチも削除します。強制削除、git branch -D、広範なディレクトリ削除、または未知の編集の破棄は決して使用しないでください。失敗したコマンドを診断し、通常のクリーンアップの問題を範囲内で修正し、黙ってスキップしないでください。

3. アプリ管理のワーカーツリーの場合、ディレクトリを直接削除する代わりに、その管理 API を使用します。Codex では、list_artifacts を使用して正確な所有ワーカーツリー ID を解決し、次に archive_worktree を使用します。結果を検査し、再リストしてアクティブでなくなったことを確認します。その後、残っている場合は git branch -d でその実行所有ローカルブランチを削除します。アーカイブスナップショットやアプリのアタッチメントは、Git 登録とブランチ削除の両方の確認に代わるものではありません。

4. インベントリエントリをクリーンとしてマークするのは、その正確なパスが存在せず、git worktree list --porcelain に登録されておらず、そのブランチがローカル参照からなくなり、管理対象アタッチメントがアクティブでなくなったことを確認した後でのみ行います。Git がブランチがまだチェックアウトされていると言う場合は、他のチェックアウトを検査します。削除リクエストの成功やエージェントの報告を証拠として扱わないでください。

5. 最終応答の直前、PR 作成後または遅延レビュー作業後に、Git ブランチ/ワーカーツリーおよび管理対象アタッチメントのインベントリを繰り返します。ベースラインおよび実行所有インベントリと比較します。エージェントレポートから省略された新しいエントリを説明しますが、無関係な同時作業は削除しないでください。調整用ブランチ/ワーカーツリーは、残っている唯一の実行所有ブランチ/ワーカーツリーである必要があります。PR とテストのために、既存または無関係なチェックアウトとともに保持します。この最終監査は、PR 作成がブロックされたりスキップされたりした場合でも必要であり、安全な場合に譲る前に失敗/中断時にも必要です。

クリーンアップを安全に完了できない場合は、他の適格なエントリのクリーンアップを続行し、クリーンアップブロック を報告します。保持されている各ブランチ/パス、正確な失敗した操作または価値のある/マージされていない作業、およびそれを解決するために必要な最小限のアクションを記載します。実行所有の一時ブランチ/ワーカーツリーが残っている間は、全体的なワークフローを完了として報告しないでください。ルーチンのクリーンアップに引き続き取り組み、マージ成功、テスト合格、PR 作成で終了しないでください。

プッシュと PR の作成

コミットされたすべての作業を含む調整用ブランチ/ワーカーツリーをレビュー用に準備しておきます。統合と必要な検証が成功した後、最終的な差分を検査し、調整用ブランチのみを目的のリポジトリリモートにプッシュします。develop をベース、調整用ブランチをヘッドとして、レビュー準備完了の PR を作成します。ユーザーが明示的に要求した場合にのみドラフトを使用します。作成前に、このヘッド/ベースに対する既存のオープン PR がないか確認します（不確かな作成結果の後も含む）。重複を作成するのではなく、再利用または更新します。

リポジトリの PR テンプレート、タイトル規則、およびチケットリンク要件に従います。最終的な動作、チェックとその結果、および具体的な手動テスト手順を説明します。これらの手順では、製品の操作や永続化された状態の検査について説明する必要があり、リポジトリのテストコマンドの別のリストであってはなりません。プッシュにはローカル Git を、PR 作成には利用可能なリポジトリコネクタを優先します。必要に応じて認証済み CLI を使用します。PR の実際のベース、ヘッド、公開コミットが完了した調整用ブランチと一致することを確認します。アーティファクト添付ツールが利用可能な場合は、作成したすべての PR を現在のチャットに添付します。PR はレビュー用に開いたままにします。

プッシュまたは PR 作成がブロックされた場合は、完了した調整用ブランチ/ワーカーツリーを保持し、正確なブロッカーと残りのアクションを報告します。確認済みの URL がないのに PR が存在すると主張したり、拒否を回避するためにフォースプッシュしたりしないでください。

完了報告

最終応答は、正確な調整用ブランチ名と絶対ワーカーツリーパスで始まる必要があります。確認済みの PR への Markdown リンクを含めるか、PR 作成がブロックされている理由、または明示的にスキップされた理由を述べてから、以下を含めます。

• 新たに動作するもの: 完了した動作と残っているスコープ。
• すでに実行されたチェック: 正確なコマンドと実際の結果。スキップまたはブロックされたチェックを特定します。
• テスト方法: 調整用ワーカーツリーからの、ユーザーが実行可能な短い番号付き検証手順。これは自動チェックとは別であり、pnpm test、lint、build、または同様のコマンドの繰り返しで満たされてはなりません。該当する場合は以下を含めます。
  • セットアップ: 環境/アプリ URL、ログインとロール、サービス、シードまたはフィクスチャデータ、レコード ID、および作業ディレクトリ。
  • メインのプロダクトフロー: 正確な画面またはエンドポイント、現実的な入力と UI アクション、トリガーする動作、および期待される可視結果。
  • 関連するエッジまたはリグレッションフロー: 無効、空、重複、制限付き、または以前に完了したデータで、それらのケースが重要な場合。
  • データを書き込んだり遷移させたりする変更に対する永続化状態の検証: テーブルまたはリソース、フィルターまたは識別子、チェックするフィールド/ステータス、および期待される結果を含む、読み取り専用の DB/API 検査を提供します。ユーザーアクションを保存されたレコードに結び付け、「DB を確認」と言うだけでは不十分です。 たとえば、プロスペクティングの変更では、名前付きエリアと半径のテリトと呼び出しスキャンを作成し、特定の場所を見つけ、その必須属性を確認し、レビュー/アウトリーチアクションを完了し、アプリ内で結果のレビューまたはアウトリーチ状態を確認し、関連するレコードを確認するように言うべきです。他のプロダクトワークフローにも同じレベルの具体性を使用します。 自動コマンドは すでに実行されたチェック の下に保持します。各手動ステップを実行済みまたは推奨としてマークします。アプリまたはデータベースが利用できなかった場合は、正確なブロッカーと、それを実行するために必要な最小限のセットアップを述べます。承認された作業が明示的にテストデータの変更を許可しない限り、データベースの検査は読み取り専用です。
• クリーンアップとブロッカー: 削除またはアーカイブされた一時ワーカーツリーと削除されたローカルブランチの確認済み数。最終監査で残っている実行所有ブランチ/ワーカーツリー（通常はコーディネーターのみ）。ブロックされたすべての一時ブランチ/パスとその正確な理由をリストします。不完全なプッシュまたは PR ステップを含めます。

進行状況の更新は簡潔に保ち、2分以内に実行可能な具体的な次のアクションを1つで終了します。