amberpixels/ship

f10 · ship

このスキルを実行することは、タスクのPRをプッシュ/作成/更新する（pr ステップ）こと、およびresolveの +reply の投稿、resolveの修正のそのPRへのプッシュ、reviewの f10 review ack の投稿、フロー内のCIレビューの場合の f10 review trigger（レビューセクションが手動での読み取り方法を宣言している場合）とresolveの f10 review settle の投稿、 pr 後のjudgeエントリの場合のキャッチアップガードの統合とそれ自身の変更のそのPRへのプッシュおよびステータスとコメントの投稿、そして実行のレポートバックコメントとステータスのタスクへの投稿（Report back）を、ユーザーが明示的に許可したことになります。 デプロイには独自の確認が必要です（deploy ステップ）。

引数

• --help: ${CLAUDE_PLUGIN_ROOT}/modes/help.md に従い停止します。以下は適用されません。
• --dry-run: 何も実行せずに ${CLAUDE_PLUGIN_ROOT}/modes/dry-run.md に従い停止します。 残りの引数がどのステップを実行するかを報告します。
• --driven: ${CLAUDE_PLUGIN_ROOT}/modes/driven.md に従います。以下のすべては引き続き実行されます。
• 単語としてのフロー名（/f10:ship direct: fix typo …; f10 start --local は /f10:ship local: <id> を送信、--flow <name> は <name>: を送信）、またはユーザーの言葉で命名されたもの：そのフローを実行します。 それ以外の場合は、frontmatterの flow_by_area がタスクのエリアにマッピングするフロー（取得した概要のエリア、それ以外の場合は計画の Areas 行）、それ以外の場合は default を使用します。 異なるフローにマッピングされる2つのエリア：Roleの場合と同様に、成果物のエリアが優先され、概要がもう一方を指定します。 エリアマップはプロジェクトの選択であり、あなたの選択ではありません：他のフローを自分で選択しないでください。ただし、小さな作業の場合は提案しても構いません。 最初のステップの前の1行で、エリアが選択したフロー名とエリアを指定します。
• --pace <name>: この実行のみそのペースでフローを実行します（ペース、以下参照）。指定がない場合は、ブランチが記録するペース、それもなければプロジェクトまたはユーザーの pace: を使用します。
• <plan.md>: 計画ファイル。それを使用してフローを実行します。
• <task-id>（プロジェクトID形式/ID/URL）、または + で結合されたバンドル（ABC-1+ABC-2、リードでキー指定）：何かをロードする前に、最初に ${CLAUDE_PLUGIN_ROOT}/modes/forward.md に従います。タスクを転送する場合は停止します。 それ以外の場合は fetch ステップを実行し、次に <storage root>/plans/<TASK-ID>.md（バンドルのリード）を探します（正確な名前が見つからない場合は plans ディレクトリをグロブします）。 見つかった場合：それを再利用し、再度尋ねることはありません。計画ファイルを持つタスクは二度と計画を立てず、再計画は手動で /f10:plan <id> を実行します。 見つからない場合：stale_after の下で、fetch はまず古いタスクを判断し、計画やフローエントリの前に実行をブロックして終了する場合があります（ステアリングの anyway はそれをスキップします）。次に、フローが plan で始まる場合（flow_by_area の場合、start と drive は計画を ship に任せます）、plan ステップを実行します。planless フロー（以下参照）はそれを決して実行せず、取得した概要がインラインプランになります。 次にフローを実行します。
• <description>: 自由テキスト。capture、fetch、plan ステップ、次にフローを実行します。
• 引数なし（フラグまたはフロー単語のみはなしと見なされます。説明は上記の自由テキストです）：この会話に既にあるタスク（保存された計画、取得されたタスク）、それ以外の場合はブランチのタスク、f10 task current が出力するID。 どのタスクをどこから取得したかを1行で示し、それを <task-id> として実行します（フォワードモードを含む）。保存された計画は再利用されます。 f10 task current が非ゼロで終了した場合：1行でタスクを要求し待機します（driven：modes/driven.md に従い要求します）。
• 件名以外の追加テキストはステアリングです。 resume at <entry>（キャッチアップが停止を解決した後に f10 drive によって送信される）は、そのエントリでフローを開始し、それより前のエントリを完了済みと見なします。(entry <n>) は、バッジのパイプラインでフローが2回名前を付ける場合の n 番目のエントリを選択します。 バッジはその場所に移動します：pipeline の後、1回の呼び出しで、その前の各エントリに対して順に set ship running を実行し、次にエントリ自体に対して実行します。

実行

1. このスキルが呼び出されるたびに、最初に f10-load-project.sh を実行し、入力が必要とするステップに名前を付けます：説明の場合は capture fetch plan、タスクIDの場合は fetch plan、計画ファイルの場合はなし。 フローはそれが出力する project.md で宣言されます。planless フローは plan をロードしますが、決して実行しません。
2. Arguments の項目で指定された順序でこれらのステップに従います。
3. 各フローエントリが実行される直前に、そのバッジとともに1回の呼び出しでロードします：f10-state.sh set ship running <entry>; f10-load-project.sh <step>、そしてそのロードからのステップに従います。 review エントリは review resolve をロードし、pr エントリは pr handoff をロードします（ただし handoff off ダイヤルが設定されている場合を除く）。pr ステップがハンドオフを実行するためです。キャッチアップガード（以下参照）は、ガードする各エントリのロードに catchup を追加します。

フロー は frontmatter の flows: で、順序付けられたエントリへの名前、またはスペースまたは矢印で分割された単一の文字列のリストです（plan judge implement cleanup:comments,prose pr review:ci deploy:staging）。宣言されていない場合のデフォルトは default: plan implement pr です。 f10 flow はそれらと各々を選択するものを一覧表示します。

ペース は選択されたフローを調整します（docs/project-setup.md → ペース）。 フローが選択されたら、f10 flow <name> [--pace <name>] を実行し、引数がペースを指定した場合のみ --pace を渡し、それが出力するエントリをその順序で実行します。frontmatter のリストは使用しません。 1行に1エントリを出力します。 skipped とマークされたエントリは実行されません：1行でその旨を伝え、バッジの pipeline から除外します。 エントリ後のダイヤルは、エントリとともにそのステップに渡されます：rounds と depth は review に、marker と handoff は pr に渡されます。judge の effort は、judge がエージェントを生成する場合（--blind）にのみ適用され、そのプロファイルは f10 agents judge から取得され、引数がペースを指定した場合は --pace <name> が付与されます。インライン judge はタスクエージェントのプロファイルで実行されます。 ペースが先頭の plan をスキップする場合、その実行は planless になり、plan のないフローと同様になります。 finish 行は、ペースがマージしていたであろうオープンPRで実行が終了することを意味します：ship はそれを決してマージせず、レポートの Next: は /f10:finish <id> --merge を指定します。ただし、drive がタスクを終了する場合を除きます（modes/driven.md）。 ペースがない場合、リストは宣言されたフローであり、オプションの既に解決されたCIレビュー（ci?）が含まれます。 名前を受け取るには古すぎる f10 flow は、その名前で失敗します：宣言されたフローを実行し、ペースが適用されなかったことを1行で伝えます。

エントリはステップ、または step:arg です：汎用ステップとそのオーバーレイ、またはプロジェクト定義のもので、引数が渡されます（review:local または review:ci はレビューの by（誰がレビューするか）を設定、review:host はホスト自身のコードレビューでローカルレビューを実行、review:local+ci は両方を1ラウンドと1つのresolveに統合、review:local+ci? はCIレビューが実行可能な場合のみ実行、f10 flow <name> はshipがエントリを見る前に ? を解決、cleanup:<targets> はクリーンアップターゲットで、常にフルパスが取得されます。ベアの cleanup は追加行が200未満の差分に対して軽量なものを実行します。deploy:<env> は環境です）。 実行は先頭の plan の後のエントリから始まります。plan は計画ファイルのないタスクに対してのみ実行されます。 resolve は決して名前が付けられません：review エントリがそれを実行します。 judge エントリは位置によって判定します：implement 前は プラン judge（件名 plan <id>）。その黄色の判定は計画ファイルをその場で修正し、コードを書きません。implement 後は 変更 judge で、黄色の判定の変更を自身でビルドし、judge ステップが pr の前後で示すようにルーティングされます。 pr エントリはブランチのPRを開くか、すでに開いている場合はそれを更新します。そのため、フローはレビューやjudgeの後に pr を再度指定して説明を最新の状態にすることができます。 先頭に plan がないフローは planless です：計画ファイルを書きません。チャット内の簡単なインラインプランが、保存されたプランが存在しない限り代役を務めます。 古いキー（pipelines、planless、drive_chain）も読み取られ、f10 init --migrate という名前の警告とともにフローに変換されます。古いエントリ形式 review (local) も同様です。 フリーテキスト入力はcaptureとfetchもスキップするため、実行にはタスクIDがありません。 タスクIDはfetchを実行し、実行をIDに結び付け（バッジ、レポート、ブランチ、レビューディレクトリ）、fetchが実行されたら f10-state.sh set plan skipped をマークします（保存されたプランを再利用する場合を除く、以下 prior 参照）。 そのインラインプランは、fetchが確定した種類を述べ、バグの再現手順と根本原因、リファクタリングの不変条件、またはスパイクの質問をそれぞれ1行で記述し、デフォルト値からの逸脱をリストします。 タスクIDがある場合、インラインプランはまた、計画ステップが行うように変更の意図を書き込みます（f10 lore add intent --change <change> -m <what and why>、docs/lore.md）。既存の意図、または追加の失敗は、レポート内の1行となり、失敗したステップにはなりません。 出荷 は最後の配信エントリのものです（conventions/context.md → shipment）：その行はそのステップが宣言するものであり、プロジェクト定義のステップの場合はそのオーバーレイの Shipment: 行です。その後の judge、demo、または handoff エントリは行を追加しますが、置き換えはしません。 表示するものがない demo エントリは、1行でスキップします（demo ステップ）。これは行を追加しない通常の終了です。

スパイクは implement 後に終了します、フローに関係なく：Kind: spike 計画は質問に回答し、そのコードはマシンから離れることはありません。 implement 後のステップは実行されません（クリーンアップ、コミット、プッシュ、pr、レビュー、judge、デプロイはなし）。出荷はスパイクレポートです。 最終レポートはそのクローズで終了します：f10 finish <id>。これは計画とレポートをアーカイブし、実験コードを破棄し、ワークツリー、ブランチ、ワークスペースを削除します。--keep は kept/ ブランチにコミットされた実験コードを保持します。 ドリブンスパイクはレポート内でクローズを必要としません：f10 drive はshipの後にそれをクローズします。 メインチェックアウトでは、f10 finish の前にレポートが指定するパスによって実験コードを破棄します。f10 finish はダーティなメインチェックアウトを拒否します。 そのレポートバック（以下参照）は、質問、回答、推奨事項を伝えます。スパイクレポートのパスは visibility: public の場合のみ指定します。ステルスは .f10/ パスをトラッカーから外すためです。 種類はフロー開始前に計画（またはplanless実行のインラインプラン）から判明しているため、バッジは f10-state.sh pipeline implement を宣言し、ドライランはimplementでカットされたパスを出力します。

キャッチアップガード は、キャッチアップステップの「ガードとして」 で説明されているように、3種類のエントリの前にベースを持ち込みます。catchup: off の下では統合は決して行われず、そのロードは catchup を除外しますが、コードのないベースに関する以下の質問は引き続き実行されます。 キャッチアップはフローエントリではありません。

• 実装前、f10 start --after または f10 finish がブランチにベースを記録した場合のみ（f10-after-branch または f10-landed）。f10 pr catchup --guard implement はそれ以外の場合 method: skip を出力します。 まだコードがないベースは、ガードの code: none 行であり、f10 drive がローカルまたはoriginにのみ保持されるベースに対して依存タスクを解放するルールです。統合する前に、一度尋ねます（AskUserQuestion）待機、または計画の前提で進める。 待機はブロックされた実行を終了します（f10-state.sh set ship blocked implement、ベースタスクを指定する note）。 進める場合は、計画ファイルに記録されたベースタスクの計画に基づいてビルドします。計画がない場合のフォールバックはありません。 ドリブンでは、何も尋ねられず、ship は決して進めません：f10-state.sh set ship blocked implement; f10-state.sh wait <base-id>; f10-state.sh note "waiting on <base-id>: its branch has no code yet" "rerun ship once <base-id> commits; f10 drive does it by itself"、その後レポート。 f10 drive はタスクを waiting on <base-id> として保持し、ベースがコミットすると再び resume at implement でshipを送信します。他のタスクは動き続けます。
• 全ての pr エントリの前（最初と各リフレッシュ）：まず f10 pr catchup --guard pr を実行し、フェッチして祖先を確認します。その method が merge、rebase、または onto の場合のみ、ツリーが保持するものをprステップが行うようにコミットし（conventions/context.md → コミット、--step implement）、統合して、プッシュがそれを運ぶようにします。 skip または none はコミットをprとそのアダプターに任せます。
• 変更 judge の前（implement 後の judge。プラン judge にはコードがありません）：ツリーに未コミットの作業がある場合（implement は作業を未コミットのままにするため、implement judge pr は常にいくつか存在します）、1行でスキップします。その judge は古いベース上のブランチを確認し、後の pr エントリのガード（フローに存在する場合）はコードが出発する前にベースを持ち込みます。 pr エントリの後は、強制プッシュせずに統合をプッシュするため、PRヘッドは judge されたコードとなり、judge のステータスはそれに着地します。

ガードは、それがガードするエントリの下で、そのエントリのロード（catchup pr）とバッジで実行されます。 失敗は set ship failed <entry>、または実行が耐久性のあるもの（ガード自身のコミットまたはオープンPR）を残した場合は partial であり（conventions/failure.md ルール7）、その state 行はそのコミットを指定し、note は catchup と /f10:catchup を指定します。 ガードは失敗する前にブランチをマークし（catchup ステップ）、f10 drive はマークされたブランチを自身でキャッチアップし、ベースが移動するたびに再度行い、その後このエントリで再びshipを促します。キャッチアップが何も変更しなかった場合、ベースが移動していない場合、または同じファイルが2回連続で競合した場合、ファイルを指定して停止します。 ドリブン実行の next は run /f10:catchup --driven in the worktree, then rerun the drive です：再実行はこのエントリで再びshipを促します。

フローのエントリを宣言された順序で実行し、各々を独自のロードから実行します。 この実行で書かれた計画は再確認を必要としません。 judge エントリはその判定によって実行をルーティングします：プラン judge は judge ステップの pr 前のルートが示すように機能し、その変更は implement がビルドするために計画ファイルに取り込まれます。変更 judge は pr エントリの前後で異なります（judge ステップ）。 変更 judge の変更は、pr の前後にかかわらず、計画に取り込まれ、judge ステップ自身のルートによってビルドされます（変更のビルド）。implement の再実行によるものではありません。

バッジ（conventions/report.md）：フローが選択されたら f10-state.sh pipeline <entry>...、plan 以降の全てのエントリをフローが指定する順に、各引数（pipeline judge implement cleanup pr review:local judge pr）。これにより最後が最終と宣言されます。各エントリの前に f10-state.sh set ship running <entry>、フローが指定する名前で、それをロードする呼び出し内で。最後の後に f10-state.sh set ship done。 以前の実行からの計画（計画ファイル、または再利用さ...