execute-common

Execute-family コントローラーレシピ

build-in-waves、build-by-story、build-inline で共有するコントローラーの手順とランタイム状態を1か所に集約します。タスクのディスパッチとレビューについては、このファイルと同じ場所にある task-lifecycle.md を参照してください。そのスキルの Setup または After-last で指示されたときに読み込んでください。npx skills add が Execute ファミリーとともにこのファイルをコピーするように登録されています。

セッション開始前の確認

ディスパッチ、isolate-workspace / git worktree add、および最初の本番コード編集を行う前に、次の3点を確認します。

1. イシュートラッカーの同期。 まず docs/agents/issue-tracker.md を開きます。トラッカーが記載されている場合は、このファイルと同じ場所にある tracker-sync.md を読み、記載どおりに厳守します。オペレーターが指定したチケットは、ディスパッチの前にここで担当として登録します。ある俳句ビルドでは #23 のチケットについてファイルを一度も開かなかったため、チケットは担当登録されず、その PR でもクローズされませんでした。ファイルがない、またはトラッカーが記載されていない場合は、チケットセットを空にして続行します（未設定は通常の状態であり、失敗ではありません）。

2. カタログの占有状態。 requirements.md の Status: と、対応する docs/specs/INDEX.md の行を読みます。INDEX がない場合は、そのことを一度伝えて /configure-repo を提案します。それでも requirements.md が存在する場合は、引き続き書き込みます。 land-branch / realign-spec は Implemented を担当し、cut-release は Shipped を担当します。コンパクション後の再開を含め、毎回の開始時に実行します。

   カタログのステータスが `Approved` の間は、ワークスペースの分離も本番コードの編集も禁止です。 先に分離する、書類作業を省略する、カタログファイルをコミットしない、といったユーザー指示があっても、この手順は省略できません。

   ステータス	アクション
   Approved	このチェックアウトで両方のファイルを In-progress に変更してから続行します。
   In-progress	すでに占有されています。再度記録しないでください。続行します。
   Draft	停止します — 仕様は承認されていません。
   Implemented / Shipped	そのままにします。開始時の記録対象ではありません。

   分離する前に、この機能に関するこのチェックアウトの変更済み仕様ファイル（requirements.md、design.md、tasks.md、INDEX の行）をコミットします。ステータスが Approved の場合は、占有状態の書き込みもこのコミットに含めます。ワークツリーは HEAD から作成されるため、未コミットの仕様ドキュメントは残されたままとなり、新しいツリーや他のセッションから見えません。isolate-workspace で .gitignore をコミットしてはいけない点は変わりません — 占有状態の記録はこの手順で行い、そのスキルでは行いません。

3. ワークスペース / ブランチ。 まだ分離されたワークスペースがない場合、ワークツリーで分離するのか、現在のブランチで実装するのかを確認します。頼まれていないのにワークツリーを作成してはいけません。分離する場合 → 必須サブスキル：isolate-workspace を使用します。現在のブランチが main/master の場合、実装前に別途明示的な同意が必要です。「ワークツリーは使わない」は、main/master を変更する同意ではありません。

完了条件：トラッカーの選択（または空のチケットセット）が明確で、占有状態が In-progress（または Draft / Implemented / Shipped による明示的な停止）であり、このチェックアウトに機能関連の未コミット仕様変更がなく、ワークスペースの選択が明確であること。

考え違い	実際の動作
「セッション開始前の確認はトラッカーとワークスペースだけ」	占有状態は2番目の確認事項で、ワークスペースは3番目です。In-progress になっていることが完了条件に含まれます。
「main でのドキュメントのコミットこそ、禁止されたことだ」	他のセッションはこのチェックアウトの INDEX を読みます。分離は記録より先に行ってはいけません。
「占有状態はワークツリー / 機能ブランチを見れば明らかだ」	このチェックアウトで動作するセッションは、依然として Approved を読み取ります。INDEX が占有状態のシグナルです。
「後で land-branch が Implemented に変更する」	Implemented はクローズ時の状態です。In-progress は作業開始時の状態で、ワークツリー作成前に設定します。
「リリースするまで INDEX が Approved のままでも問題ない」	他のセッションには、このコードが実行中だと分かりません。タスク1の前に状態を記録します。
「ワークツリーを使わないなら、書類作業は省略する」	分離を見送っても、占有状態の確認は省略できません。
「すでに In-progress だから、すぐに分離する」	まずステータスを読みます。書き込みは省略しても、確認は省略しません。再開時も分離の前にステータスを読みます。
「ユーザーがドキュメントのコミットを禁止した / 先に分離するよう指示したので、占有状態の記録より優先される」	占有状態の記録は省略できません。このチェックアウトで In-progress を確認するまで、分離は待ちます。
「仕様ファイルはディスク上にあるので、ワークツリーから見える」	git worktree add は HEAD をコピーします。未コミットの requirements.md / 仕様3点セットのファイルは残されたままになります。

ランタイムバインディングとリースの事前確認

最初のディスパッチ前に（インラインルートでは、最初の本番編集前に）、 このファイルと同じ場所にある runtime-binding.md を読み、記載どおりに 正確に従ってください。.skills/<CODE>/execution-session.json のスキーマ （schema_version、harness、provider、model、resume/fork/worktree のサポート、 cache_control、token_telemetry、pricing_policy、effective_concurrency、rotations）、 4 つのリースローテーションのトリガー、pricing-policy のフォールバック、 同時実行数の低下ルールが定義されています。

完了条件：ディスパッチ前にランタイムスナップショットが存在し、利用できない 機能がすべて明示され、最初に適用される同時実行数／リースの判断が記録されていること。

台帳の確認

このファイルと同じ場所にある ledger-check.md を読み、記載どおりに正確に 従ってください。.skills/ はローカル専用のままにし、.skills/<CODE>/progress.md から再開し、タスクゲートの判定基準となる lint のベースラインを記録し、 Verified: 欄は prove-claim のものとします。

完了条件：次のタスク／ユニットが分かっており、Lint baseline: が記録されていること。

判断の記録 — 条件に応じて確認

ユーザーが判断の記録／作業内容の提示を求めた場合、または無人で一晩以上／ 複数日にわたり実行する場合、または複数の未完了ユニットがある状態で effective_concurrency が 1 を超える場合は、このファイルと同じ場所にある decision-trail.md を読み、記載どおりに正確に従ってください。それ以外の場合は、 Close notes に skip: no decision-trail predicate と記入してください。

Todo — 必須

ディスパッチまたは Task 1 の前に、表示されるリストを用意してください。 ハーネスに todo／タスクリストツールがある場合はそれを使用し、ない場合は返信に チェックリストを記載し、各タスクの区切りで再掲してください。タスクごとに todo を 1 つ、さらに終端の todo として Close branch を 1 つ用意します （以下のクローズ手順。後回しにせず、今作成してください）。磨き込みの条件が すでに満たされていることが分かっている場合（ユーザーが最初に依頼している場合） に限り、Polish Diff todo を追加してください。それ以外の場合は、クローズ手順の ステップ 3 で条件が満たされていれば、その時点で Polish Diff todo を作成してください。

完了条件：リストが計画と一致し、Close branch todo が含まれていること。

クローズ手順

最後のタスク（ウェーブ／インライン）または最後にロック解除されたユニット（ストーリー）の後：

1. ブランチ全体のレビュー。 必須サブスキル：inspect-change を使用し、base には git merge-base <branch-base> HEAD を指定してください。ブランチ途中の sha は使用しないでください。 <branch-base> は main、またはチケットが別のブランチに積み重ねられている場合はブロッカーのブランチです（deliver-issues）。積み重ねられたチケットを main に対してレビューすると、ブロッカーの差分も再レビューされ、その差分のファイルも仕上げの対象として数えられます。 台帳に Minor を記録してください。最上位のモデル階層を使用してください。
2. 見つかった項目全体に対して修正担当を 1 人割り当て → 再レビューします。項目ごとに修正担当を割り当ててはいけません。インライン方式では、test-first のもとであなたが修正担当になります。
3. 差分の仕上げ — 条件を明示して判定。 以下の仕上げ条件を評価してください。いずれかの節が真なら → 受け入れ前にブランチ全体の差分に対して polish-diff を使うことが必須です。存在しない場合は今すぐ Polish Diff の todo を作成し、スキルの実行後にのみ完了にしてください。いずれの節も真でない場合は → 省略し、Close branch のメモに skip: no polish predicate と記入してください。EOD、デモの時間的制約、「inspect に問題がなかった」、「省略してもよさそうなほど小さい」は、条件に該当しません。
4. 受け入れ。 必須サブスキル：validate-feature を使用してください。失敗した場合は → root-cause を行い、合格したチェックをドメインの動作を説明するコミット済みテストに昇格させてください（docs のみの構成では、テストファイルに要件 ID タグは不要です）。
5. クローズ記録。 close-receipt.md を読み込み、その生成手順に従ってください。最後の変更後にのみ発行し、その HEAD に結び付いた証拠に基づいて発行してください。証拠が欠落または古くなっている場合にのみ、生成処理を再実行してください。
6. 完了。 必須サブスキル：land-branch を使用してください。

手順 1～6 をそれぞれ実行するか、該当する条件のもとで省略した後にのみ、Close branch todo を完了にしてください。

考え	実際
「タスクの todo はすべて完了している — クローズは後回しでよい」	Close branch todo はまだ未完了です。この手順を実行するまで land はブロックされています
「Inspect で問題なし／ブランチが小さい — 仕上げは省略」	Inspect に問題がなかったことや「小さく感じる」ことは条件ではありません。ファイル数を数え、公開 API を確認し、inspect の残件を読んでください
「EOD／デモ — 40 ファイルのブランチでも仕上げは省略」	時間的制約は条件ではありません。ファイル数が条件です
「忘れないように、常に仕上げを実行する」	3 ファイルのタイプミスに対する 4 つのクリーンアップエージェントは、この条件付き手順によって削減したいコストです。省略する場合は必ず記録し、無言で省略してはいけません

クローズ手順の条件

仕上げ — 次のいずれかに該当する場合に真です：ユーザーが polish、cleanup、または tidy を依頼した場合、inspect-change の Standards 残件に、動作を維持する Important 以上の指摘（再利用、デッドコード、不要な複雑さ、無駄な I/O）が含まれる場合、git diff --name-only $(git merge-base <branch-base> HEAD) HEAD が15 ファイルを超えるファイルを列挙する場合、ブランチで新しい公開 API またはエクスポート対象のサーフェスを追加する場合。

危険信号 — 絶対に行わない

• tracker-sync、occupancy、または workspace preflight を省略する
• カタログの Status がまだ Approved の間に、本番ファイルを隔離または編集する
• 今回のセッションで作成した worktree 内だけに In-progress を記入する
• すでに In-progress の行に再スタンプする
• このチェックアウトに未コミットの仕様／要件の変更が残っている間に隔離する
• 設定がない場合やユーザーが断った場合に、tracker またはチケットセットをでっち上げる
• 明示的な同意なしに main/master で実装を始める
• 尋ねずに worktree を作成する、または「現在のブランチ」を main/master に対する同意として扱う
• todo リスト（タスクと Close branch の両方）ができる前に、最初のタスクを割り当てる
• 仕上げを無言で省略する（skip: no polish predicate の記入がない）
• decision-trail を無言で省略する（省略または必須の記載がない）
• EOD、デモ、または「inspect に問題がなかった」を仕上げの条件として扱う
• Close branch todo が未完了のまま land-branch に進む
• 不完全な記録を作成する、または最後の変更より前の証拠に結び付ける
• チェックを「ID タグ付きテスト」として昇格させる — ID は docs に記載する