ship

Ship

機能を、3つの対話型フェーズと4つの自律型フェーズで進めます。人による判断はすべて承認ゲートの前に収集し、その後はユーザーに尋ねるのではなく、複数モデルによる合意形成にエスカレーションします。このスキル自体にはフェーズに関する知識はありません。すべての動作は、参照先のスキルに委ねられています。

モデルのルーティング

フェーズ0の前に、呼び出しの意味から、パイプラインの各段階を特定のモデルまたはハーネスに割り当てているかどうかを判断します（「Xで計画し、Yで実装する」など）。これは意味に基づく判断であり、キーワードの照合ではありません。機能の内容、引用文、ファイル名に含まれるモデル名は割り当てではありません。各指示を、フェーズごとの実行モデルに解決します。

• スコープ付き（「Xで計画する」「実装にはYを使う」）の場合は、指定されたフェーズに割り当てます。複数のスコープ付き指示は、それぞれ個別に解決します。
• スコープなし（「Xを使う」「Yを使って」）の場合は、実装フェーズのみに割り当てます。計画やすべてのフェーズに拡大してはなりません。この割り当ては、冒頭の行で開示します（「実装はXにルーティングします。計画はセッションのモデルで続けます。」）。
• 強度はキーワードではなく、指示の意味から判断します。「実装にXを使う」は優先レベルです（利用できない場合はフォールバックし、そのことを目立つ形で開示します）。「Xだけを使う」は必須レベルです（ルートを利用できない場合、そのフェーズをブロックします。確認プロンプトは表示せず、黙ってフォールバックすることもありません）。

呼び出しに指示がない場合は、ローカル設定の work_engine_preferences（shared/references/local-config.md）で、フェーズごとの既定値を確認します。明示的な指示は常に既定値より優先され、その mode: off|prefer|require は上記と同じ強度ルールに対応します。どちらもない場合、すべてのフェーズでセッションのモデルを使います。

フェーズ0〜2やレビュー入力に入る前に、ルーティング指示を機能リクエストからすべて取り除きます。実行モデルはフェーズごとのルーティング権限であり、プロダクトの内容ではありません。

ローカルのみのモード

実行の開始時に git remote を一度実行します。リモートがない場合、実行全体をローカルのみのモードにします。各フェーズで指定されているコミットはすべて作成しますが、プッシュ、PR の作成・編集、CI の試行はすべて省略します。再試行は一切せず、リモートも探しません。リモートの欠落は終端状態であり、エラーではありません。ローカルのみのモードでは open-pr を呼び出さないでください。フェーズ6は、ローカルのコミット、コミット済みの残存調査結果の記録、引き継ぎメモで終了します。

委任

あなたは薄い指揮役です。ユーザーの対応が不要な各フェーズはそれぞれ独自のサブエージェントで実行し、フェーズ間で受け渡すのは段落ではなくファイルです。契約は shared/references/handoff-contract.md（概要 → レポート → エンベロープ）です。各ステーションのバインディング、つまり各ワーカーが呼び出すもの、読むもの、引き継ぐものについては、references/station-dispatch.md を参照してください。フェーズ 3 の前に読んでください。

ペイロードではなくパスを引き渡してください。 コンテキストに保持するのは、実行状態のパス、現在のスライス ID、完了した各ステーションにつき 15 行以内のエンベロープ 1 つです。PRD 本文でも、差分でも、調査結果の一覧でも、ステーションの記録でもありません。詳細をもとにあなた自身が判断しなければならない場合に限り、レポート本文を開いてください。たとえば、revise の振り分け、最終レポートの作成、見解が異なる 2 つのステーションの調整などです。

分割位置の理由：

• フェーズ 0～2 はあなたのコンテキストで実行します。 ユーザーに質問できるのはあなただけであり、フェーズ 2 の承認ゲートが人間との最後の接点だからです。永続的な成果物はすでに存在します（トラッカーまたはリポジトリルートのファイルにある PRD、issue または TASKS.md にあるスライス）。書き込みが済んだら、パスを示して作業上の詳細は破棄してください。
• フェーズ 1 の根拠確認は、いずれにせよ委任します。 CONCEPTS.md、ADR、コードを読むのは入力の収集であって、会話ではありません。読み取り専用のワーカーが、リポジトリですでに回答されている質問を返すことで、それらがユーザーに届かないようにします。
• フェーズ 3～6 は、スライスごとにステーションあたり 1 人のワーカーで実行します。 ゲート以降はユーザーの対応は不要です。判断が分かれた場合は models-consensus に委ねます。
• ステーション内の各役割は、ランナー CLI を介して実行します（discover_runners.py probe --native-agent no）。ワーカーは Agent ツールを入れ子にして使えるとは限らないためです。

ホストにサブエージェントツールがない場合は、ステーションをインラインで実行します。ただし、引き続き概要とレポートを書き、最終レポートにワーカーを起動しなかったことを記載してください。ファイルベースの受け渡しによってコンパクション後も情報が残り、分離を実現できるかどうかはホスト次第です。

パイプライン

フェーズ	モード	実行場所	呼び出し
0. 構想	対話型、任意	メイン	brainstorm（漠然としたアイデア — 重大な意思決定を伴う複数モデルでの探索にはパネルモード）；prototype（設計上の不明点を、実行コードでしか解決できない場合）
1. 仕様策定	対話型	メイン（＋委任による根拠確認）	読み取り専用のワーカーが、用語集、ADR、コードに照らしてリクエストの根拠を確認し、01-grounding.report.md を作成します → 次に、そのレポートを参照しながら interview をインラインで実行し、その後 to-spec を実行します。重要度が高い場合や意見が分かれる場合は、両方をパネルモードで実行します。interview は仕様策定時の security-gate チェックリストを実行し、テストの境界を明示します。to-spec はそれらを PRD の Security Decisions と Testing Decisions に記録するため、フェーズ 2 で両方を取り込めます。
2. 計画	対話型 — 最後の人間による承認ゲート	メイン	to-tasks（各タスクのテスト計画とアーキテクチャのマッピングが必要な場合はパネルモード）。Slice Contract には acceptance と gates がネイティブに含まれます。ユーザーが作業の分割を承認します。
3. 設計ゲート	自律型、タスクごと	サブエージェント	coding-design-plan の後、スライスのレンズフラグを指定して design-gate
4. 実装	自律型、タスクごと	サブエージェント	スライスごとに implement-and-review を実行 — Slice Contract をネイティブに取り込み（acceptance が完了ゲートになり、gates がレンズを選択します）、プッシュは行いません。代替手段：記録された複数モデルによる監査証跡が必要な場合は collaborative-delivery、単純な単一トラックのスライスには直接 tdd（テストされていないレガシーコードでは、最初に safe-incremental-coding を実行）。作業中に見つかったバグには diagnose を実行します。
5. 検証	自律型	サブエージェント（1つ、チェーン全体を担当）	順序どおりに実行し、失敗時は即時停止：受け入れ条件を実行 → coding-review-simplify（コンテキストが新鮮なうちに自己簡素化）→ full-review（security-gate によってフラグが設定されている場合は、徹底したセキュリティレビュー）→ Web 向けの変更ではパイプラインモードで browser-smoke、それ以外ではハーネスの run チェック。複数モデルによるゲートでは最終コードをレビューします — その後に、レビューを経ていない変更を伴うパスを実行してはいけません。失敗した場合は diagnose を介してフェーズ 4 に戻ります。
6. 提出	自律型	サブエージェント	コミットし、未適用のレビュー指摘を references/residual-findings.md に従って後から参照できる形で記録し、open-pr で PR を作成（ローカルのみのモードでは省略）、イシューのトリアージラベルを更新し、session-handoff で継続性メモを保存（本文は summarize のコールドスタートテストに従います）。さらに、実行によって自明でない問題が解決された場合は、ヘッドレスモードで capture-learning を実行します。マージは人間が行います。コメントが届いたら、resolve-pr-feedback でレビュー後の対応を完了します。

入力がすでに PRD または承認済み仕様書である場合は、フェーズ 0〜1 を省略します。承認済みのスライスがすでにある場合は、フェーズ 3 へ進みます。

スライス契約

Slice Contract — 機械的に検証可能な acceptance コマンドと、design-gate および security-gate 用の gates フラグ、HITL/AFK の分類（HITL を先にスケジュール）、ready-for-agent / TASKS.md の作業キュー — は to-tasks で定義されています。フェーズ 2 ではこれを含むスライスを作成する必要があります。フェーズ 3〜6 ではこれを使用します。

自律ループ

準備完了のスライスが複数ある場合は、スケジューリングを implement-feature に委任します。このスキルは、並列ワークツリー、統合ブランチへのリベース、機能全体のシームレビューを使って依存関係 DAG を実行し、タスクごとに implement-and-review を呼び出します。スケジューリングは指揮者の役割であり、ステーションの役割ではありません。implement-feature はあなたのコンテキスト内で実行され、スライスごとのステーションワーカーを自らディスパッチします。ゲート後にステーションのサブエージェントでラップされないスキルはこれだけです。スライスが 1 つの場合は、委任のセクションに従って、worktree スキルで作成した分離ワークツリー（まずハーネスネイティブの分離を使います。ハーネスから見えないワークツリーは決して使わないでください）で、フェーズ 3〜6 を自分でディスパッチします。

ブロックされたスライス（ハードストップでエスカレーションラダーを使い切った場合）については、その理由を記録してスキップし、ブロックされていないスライスを続行し、最終レポートにブロックされたスライスをすべて列挙します。ステーションへの委任によって、スライスごとの作業はすでにあなたのコンテキストから切り離されています。それでも実行がその範囲を超えるほど大きくなった場合（多数のセッションにまたがる多数のスライスなど）は、dynamic-harness のマネージャーモード（同じ引き継ぎ契約、ミッションスコープの台帳）に移行するか、肥大化したコンテキストウィンドウで品質を落とすのではなく、session-handoff ノートを残してセッションを終了します。

実行状態

ループはコンパクション、再起動、並列ワークツリーをまたいで進むため、進捗は文字起こしではなく、台帳に記録します。shared/references/run-state-contract.md に従って、スライスごとに 1 つの実行状態を保持してください。今回の実行に固有の設定は次のとおりです。

• phase はパイプラインのフェーズ番号であり、完了するたびに steps に追加されます。再開したスライスはフェーズ 0 ではなく、phase から再開します。フェーズ 3〜6 はコストが高く、その出力はすでにディスク上にあるためです。
• 委任された各ステップのエントリーには brief と report のパスが記録されているため、実行を再開すると、ステーションの番号だけでなく、その推論も復元できます。レポートが存在するステーションは完了しています。再ディスパッチするのは、その status が失敗を示している場合だけです。
• ユーザーが内訳を承認した時点で、フェーズ 2 の承認を gates に記録します。これは最後の人的ゲートです。そのため、再起動時に gates で承認を確認できなければ、承認済みと決めつけず停止して確認を求めます。承認が確認できた場合は、決定済みとして扱い、再度確認しません。
• コミット、PR、登録したチケット、残存項目の記録には、それぞれ side_effects キー（commit:<slice-id>、pr:<branch>、ticket:<finding-id>）を割り当て、処理を実行する前に書き込みます。再開したスライスでキーが見つかった場合は、重複を避けるため、その処理をスキップします。これにより、再実行のたびに残存項目のチケットが二重に登録されるのを防げます。
• スライスの上限をあらかじめ宣言し、各スライスは必ず次の3 つの終了状態のいずれかで終了させます。complete、failed（ハードブロックまたはエスカレーションラダーの終了）、ceiling_hit。ブロックされたスライスも記録する終了状態であり、黙ってスキップしてはいけません。

エビデンスゲート

フェーズ 4 で動作変更が報告されたにもかかわらず、一貫した検証エビデンス（どの既存テストを調査したか、どのテストを追加または実行したか、何が確認できたか）がない場合は、実装済みの作業からエビデンスを整理するリカバリーモードで、実装ステージを同じスライス、同じスコープのまま、ちょうど 1 回再実行します。再実装はしません。「ちょうど 1 回」とは、上限を 1 とする attempts.evidence_recovery のことです。再実行の前に実行状態でこの値を増やします。再試行を決めるのはモデルではありません。そのため、リカバリー中に実行がクラッシュしても、新たな試行が与えられることはありません。2 回目の結果にも一貫したエビデンスがない場合は、そのスライスをハードブロックします。未検証の動作について、検証やデリバリーに進んではいけません。そのスライスは、ブロックされたスライスとともに最終レポートに記録します。

残存事項

適用されなかったフェーズ 5 のレビュー指摘は、スライスが完了する前に永続化する必要があります。references/residual-findings.md に従い、検出されたシンクを通じてトラッカーチケットを起票してください（利用可能かどうかは実行ごとに一度確認してキャッシュし、構造化された {filed, failed, no_sink} の結果を返します）。必ず docs/residual-review-findings/<branch-or-head-sha>.md の記録をコミットし、起票済みチケットにはベストエフォートで PR URL を追記してください。残存事項を PR 本文の台帳として追跡することは決してありません。PR の契約における決定ログに記載するのは前提であり、レビューの残存事項ではありません。

エスカレーション手順（途中での質問に代わるもの）

自律的なフェーズで、意見が分かれる判断や取り消せない判断が必要になった場合：

1. 定型的なエスカレーション向けの予算プリセットを指定し、--auto を付けて models-consensus をポーリングモードで実行します。複数モデルによる検討でユーザーへの問い合わせに代えます。検討のみを行い、実装は開始しません。
2. それでも解決しない場合は、最も取り消しやすいデフォルトを選び、前提とその根拠を決定ログに記録して PR 本文に引き継ぎ、作業を続行します。
3. 破壊的または取り消せない操作（データ削除、強制プッシュ、外部への公開、実データに対する不可逆な移行）の場合に限り、作業を停止して人間の判断を待ちます。

PR の契約

PR の作成は open-pr の役割です。作業を委任してください。Ship は、必須のパイプラインセクションを本文に追加します。内容は、受け入れの証拠（実行したコマンドと出力）、設計ゲートの判定、レビューの要約、注意事項を明示した決定ログ、および残存リスクです。結果は忠実に報告してください。失敗またはスキップされたチェックは明記し、取り繕ってはいけません。

注意事項

1. 時間を節約するためにフェーズを省略しないでください。ゲートが品質を担保します。
2. ハードストップの場合を除き、フェーズ 2 の承認ゲート以降にユーザーへ質問しないでください。
3. フェーズの動作をここに書いたり、インラインで記載したりしないでください。知識を一元管理できるよう、参照先のスキルを呼び出してください。
4. ブロッカーが未解決のスライスでは、フェーズ 4 を開始しないでください。
5. ワークツリー内で受け入れコマンドが成功していないスライスを完了扱いにしないでください。
6. ローカルのみのモードでは、プッシュや PR 操作を再試行しないでください。git remote の確認は一度だけ行い、その結果で実行全体を判断します。
7. ルーティング指示が仕様、計画、レビューの入力に混入しないようにしてください。フェーズ 0 の前に除去します。
8. full-review の後に変更を伴う処理を実行した場合は、必ず再実行してください。このゲートは最終コードをレビューします。
9. 状況を把握するために、ステーションのレポート本文を読まないでください。インターフェースはエンベロープです。委任で節約できるコンテキストを、すべてのレポートを読むことで使い切ってしまうことになります。
10. レポートの内容を次のステーションへのブリーフに貼り付けないでください。パスまたはレポート内の見出しを示してください。詳細が必要なワーカー自身がファイルを開きます。

---

モデルルーティング、ローカルのみの実行、証拠ゲート、残存事項の永続化に関する契約は、Every の compound-engineering-plugin（lfg）をもとにしています。