パイプラインを実行する
あなたはパイプライン実行を開始または再開します。$1 は実行するパイプライン — ./.pipeline/ 配下のフォルダです。(v1パイプラインはイテレーションファイルのパスで指定される場合があります。「前提条件」を参照)。
あなたが行うこと
あなたはメインセッション (深度0) で実行されるスーパーバイザーです。自分でイテレーションをループすることはありません。代わりに、単一の**pipeline-manager**サブエージェント（深度1）を起動し、チェーン全体を駆動させます。このサブエージェントは、イテレーションごとに新しいstep-executorを起動し、ステップ間でpipeline-improver / pipeline-script-creatorを実行し（駆動するpipeline next CLIがイテレーションごとのUIイベントを自動発行し、外部worktreeフックを自ら実行します）、実行完了時、停止時、またはスコープ外のブロッカーに当たった時点で構造化レポートを返します。
あなたは深度0に留まります。なぜなら、以下の3つの作業はメインセッションで実行される必要があり、サブエージェントでは実行できないからです：(a) 実行のlivenessロックファイル用に安定したpidを所有すること、(b) 外部条件（ブロッカーとなるPRのマージ）を何時間も待機して再開すること、(c) 最終的に人間に結果を提示すること。したがって、あなたの仕事は次のとおりです：実行IDを発行する（または、--resumeを使用して既存のIDを再利用する — 「再開手順」を参照）、UIトラッキングを設定する、マネージャーを起動する、そしてそのレポートに基づいて行動する — これにはネストされたブロッカーのポーリング待機と、マネージャーを再起動して実行を再開することが含まれます。
重要 — トークン節約のため、ほとんど読み取らない
このスキルはスーパーバイザーであり、リーダーではありません。すべてのイテレーションファイルは、それぞれ独自のコンテキスト内でstep-executorによって読み取られます。ステップごとのモデル解決はpipeline-manager内部で行われます。
- イテレーションファイル (
steps/**/*.md) を決してReadしないでください。 フロントマターも含め、決して触れてはいけません。マネージャーがステップごとのモデルを解決します。あなたはパイプライン全体のデフォルトのみを渡します。 PIPELINE.mdは、チェーン開始時に一度だけ、フロントマターのみ (limit: 50) 読み取り、model:フィールドをpipeline_default_modelとして抽出する以外には使用しません。その内容をマネージャーに渡してはいけません。--resume時は、この読み取りを完全にスキップします —pipeline_default_modelは既存の実行の永続化されたnext.json.default_modelから取得されます（「再開手順」を参照）。これにより、再開時に、next.jsonの読み取り（current_iterationのために既に必要なもの）に加えて、マニフェストの読み取りが追加されることを防ぎます。- 完全に
Readしてよいファイルは、自分でネストブロッカーフロー内で書き込んだファイル（Issue本文、部分作業メモ）と、--resume時の小さな.runtime/*/next.jsonオーケストレーションカーソルファイルのみです — イテレーションファイルやPIPELINE.md本文は決して読みません。
ランナー選択 (実験的)
4つのモードが存在し、pipeline nextがすべてのモードで次に何を実行するかを決定します (E1) — それを呼び出すループではありません。 それらはループが存在する場所と1つのステップを実行するものだけが異なります：
| モード | ループの存在場所 | 1ステップを実行するもの |
|---|---|---|
session | このメインセッション | Agentツール、セッション内 |
manager (デフォルト) | pipeline-managerサブエージェント | Agentツール、セッション内 |
driver | このプラグインが所有するプロセス、ループ内にモデルなし (pipeline drive) | ステップごとに新しいclaude -pプロセス |
standalone | driverと同じ所有プロセス | あなた自身のAPIキーを使用するAgent SDK — Claude Codeセッションは一切なし |
driverとstandaloneは、ループを共有し実行者のみが異なるため混同されがちです。どちらもpipeline driveと混同しないでください。pipeline driveはdriverパスのコマンド名であり、そのモードの同義語ではありません。このバンドルされたCLIは、session、manager、driverを実装しています — v1パイプラインはPIPELINE.mdフロントマターでdriverをrunner: headlessと記述します（下記参照）。standaloneおよびpipeline.ymlレベルのrunner:キーは同じ4モード設計に属しますが、このバンドルされたコピーにはまだ配線されていないため、ユーザーに今日実行できると伝えてはいけません。
runner: を手順3のmodel:読み取りと一緒に解決します。 v2パイプラインではpipeline.ymlのトップレベルキーです — そこで^runner:をGrepします。これにより1行が読み取られ、ステップファイルが開かれることはありません。v1ではPIPELINE.mdフロントマター内にあり、model:のために読み取る≤50行に既に含まれています。存在しないか読み取り不能 ⇒ manager、今日の動作であり、意図的なデフォルトです (E10)。宣言されているが以下の分岐がない値もmanagerを実行します — ただし、開始する前に1行でその旨を伝えてください。これは、マニフェストが宣言していないモードは、作成者が選択していないモードだからです。チェーン長からモードを推測してはいけません。目に見えないしきい値により、1つのコマンドが2つの方法で動作することになります。
runner: session — メインセッションがループ自体を実行する
pipeline-managerを起動してはいけません。セッションループを読み、手順5.1〜5.3の代わりにそれに従ってください。このファイルの他のすべて — 手順1〜4、再開手順、ネストブロッカーフロー、スーパーバイザーの不変条件とレポート形式 — は変更せずに適用されます。なぜなら、あなたは依然として深度0のスーパーバイザーであり、ループを委譲する代わりに吸収しただけだからです。
そのファイルは、このモードが必要とする2つの事前チェック拒否（pipeline next --brief-fileには古すぎるCLI、およびexecution: parallel — そのペイロードはセッションが開いてはいけないbriefに存在します）を伝え、トレードオフについて正直です：すべてのアクションおよびすべてのステップレポートがユーザーの監視するコンテキストに表示されるため、長いチェーンはmanagerに属します — これこそがmanagerが依然としてデフォルトである理由です。
runner: headless (v1) — driver モード
パイプラインがv1であり、model:のために読み取ったPIPELINE.mdフロントマターにrunner: headless（driverモードのv1での記述 — 上の表を参照）も含まれている場合、pipeline-managerを起動してはいけません。代わりに、バンドルされたドライバーをバックグラウンドプロセスとして実行し、監督します：
bun "${CLAUDE_PLUGIN_ROOT}/apps/pipeline-cli/src/cli.ts" drive \
--root "<pipeline_root>" --run-id "<run_id>" [--start "<step-name>"] \
--default-model "<pipeline_default_model-or-null>" \
[--default-effort "<level-or-null>"] \
[--model "<step_id>=<model>" ...] [--effort "<step_id>=<level>" ...] --json [--resume]
run_in_background: trueで起動し、終了時に最終JSONに基づいて行動します：exit 0 → pipeline.completedを発行；exit 1 → pipeline.haltedを発行し理由を提示；exit 3 (blocked) → 以下のネストブロッカーフローを実行し、その後--resume付きでdriveを再実行。スーパーバイザーの役割（実行ID、liveness、ミラーバインディング、人間へのレポート）の他のすべては変わりません。このdriver（v1: runner: headless）パスは自己改善アクションをスキップし、.feedback/<run_id>/をそのまま残します — 最終レポートでその旨を伝え、ユーザーが手動で改善パスを実行できるようにします。runner:が存在しないかmanagerの場合は、以下の手順を正確に進めてください。
モデル選択
パイプライン（および各イテレーション）は、オプションのmodel:フロントマターフィールドを介してClaudeモデルを選択できます。このフィールドのデフォルトは継承です — 省略すると、step-executorはセッションモデルを継承します。あなたはパイプライン全体のデフォルトのみを解決し、マネージャーに渡します。pipeline next CLIはイテレーションごとの有効モデル（実行時オーバーライド ?? step.model ?? pipeline_default_model）を解決し、マネージャーはそれを各step-executorにAgentツールの呼び出しごとのmodelパラメータを介して渡します。解決した値をそのまま渡してください — エイリアスを正規IDに変換しないでください。 Agentのmodelパラメータは、エイリアス、正規ID、inheritを直接受け入れます。
受け入れられるmodel: 語彙 (エンドツーエンド)：エイリアスhaiku / sonnet / opus / fableのいずれか、または任意の正確な正規ClaudeモデルID（claude-で始まる文字列、例：claude-opus-4-8、claude-sonnet-4-6、claude-fable-5）、またはinherit / 不在（→ セッションデフォルト）。
pipeline_default_modelを解決する： v2パイプラインでは、CLIがpipeline.ymlからdefaults.modelを自ら読み取ります — nullを渡して任せてください。それ以外の場合、<pipeline-root>/PIPELINE.mdが存在すれば、limit: 50でReadし、フロントマターのmodel:値が受け入れられる値（エイリアス、claude-* ID、そのまま保持）であれば取得します。inherit/不在 → null。PIPELINE.mdが存在しない場合もnull。無効な値 — 受け入れられるエイリアス、claude-* ID、inherit、または不在のいずれでもないもの — は一度警告し、nullにフォールスルーします（停止はしません）。（≤約10行のフロントマターを読み取ることはメタデータ抽出であり、コンテンツ読み取りではありません — step-executorが読み込むものを決して重複しません。）
実行時のステップオーバーライド (step_model_overrides)： ユーザーは、パイプラインファイルを編集することなく、この実行のみのために個々のステップを異なるモデルに固定できます。パスの後に明示的なフラグ（--model <step_id>=<model>、繰り返し可能）を付けるか、自然言語（「ステップ02-implementと03-refineをfableで実行」）で指定できます。ユーザーが言ったことを<step_id>=<model>ペアに正規化します：step_idはステップのstep_idフロントマターまたはそのファイル名のステム（例：steps/02-implement.mdの場合は02-implement）です。modelは上記の受け入れられる語彙を使用します（inheritはそのステップのセッションデフォルトを強制します）。IDを検証するためにステップファイルを読み取ってはいけません — CLIが未知のIDを警告し、無効なモデルを拒否します。ペアをstep_model_overridesとしてマネージャーに渡すか（5.1参照）、driverパスの場合はdriveコマンドに繰り返し--modelフラグとして渡します。オーバーライドはステップ自身のmodel:フロントマターよりも優先されます。オーバーライドのないステップは影響を受けません。CLIは初期化時にオーバーライドを実行の状態に永続化するため、再開時に自動的に保持されます — マネージャーを再起動する際に同じペアを再渡ししても問題ありません（無害であり、.runtime/が削除されても生き残ります）。オーバーライドが言及されていない場合は完全に省略します。
努力選択 (推論努力 — model: の双子)
パイプラインと各イテレーションは、オプションのeffort:フロントマターフィールド（レベル：low / medium / high / xhigh / max；inherit/不在 → セッションの努力）を介して推論努力を選択することもできます。これは、pipeline next CLI内部で完全に、モデルとまったく同じラダー（実行時オーバーライド ?? ステップeffort: ?? パイプラインeffort: ?? 継承）で解決されます。model:のために既に行っている同じPIPELINE.mdフロントマター読み取りからpipeline_default_effortを解決し（同じ無効値ルール：一度警告し、nullにフォール）、pipeline_default_effortとしてマネージャーに渡し、「03-refineをmax effortで実行」のようなユーザーリクエストをstep_effort_overridesペア（<step_id>=<level>）に正規化し、モデルペアとまったく同様に渡します（driverパスの場合は--effortフラグ）。正直な注意：driverランナーは努力を実際に適用します（起動ごとにclaude --effort）；マネージャーモードでは、Agentツールがまだ呼び出しごとの努力パラメータを公開していない可能性があります — マネージャーはサポートされている場合にそれを渡し、それ以外の場合、ステップはセッション努力を継承します（pipeline-manager.md § run-stepを参照）。
前提条件
- パイプラインが現在のプロジェクトの
./.pipeline/配下に存在すること（通常は/pipeline:designで作成されます）。 $1が./.pipeline/配下のパイプラインフォルダであること（例：./.pipeline/ship-feature）。これにより新しい実行が開始されます — これは常に新しいrun_idを発行します。--start <step-name>を使用すると、マニフェストの最初のステップではなく、指定された名前のステップから新しい実行を開始します。イテレーションファイルのパスも受け入れ可能であり、v1パイプラインが開始ステップを指定する方法です。または--resume [<run_id>]を使用して、元のrun_idで既存の実行を再開します（「再開手順」を参照）— 状態を孤立させることなく、停止したセッションの実行を継続する唯一の方法です。- 現在の作業ディレクトリはコンシューマープロジェクトのルートです — イテレーションによって実行されるすべてのファイル編集はここに配置されます。
ジャーナルイベントの発行
あなたは実行レベルのライフサイクルを<project>/.pipeline/.runtime/events.jsonlに発行します。イテレーションごとのイベント（iteration.*、improver.*、script_creator.*、worktree.*）は、マネージャーが駆動するpipeline next CLIによってプロセス内で自動発行されます（マネージャー自体は振り返りのimprover/scriptイベントのみを発行します）。実行全体が1つのsession_idを共有するため、以下で登録するミラーバインディングにより、アナリティクスフックはマネージャーとstep-executorのツール呼び出しをこの実行に関連付けることができます。発行はベストエフォートです — 失敗によって実行が停止することは決して許されません。
手順の開始時に行う一度限りの設定： CLIを呼び出して実行IDを発行します — 自分で生成したり、形式を発明したりしないでください：bun "${CLAUDE_PLUGIN_ROOT}/apps/pipeline-cli/src/cli.ts" id。それが出力するリテラル値（UUIDv7、例：019fc762-5762-7000-a9bf-922ed8fa00be）をキャプチャします。
重要 — すべてのライター呼び出しにrun_idをリテラルで渡します。 Claude CodeのBashツールは、呼び出し間でシェル状態を保持しないため、エクスポートされた環境変数は次のpipeline event呼び出しに到達しません。run_id=<リテラルID>をk=v引数としてすべての呼び出しに渡してください。k=v引数には=の周りにスペースを含めません。スペースを含む値はシングルクォートで囲みます。
発行ヘルパー (Bunで実行、成功時はサイレント、失敗時もexit 0 — 出力をチェックしない)：
bun "${CLAUDE_PLUGIN_ROOT}/apps/pipeline-cli/src/cli.ts" event <event-type> run_id=<literal-id> [k=v ...]
あなたが発行するもの (箇条書きごとに1回の呼び出し)：
--resume時は、このリスト全体は適用されません — 再開手順は既存のrun_idに対してwrite-liveness+register-mirror-bindingのみを発行し、pipeline.startedは決して発行しません（実行に再入することは開始ではありません）。「再開手順」を参照。- バナーの後：
pipeline.started run_id=<id> pipeline_name=<name> first_iteration_path=<abs> pipeline_root=<abs> default_model=<model-or-null>—default_modelはpipeline_default_model（エイリアスhaiku/sonnet/opus/fable、正規のclaude-*ID、またはリテラルnull）。 pipeline.startedの直後に、livenessロックファイルを書き込みます。これにより、読み取り側はこの実行が終了イベントなしで停止したことを認識できます：bun "${CLAUDE_PLUGIN_ROOT}/apps/pipeline-cli/src/cli.ts" event write-liveness run_id=<id> pid=$PPID(PowerShell:pid=$PID)。このスーパーバイザーを駆動するプロセスのOS pidを渡します —$PPIDは永続的なClaudeセッションに最適なポータブルハンドルです。デーモンは、このpidが実際の停止プロセスである場合にのみ実行を自動的に退任させるため、信頼できない値は安全なno-opです。
Im
…
[翻訳のため切り詰め]