task-pipeline

task-pipeline

自己完結型のオーケストレーターです。各段階に組み込みの指針を備えたゲート付きステージを通じてタスクを実行し、追加のプラグインは必要ありません。ゲートを通過するまで次のステージには進まず、実行全体で使うモデルは開始前に1つ確認します。

まずは状況に応じて、次に自律的に。 ステージ0は面接の前に不足の確認を行います。依頼、ファイル、情報収集の内容からブリーフを作成し、質問するのは情報源から答えが得られない重要な不明点に限ります。ブリーフが完成していれば、受付時の質問はゼロです。依頼またはプロジェクトですでに決定済みの事項は記録し、再交渉しません。変更が小規模でもある場合（リスクR1、ファイル数が5つ以下、公開コントラクトの変更なし、ユーザー向けの変更なし、デプロイなし）、実行はデフォルトで短縮経路を取り、その旨を1行で伝えます。実行台帳にブリーフを記録し、テストを行いながらビルドし、検証を1回行い、ドキュメントと引き継ぎを整え、新たな教訓がある場合に限りレトロスペクティブの記録を残します（references/stage-00-intake.md → Phase 1d。ここでは、スキップしたステージを再開する条件も説明しています）。それ以外の変更では、完全なフローを実行します。不明点が残る場合は、ステージ1→10を事前に解決するための面接を1回にまとめて行います。ステージ0で見送られた重要な質問は、後の段階ですべて中断事項として再度提示されます。

設定コントラクト：pipeline.schema.json。 パイプラインはステージを順に並べたリストで、各ステージは skills[] と gate {type, check} を持ちます。スキーマはステージ、スキル、ゲートの割り当てを規定しません。 pipeline.example.json は、このプラグインのデフォルトフロー（ステージ0と、以下のステージ1→10）および任意の release ブロックをコピーして書き換えるための例です。

2つのレイヤーがあり、置き換え可能なのはそのうち1つだけです。 KERNEL は、どのパイプラインでもすべての作業単位に含まれるもので、スコープ、エビデンス、依存関係、再開ポイントを持ちます。カーネルは不変です。PROFILE はステージのリストであり、プロジェクトが全体を置き換えます。ステージ番号はKERNELではなく、選択したプロファイルに属します。 3ステージだけのプロファイルに「ステージ7」はなく、グローバルなステージ番号に基づくルールはデフォルトプロファイルに関するルールです。カスタムプロファイルではステージを省略できますが、カーネルフィールドは省略できません。各ゲートにはタイプがあります。auto（オーケストレーターが check を検証）、judgment（指定された判定者が判定し、測定値ではなく判断として記録。references/gates.md → The judgment gate）、manual（明示的な承認）です。デフォルトプロファイルのゲートは auto です。manual になるのはオペレーターの pipeline.json で指定されている場合に限られ、行為を明示したオペレーターの常設承認は承認として扱われます。 skills[] では、task-pipeline:<name> はこのスキル独自の指針（references/<name>.md）、host:<name> はホストプロジェクト独自のコマンド（references/conventions.md）です。

前提条件：不要

各ステージの手順はこのスキルに含まれており、インストールが完了しないと進められないステージはありません： ステージ 1 はウェブ検索にフォールバックします。Wiki とコードグラフは推奨事項です。 どのリファレンスがどのステージを担当するかは、 references/doctrine-map.md を参照してください。優先順位： カスタムプロファイルではカーネルが優先されます。references/stages.md はデフォルトプロファイルの規範的なゲートセットであり、すべてのプロファイルでカーネルが規範となります。ステージ 2/4/5/6 における別のスキルセットについては、 references/companion-skills.md を参照してください。

super-ux は、あらゆるユーザー向けタスクで推奨されるプロバイダーです。また、ステージ 3 のゲートで確認するのはパッケージではなく成果物です。変更を網羅する有効なシナリオが、super-ux、同等のプロバイダー、または references/companion-skills.md のインラインフォールバックによって提供されていれば、ゲートを通過します。シナリオの成果物が一切ない場合、ゲートは停止します。ツールがない場合は、タスクの失敗ではなく、実施されなかった確認項目を名前付きで報告します。

グリルは組み込み済みです（references/grill.md）。グリルはREQ の骨格を生成します。これは、各行に検証方法、ステージ 3～5 での追跡先、そしてステージ 10 で確実に対応する項目を明記した、アドレス指定可能なリスト形式のリクエストです。質問する前に情報を収集します （references/knowledge-sources.md）。ステージ 0 ではプロジェクトがすでに把握している情報を取得し、情報源台帳を作成して、すべての回答を台帳と照合します。文書よりオペレーターを優先しますが、その指示は口頭で伝えられた場合に限ります。

実行を完了させる 3 つの成果物は連携しています。ステージ 9 でドキュメント、Wiki、コードグラフを同期し、グラフが存在する場合は、グラフとドキュメントの差異チェックをそれらに対するゲートとします（references/knowledge-graph.md）。ドキュメントはゲート付きの成果物です （references/documentation.md）。これには docs/DOCMAP.md、任意のステージで実施する Doc Loop、ステージ 9 の伝播マトリックス、終了コードを返すコマンドとしての 「ドキュメント同期済み」 が含まれます。

実行で得た知見を次の実行に活かし、リストは短く保ちます （references/retrospective.md）。ステージ 10 の最後の処理は、この順序で行い、順序を崩してはいけません。実行にスタンプを付け、次に整理し、最後に記録を書きます（references/learned.md のルール 21）。ステージ 0 で全文を読み込む内容（常設の指示と実行スタンプ）には、バイト数の上限があります。scripts/retro_budget.py check はステージ 0 でバイト数とバイト数/4 で算出したトークン数を出力します。上限を超えるとゲート 10 は失敗し、migrate によって記述をアーカイブへ移し、原文のままであることとハッシュによる検証が確認されるまで通過しません。

実行方法

1. タスクを1行で言い換え、各ステージを0から追跡します（再開用にホストのタスクツールまたは文章のチェックリストを使用）。その後、事前確認ブロックを一度だけ出力します。内容は、モデルの決定（references/model-tiering.md：最も高性能なモデルを推奨として提示し、オペレーターが承認または上書きします。その選択はプラン、ステージ、サブエージェントにそのまま引き継がれます）、実行モード（pipeline.json → run.loop、references/continuity.md。設定がなければオフで、モードによって manual ゲートがなくなることはありません）、および任意のコンパニオン（UI タスクには super-ux、context7、wiki-update、graphify。references/companion-skills.md）です。
2. ステージ0を実行します。 情報を収集し、次に不足を確認してから、タスクに応じた判断を行います（references/stage-00-intake.md）。super-ux から引き継いだ場合（検証済みの docs/ux/ の一連のドキュメント、または docs/ux/plans/… の修正プランが存在する場合）は、/ux-lint が成功していることを確認し、スコープを1行で確認して、実作業のある最初のステージに進みます。
3. 事前確認で確定したモデルを使って各ステージを進めます。ステージごとにモデルを再確認しないでください。選択したプロファイルは事前確認時に一度だけコンパイルされ、そのプロファイルで宣言されたステージとゲートだけが実行されます。3ステージのカスタムプロファイルなら実行するのは3ステージで、隠れたステージ0、7、10が追加されることはありません。ただし、カスタムプロファイルで カーネル を回避することはできません。ステージを省略しても、エビデンスゲートは省略されません。また、未知の必須機能があればコンパイルは停止します。このランタイムにない must_understand 機能は拒否され、その機能を黙って欠いたまま実行されることはありません。変更ではなくプラットフォームの場合は？ ステージ2でモジュールに分割し（references/decomposition.md）、ステージ3～10をモジュールごとに実行します（references/stages.md → プログラムループ）。ボード全体の場合は？ /task-pipeline waves を使います（references/waves.md）。リリースの場合は？ references/iteration.md を参照してください。発見事項は見つかり次第トリアージし、終了条件に達したらイテレーションを停止します。終了条件とは、成果物の終了チェックがすべて成功し、新たなブロッキング指摘がないラウンドが1回（R3 またはフラッグシップノードでは2回）完了すること、または予算を使い切ることです（references/finish-line.md）。
4. ステージの ゲート に合格するまで次に進まないでください（references/stages.md）。auto の場合は check を自分で検証します。judgment の場合は判定を判断として記録します。manual の場合は、オペレーターの続行指示、またはこの行為を明記した継続的な許可を引用します。ループには停止条件があります。 R1 ノードは1回のブラインドティアで認定され、R3 またはフラッグシップでない限り、問題のないラウンドが1回完了すればノードを終了します。認定上限に達したノードはエビデンスとともに保留し、次に進みます。入力に変更がなければティアを再実行しません。レビューのループは最大3ラウンドです（references/certification.md、references/loop-guard.md）。
5. 横断ルールはどのステージでも適用されます（Doc Loop、ループガード、監査の終了条件、終了条件、凍結された REQ リスト、引き継ぎ台帳、エビデンスの定義）。また、各ゲートは8つすべての残留クラスに対して holds: N を出力し、この実行の残留が残っている間、ステージ10を終了できません（references/residue.md）。詳しくは references/gates.md → すべてのステージに適用される横断事項 を参照してください。

何を、いつ読むか

開始時に読むのはこのファイルだけです。以下のステージ表がステージのインデックスです。各ステージの詳細は、そのステージの開始時に読みます（references/stages.md が順に、1 セクションずつ案内します。詳細をすべて先読みしてはいけません）。それ以外の内容は、該当するきっかけがあったときに読みます。

参照先	読むタイミング
references/grill.md	ギャップの確認で重要な未確認事項が残ったとき
references/knowledge-sources.md	情報源について、台帳の行だけでは不十分なとき：コードグラフ、Wiki、レッスンストア、引き継がれた主張、古くなった行
references/companion-skills.md	ユーザー向けタスク（プロバイダーのルール）、スキルセットの差し替え、またはコンパニオンの不足があるとき
references/continuity.md	run.loop が有効になったとき、コンテキスト予算のシグナルを受け取ったとき、または実行を再開するとき
references/model-tiering.md	オペレーターがモデルを上書きするとき、またはステージマップが異なるとき
references/gates.md	チェックを作成または変更するとき、ゲートの判定に異議があるとき、または判断ゲートが実行されるとき

ステージ（references/stages.md のゲートとルート）

すべてのステージは、プリフライトで確認した同じモデルで実行します。

#	ステージ	ゲート	種別
0	インテークグリル — 必須	Contradictions: 行を含むソース台帳を作成済み；docs/DOCMAP.md に回答し、意図を実装済みの状態と照合して整合済み；レトロスペクティブの最低要件を全編読み、そのバイト数を出力済み；自律性の確認を網羅済み；UI：surface_class を記録済み；ブリーフを確定し確認済み	自動
1	ドキュメント調査	取得したドキュメントに基づくコントラクト	自動
2	ブレインストーミング＋分解	設計を承認済み；UI の判定を記録済み；すべての REQ に回答済み；キューは成果物 — 作業グラフが検証に合格し、未対応の REQ がないことをカバレッジで明示；プラットフォーム：モジュールマップを承認済み	自動
3	仕様	コミット済み＋レビュー済み；UI：チェーンを検証済み、リンターがグリーン、シナリオと SCR- のトレース済み；COPY と VISUAL は UX 後の並行レイヤーで、両方を実施した場合は収束チェックを記録済み；VISUAL はディレクターの記録で確認済み	自動
4	計画	並列実行の準備完了、タスクごとに DoD を設定；すべてのエッジに、引き継ぐ内容を記載 — フェイクエッジのテストを実行し、Edges: の件数を算出済み；scripts/plan_audit.py がクリーン — 稼働中のすべてのノードのパケットを予備知識のない読者が理解でき、順序付けされていないノード同士が同じファイルを編集しない	自動
5	開発	タスクが DONE、タスクごとに TDD がグリーン、ブリーフに従ってブランチを統合済み；作業を複数に展開したグループは、最初のワークツリーを取り込む前に、すべての差分をまとめて収束チェックを 1 回実施	自動
6	テスト	フルスイートがグリーン、新規および変更済みコードをカバー済み、新しいチェックはすべて両方向から試し、終了コードをアサート済み；ウェブのサーフェスは差分ではなくブラウザーで確認 — ブラウザーチャネルが接続されている場合；未接続の場合は、より弱い主張を記録；ゲート付きサーフェスのコンタクトシートが合格	自動
7	リント＋デプロイ	デプロイ前にリントがクリーンでスイートがグリーン；デプロイには go、またはブリーフで指定された具体的な継続的承認が必要	自動
8	デプロイ後	クリーンな起動、または正直な縮退レポート；デプロイ済みのウェブターゲットは curl ではなく開いて確認 — 200 が証明するのはサーバーが応答したことだけで、それ以外は証明しません；ブラウザーチャネルが接続されていない場合は、より弱い主張を記録	自動
9	ドキュメント＋Wiki	ステージ 0 のソース台帳にある古くなった行をすべて更新済み；今回の実行で発生したすべての変更タイプについて伝播マトリックスを確認済み；ドキュメントのゲートがグリーンで、調整値を出力済み；ドキュメント、Wiki、コードグラフを同期し、相互に照合済み	自動
10	受け入れ	ラダーウォークを実行し、その欠落を REQ 行に反映済み；すべての REQ を、失敗を一度確認したチェックの証拠で説明済み；未解決の台帳行なし；すべてのリポジトリがクリーンで、プッシュ済み、参照先も提示済み；引き継ぎ文書を作成し、環境を返却済み；レトロスペクティブを最後に、順序どおり、バイト数の予算内で作成済み	自動

上記の各ゲートは簡略版です；詳細版は references/stages.md を参照してください。CUSTOM プロファイルでは、宣言した独自のドクトリンを使用します；数値 ID が一致しても、デフォルトの詳細が選択されるわけではありません。複数のリポジトリがある場合は？ サブモジュールが完了するのは、その親が完了を宣言したときです： references/acceptance.md → 複数のリポジトリからなるプロジェクト。

モデル：プリフライト時に一度だけ確認

利用可能な中で最も高性能な推論モデルを推奨します。実行時にティアを解決し、 ID をハードコードしてはいけません（references/model-tiering.md → Mechanic）。回答をブリーフに記録します；ステージ 5 のサブエージェントはそのモデルに固定します。

縮退

• python3 がない場合 → 作業グラフの動詞とシード済みのゲートスクリプトを実行できません。キューは文章による計画に、ゲートはチェックリストに縮退します — 必ず明言し、黙って済ませてはいけません。
• git がない場合 → ワークツリーによる分離も、コミットを指定した証拠も得られません。より強い主張を装うのではなく、実行ではより弱い主張を記録します。
• ブラウザーチャネルがない場合 → ウェブのサーフェスは差分を読んで検証し、終了時にその確認がより弱い主張であると記録します。

スキルを独自に用意する

上記のステージは例のワークフローです。ホストは pipeline.example.json を pipeline.json にコピーし、独自のステージ（数は任意）を定義して、各 skills[] に環境で解決される対象を指定し、各 gate.type（auto／judgment／manual）を設定して、独自の release ブロックを切り替えます。唯一の契約は pipeline.schema.json です。

参考資料

ほとんどの参考資料は、ステージごとに references/doctrine-map.md から案内されます。残りは文章から案内されます。stages.md、learned.md（ルールが適用される箇所で引用）、および probing.md（gates.md から）です。このファイルと同じ場所に、設定の契約と、このファミリーのタスク／コンテキスト契約である execution-packet.schema.json および execution-result.schema.json とそのサンプルがあります。これらは依存関係なしで scripts/packet.py により検証されます（不明な必須バージョン、ダイジェストのない参照、または未バインドの決定は拒否されます。古い結果の場合は適用せず、再計画します）。scripts/context_packets.py compile|verify は監査レポートを親タスクに対応付けます。ID は検出事項の ID から導出され、位置には依存しません。対応付けられない行がある場合、コンパイルはブロックされます。

トリガー

説明は短縮版です。1.98.0 まで使われていた完全なトリガー一覧をここにそのまま移し、このスキルのトリガーとして引き続き使います。

「リポジトリを変更する作業（機能追加、修正、バグ対応、リファクタリング、移行、統合、書き換え、導入、強化。фича、фикс、баг、рефактор、миграция、интеграция、доработать、починить、внедрить、перевести）を行うとき、またはリポジトリに反映される検出事項（監査／аудит、バグ調査／проверь ошибки、本番環境の確認／проверь прод、PR レビュー／ревью PR）があるとき、または『これをパイプラインに通して』／『прогони по конвейеру』、『全サイクル』／『полный цикл』、/task-pipeline の場合に使用します。実質的なタスクを、ゲート付きのステージ（初回ヒアリング、ドキュメント、ブレインストーミング、仕様、計画、実装、テスト、デプロイ、デプロイ後、ドキュメント／Wiki、受け入れ）に通します。『waves』／『волнами』／『release iteration』／『итерация релиза』でボードを締め切ります。『checkup』／『чекап』で未確認のリリースを一覧表示します。『setup』でドキュメントを監査します。対象外：質問への回答、説明、誤字の修正、1 行の編集、名前の変更、何も反映されない調査。オプトアウトする場合は『no pipeline』／『без пайплайна』と言ってください。」