chrislacey89/closeout

closeout は何をしますか？

レビュー済みPRを受け取り、ワークスペースをクリーンなベースに戻します — マージ、シェルをワークツリーから切り離してから削除、マージされたブランチの整理、ベースのプル、最終状態の確認。これはパイプラインのテールです。最も繰り返される動作（「完了したのでマージしてクリーンなmainに戻して」）をユーザーの頭の中からスキルに移します。

なぜこれが存在するのか

/execute Step 0 はすべてのスライスに対してワークツリーを作成します。このスキルが存在するまでは、それを削除するものは何もありませんでした。ワークツリーは流入があり流出のないストックであり、ストックは際限なく増加します（Meadows, 『Thinking in Systems』 — 流入のみで流出のないストックに対する構造的な脱出方法は、より強く戒めることではなく、欠けているフィードバックループを追加することです）。マージ → 解体 → プルの順序はユーザーの記憶の中にしか存在せず、「予測的記憶は静かに失敗する」（Norman, 『The Design of Everyday Things』 — 知識を頭の中から世界に移しましょう）。その順序は実際にエラーを起こしやすいものです。シェルのカレントワーキングディレクトリがワークツリー内にあるまま削除すると、シェルは削除されたディレクトリに取り残され、そこからnode_modulesに依存するStopフックが発火すると、実際のリグレッションのように見えるMODULE_NOT_FOUNDの「lint/型エラー」の壁が表示されます。Step 4での削除前にベースにcdするという順序は、まさにそのミスに対する重要性の高い修正です。

このスキルは既存のツールをオーケストレーションします（gh pr merge、wt remove / git worktree remove、commit-commands:clean_gone）。ファイルシステムの状態を導入することはありません。クリーンアップが実行されたことだけではなく、結果 — クリーンなツリー、新しいベース上、PRがマージされたこと — を検証します（Meadowsの「間違った目標を追求する」：クリーンアップが「実行されたか」で測定される目標は代理目標を最適化し、もろい儀式を生み出します）。

呼び出し位置

これはプライマリパイプラインスキルであり、デフォルトのデリバリーパスのマージ → クリーンアップテールを所有します：

… → /pre-merge → /compound（PR内、レッスンが存在する場合） → /pre-merge（コンパウンドコミット上で再実行；再スタンプ） → [マージ + ワークツリー解体 — このスキル] → [イシュークローズ — Step 9 の散文]

以下の場合に/closeoutを使用します：

• /pre-merge がPRを作成し、レビューが完了している（または変更がレビューを必要としないほど些細な場合）
• PRが承認されマージ可能であり、マージしてワークスペースをクリーンなベースに戻したい場合
• ユーザーが「close out」「merge and clean up」「tear down the worktree」「get back to a clean main/base」と依頼した場合

以下の場合に/closeoutを使用してはいけません：

• PRがまだ作成されていないかレビュー中の場合 — まず/pre-mergeを実行します
• 永続的なレッスンを記録したい場合 — それは/compoundの役割であり、デフォルトでは/closeoutがマージする前にPR上で実行されています（マージ後の/compoundがフォールバックです）；/closeoutはレッスンを記録しません
• PRDとスライスイシューをクローズしたり、リサーチアーティファクトのフロントマターを調整したい場合 — それはSYSTEM-OVERVIEW.md Step 9のクリーンアップ散文の役割です；/closeoutはgitハイジーンの半分を実行し、イシュークローズとリサーチアーティファクトの置き換えの半分はStep 9に委ね、重複させません。このスキルが行う唯一のクローズは、sidecarバックエンド上のマージされたスライスのワークアイテムです（Step 3）。なぜなら、Closes #N行がない場合、マージ時にそれが行われないからです。
• 変更がそもそもフィーチャーブランチ上にない場合（マージするものがなくベースブランチ上にいる場合）— クローズアウトするものは何もありません

これはHITL確認済みであり、非ブロッキングです。すでにオプショナルなテールを運用化します。自動マージは決して行いません — マージは外向きで元に戻すのが難しいため、常に最初に確認します。

プロセス

これを確認付きTODOリストとして実行します（Gawande）：各ステップを実行し、次のステップの前にその結果を検証します。破壊的なステップ（4–6）は自己防御的です。実行前にStep 2の安全条件を確認します。

0. ホストプロビジョニングによる分離？ 最初に解体を譲る

マージ/解体シーケンスの前に、このリポジトリの分離がホスト所有（Conductor、Codespaces、devcontainers）かどうかを判断します。その場合、/closeout はGitHubネイティブのマージを実行しますが、ワークツリーの解体やローカルブランチの整理は行いません — ホストがライフサイクルのその半分を所有しており、それに抗うことはMeadowsのポリシー抵抗（同じストックを押す2つの主体）です。ワークツリーストックをホストに譲ります。

流出検出は/executeの流入チェックよりも厳格であり、汎用的な「toplevel ≠ primary working tree」ヒューリスティックだけを使用してはいけません：パイプライン作成のワークツリーもそのテストを満たすため、汎用的なシグナルでは「ホストが解体を所有する」と「パイプラインがこれを作成したので解体しなければならない」を区別できません。.claude/settings.jsonのworktree.provisioningから解決します（存在しない場合のデフォルトは`