chrislacey89/execute

execute は何をしますか？

完全な作業単位を実行します。計画、構築、実際の結果の検証、コミットを行います。

呼び出し位置

これは、/prd-to-issues が具体的なスライスを生成した後、またはユーザーが既に明確にスコープ設定された実装タスクを持っている場合に使用されるプライマリパイプラインスキルです。

作業を構築、検証、コミットする準備ができたら /execute を使用します。

スライスにまだ積極的なユーザーの判断、監視、または実装中の承認決定が必要な場合は、HITL /execute を使用します。次のスライスがGitHub上で既に永続的で、ブロックされておらず、そのIssue、境界マップ、およびリンクされた調査成果物（アーカイブファイルやスパイクIssue）または docs/solutions/ コンテキストから判読可能な場合にのみ、AFK /execute を使用します。

判読可能とは、それらのいずれも保持しない読者にとって理解できることです。これがAFKイテレーションの条件です。/prd-to-issues §4のコンテキスト完全性チェックは、その条件の背後にあるゲートです。すべてのAFKスライスが、Issueが提出される前に ### Context ブロック、または明示的な空の宣言を持つことを要求します。そのようなブロックなしでAFKとマークされたスライスは、この条件に対してチェックされたことがなく、満たされていると仮定されただけです。それを、スライスをHITLで実行するか、/prd-to-issues に戻す理由として扱います。形式的に通過させるものではありません。

以下のステップ0: 前提条件にある、必須のRalph自動検出およびTDDマーカーゲートを参照してください。

問題や形状が未解決の場合に /shape、/research、または /write-a-prd の代わりに使用しないでください。実装が完了し、レビューの準備ができた後の /pre-merge の代わりとしても使用しないでください。

ワークフロー

0. 前提条件

ブランチ分離ゲート。 実装作業を開始する前に、この特定のタスク用に作成されたクリーンなブランチで作業していることを確認してください。以前の作業から残ったフィーチャーブランチではありません。

分離は既に提供されています — 待機してください（これを、番号付きルールの前に最初に確認してください）。 一部の環境では、/execute が実行される前に、専用の分離されたワークツリーとブランチをセッションに提供します。Conductorワークスペース、GitHub Codespaces、devcontainersなどはそれぞれ「1ワークスペース = 1ブランチ、ベースから自動フォーク」をプロビジョニングし、セットアップスクリプトは既に実行されています。その場合、パイプラインはプロビジョニングを所有していません。ここでワークツリーを作成すると、ホストのワークツリーの内部に入れ子になり、ホストのブランチ（タスクではなくワークスペースにちなんで名付けられた）は「古くなって」いません。環境のシグナルを読み取り、ワークツリーを既に所有している人に譲ってください（Norman — パイプラインが常にプロビジョニングするという頭の中の仮定ではなく、世界の意味を読み取ってください。Meadows — ストックごとに1つのアクターなので、パイプラインは競合するマネージャーを追加するのではなく延期します）。

プロビジョニングモードを .claude/settings.json の worktree.provisioning から解決します。"host" | "pipeline" | "auto"、キーがない場合のデフォルトは "auto" です（既存の research.storage の precedent を反映）。

• host — 分離はホストが所有します。無条件に待機します。
• pipeline — パイプラインがプロビジョニングします。この待機をスキップし、以下の番号付きゲートを実行します。
• auto（デフォルト）— 次のいずれかのシグナルが発動した場合に待機します。
  • ホスト環境変数がこのツリーを説明している — 以下のブロックが host_owned=yes を出力します。これは最も安価で主要な識別子です。パイプラインの唯一の検出メカニズムはBashであり、これらの変数はエージェントのシェルで可視です。存在だけでは十分ではありません。CONDUCTOR_WORKSPACE_PATH はConductorで起動されたすべてのシェルに継承され、異なるリポジトリのワークスペースを指定する可能性があるため、現在のトップレベルを含む場合にのみカウントされます。（cwdの .conductor ディレクトリを介して検出しないでください。Conductorはそれを $CONDUCTOR_ROOT_PATH の下に保持しており、ワークスペースにはありません。）
  • 現在のワーキングツリーがリポジトリのプライマリワーキングツリーではない — git rev-parse --show-toplevel が git worktree list --porcelain の最初のパスと異なる。

# host-signal: ホスト環境変数はTHISツリーを説明していますか？単にこのシェルだけではありませんか？
host_owned=no
top=$(cd "$(git rev-parse --show-toplevel)" && pwd -P)
if [ -n "${CONDUCTOR_WORKSPACE_PATH:-}" ]; then
  ws=$(cd "$CONDUCTOR_WORKSPACE_PATH" 2>/dev/null && pwd -P) || ws=
  if [ -n "$ws" ]; then
    case "$top/" in "$ws"/*) host_owned=yes ;; esac
  fi
fi
if [ -n "${CODESPACES:-}" ] || [ -n "${REMOTE_CONTAINERS:-}" ]; then host_owned=yes; fi
echo "host_owned=$host_owned"

CODESPACES と REMOTE_CONTAINERS は比較するパスを持たず、存在がチェックされます。これらはコンテナスコープであるため、それらを認識するシェルは、それらが説明するリポジトリを含むコンテナ内にあります。同じブロックが /closeout、/lfg、および /init-pipeline にも表示され、バイト単位で同一であり、パック自身のリポジトリ内の scripts/test-host-signal-containment.sh によって固定されています。

待機する場合：ワークツリーの作成と EnterWorktree をスキップし、現在のブランチでそのまま作業します。 以下の番号付きルールは既に満たされています。特にルール3は適用されません（ホストプロビジョニングされたブランチはベースでもタスク名でもありませんが、古くはありません。ワークツリーを入れ子にせず、停止もしないでください）。ホストは既にgit-ignoredな設定と依存関係をシードしているため、「ワークツリーセットアップチェックリスト」のほとんどは情報提供のみです。コマンドが失敗した場合は .env.local/依存関係をスポットチェックしますが、再プロビジョニングはしないでください。git-hooks項目は例外であり、依然として適用されます。 ホストは追跡されたファイルと依存関係をプロビジョニングします。gitフックは .git/hooks に存在し、これはワークツリーごとで追跡されないため、ホストプロビジョニングされたワークスペースには特徴的に存在しません。待機する場合でもその項目を確認してください。Issue形状ゲートに進みます。

この待機は、/closeout の後片付けチェックと意図的に非対称です。流入は「私は既に分離されているか？」という質問に答えるだけで済みます。汎用的な検出（toplevel ≠ プライマリ）とenv-varヒントがそれぞれこれを解決します。流出側の質問 — 「誰が後片付けを所有するか？」— はより厳格であり、汎用的なヒューリスティックだけに依存することはできません。パイプラインで作成されたワークツリーも toplevel ≠ プライマリを満たすためです。/closeout は明示的な設定またはホスト環境変数のみに基づきます。

1. 現在のブランチを確認します：git branch --show-current
2. 現在のブランチがベースブランチ（例：main、prod、master）の場合は、このタスク用に新しいフィーチャーブランチを作成します。
3. 現在のブランチが別のフィーチャーブランチ（ベースブランチでも、このタスク用に名付けられたブランチでもない）の場合は、以前の作業からの古いブランチにいます。ここに新しい作業をコミットしないでください。例外： 現在のブランチが、このタスクの Consumes from #N 宣言で指定された兄弟スライスブランチである場合は、積み上げPRスライスのためにそこからフォークしようとしているところです — 続行してください。例外（ホストプロビジョニング）： 上記の待機チェックが発動した場合、このブランチはホストの分離ワークスペースブランチです。古くありません。そのまま作業してください。

分離ブランチを作成するには、次のいずれかのアプローチを使用します（優先順位順）：

• Worktrunk（wt が利用可能な場合）：wt switch --create <branch-name> — 適切なベースから新しいワークツリー+ブランチを作成し、それに切り替えて、完全なファイルシステム分離を提供します。ガイダンスについては /worktrunk スキルを参照してください。
• Plain git：git checkout <base> && git checkout -b <branch-name> — 現在のワーキングディレクトリに、適切なベースから新しいブランチを作成します。

適切なベースは、デフォルトではリポジトリ自身のベースブランチです。bash "$SC" base-ref --name が出力するもの（SC はこのスキルの references/sidecar.sh に設定されます）。main を想定しないでください。このスライスがインポートするシンボルを生成する未マージの Consumes from #N 依存関係を持つスライスの場合は、代わりにその兄弟スライスのブランチからブランチを作成して、積み上げPRが兄弟のPRをターゲットにできるようにします（Hammant Trunk-Based Development 第13章：ストーリーごとに複数のPR。兄弟のPRは2日以内にリポジトリのベースブランチにマージされる必要があります）。

ブランチ名はタスクから派生させます。例：issue-5-landing-page、landing-page、またはIssueのスラッグ。以前の作業からブランチ名を再利用しないでください。

ワークツリーをセッションとして入力します（ワークツリーを作成した場合）。 ワークツリーを作成することは、セッションがその内部で実行されていることと同じではありません。wt switch --create は、各コマンドの後にシェルcwdをプロジェクトルートにリセットします。そのため、さらなるステップなしでは、セッションは元のチェックアウトに固定されたままであり、報告されるcwdは作業が行われている場所について嘘をつきます。ワークツリーを作成した後、ハーネス EnterWorktree ツールを使用してワークツリーを入力し、セッションのワーキングディレクトリが実際にワークツリーになるようにします。

• EnterWorktree { path: <absolute-worktree-path> } を呼び出します。パスは既にこのリポジトリの git worktree list に表示されている必要があります（作成したばかりなので表示されます）。これにより、セッションが永続的にワークツリーに切り替わります。
• 作成ステップは上記のままにします — wt switch --create / git worktree add は、.env.local と依存関係をシードするworktrunk pre-start フックを実行します。EnterWorktree はcwdのみを切り替え、これらのフックは実行しません。最初に作成（env/depsをシードするため）、その後に入力します。
• これにより、知識が頭の中ではなく世界に置かれます。cwdは編集とコミットがどこに着地するかについて真実を伝え（監視しているオペレーターがそれを確認できます）、忘れがちなコマンドごとの cd プレフィックスがなくなり、プレフィックスが付けられていない1つのコマンドが間違ったツリーに書き込むというスリップクラスが排除されます。
• Plain gitオプション（git checkout -b、ワークツリーなし）は、現在のチェックアウトにブランチを作成します。入力するワークツリーはないため、EnterWorktree をスキップしてその場で作業します。

AFK / ヘッドレスフォールバック。 EnterWorktree が利用できない場合（ヘッドレス実行、AFK Ralph、cron）、cwd-プレフィックス規律にフォールバックします。シェルcwdはすべてのBashコマンドの後にプロジェクトルートにリセットされるため、このセッションでのすべてのBash呼び出しの前に cd <absolute-worktree-path> && を付けます。これは、ハーネスツールが真に利用できない場合にのみ使用してください。これはネイティブメカニズムのない環境のために保持されている古い回避策です。

このワークツリーの後片付けは、パイプラインの末尾で /closeout が所有します。PRがマージされた後、/closeout はシェルをベースチェックアウトに再アンカーし、ワークツリーを削除し、マージされたブランチを削除します。/execute はワークツリーライフサイクルの流入側であり、/closeout は流出側です。以下のステップ6のクリーンアップは .tdd-* マーカーのみを削除します。ワークツリーは意図的に削除しません。

ワークツリーを作成したら、セットアップします。 新しいワークツリーは追跡されたファイルを継承しますが、git-ignoredなファイル（.env.local、ワークツリーごとの依存関係、ビルドキャッシュ）は継承しません。2つのパスがあります。

推奨 — worktrunkフックを介して一度設定します（プロジェクト内の .config/wt.toml）：

[pre-start]
copy = "wt step copy-ignored"
install = "pnpm install"

pre-start フックはブロッキングです。ワークツリーはそれらが完了するまで準備完了として報告されません。.env.local または node_modules を必要とする後続のコマンドがフックと競合するため、両方に post-start ではなく pre-start を使用します。完全なレシピについては /worktrunk を参照してください。プロジェクトごとに1回。

フォールバック — plain git worktree add の手動セットアップ（worktrunkなし）：

• cp <source-repo>/.env.local <worktree>/.env.local（およびプロジェクトで使用されるその他のgit-ignored設定）。
• ワークツリーからプロジェクトのインストールコマンド（pnpm install、npm ci、pip install -r requirements.txt など）を実行します。

ワークツリーセットアップチェックリスト（DO-CONFIRM — 各ステップを実行し、進行する前に確認します）。 ワークツリーが作成された方法に関係なく適用されます。

• Git-ignored設定がコピーされた — .env.local（およびその他の .env.*、*.local、またはプロジェクト固有の無視された設定）がワークツリーに存在する
• 依存関係がインストールされた — インストールコマンド（pnpm install、npm ci など）がワークツリーでエラーなく実行された
• セッションがワークツリー内にある — EnterWorktree { path } でワークツリーを入力したため、pwd はワークツリーパス（プロジェクトルートではない）を報告する。AFK/ヘッドレスフォールバックの場合のみ、この項目は代わりに cd <absolute-worktree-path> && プレフィックスがすべてのBash呼び出しに適用されていることを意味する
• $CLAUDE_PROJECT_DIR のスコープが正しい — プロジェクトがこの環境変数をスクリプトで参照している場合、プライマリリポジトリではなくワークツリーパスに解決されることを確認する
• ローカルgitフックがインストールされ、そのマネージャーが PATH に存在する — ls "$(git rev-parse --git-dir)/hooks/" | grep -v '\.sample$' が何かをリストし、リポジトリが宣言するマネージャー（lefthook、husky、pre-commit など）が解決される。フックは .git/hooks に存在し、これはワークツリーごとで追跡されないため、新しいワークツリーはそれらを何も継承しません。そして、障害は最悪の方向でサイレントです。すべてのコミットは成功し、リポジトリがコミット時に文書化するすべての保証は単に実行されません。マネージャーが存在しない場合は、インストールするか（lefthook install）、ステップ6のレビューノートに、このブランチではローカルゲートが非アクティブだったことを記録して、誰も緑色のローカル実行をマージゲートと誤解しないようにします
• 分類マーカーが存在しない — .claude/.tdd-active、.claude/.tdd-skipped、.claude/.lfg-active がワークツリーに存在しない（新しい状態。ステップ3で1つ作成される）
• レビュー後ロックフラグが存在しない — .claude/.review-stamped と .claude/.fix-findings-active が存在しない。両方とも以前のブランチのレビューに属します。/pre-merge フェーズ4が最初を書き込み、/fix-findings が2番目を書き込み、/closeout と /fix-findings がそれぞれそのブランチの最後にそれらを削除します。リークした .review-stamped は、このスライスが開始される前にすべての実装書き込みを拒否します。リークした .fix-findings-active はスライス全体にわたってロックを開いたままにし、これがサイレントな方向です。見つけたらどちらも削除してください。レビューを受けていないブランチの開始時点にいるため、どちらもこれを説明しているはずがありません

Issue形状とブロッカーゲート。 タスクがGitHub Issueの場合、実装する前にそれが取れるスライスであることを確認します。分解されていないPRDではなく、ブロックされておらず、他の誰かのオープンPRによって既にクローズされようとしていないこと。1回のGraphQL読み取りで3つすべてに答え、ブロックが決定します。いずれも目視で判断しないでください。

N=<n>
VERDICT_JQ='
def lines: split("\n")[];
[inputs][0] | if (.errors // [] | length) > 0 then "unknown" else
.data.repository.issue as $i
| if $i == null or $i.number != $n or (($i.title // "") == "")
     or ($i.state != "OPEN")
     or ($i.isPullRequest) then "unknown"

…

[翻訳のために切り詰められました]

(翻訳は元のMarkdownの完全な長さを維持する必要があります。ここでは切り詰められています。)