cheese-factory

/cheese-factory

入力

受け付けるもの：

/cheese-factory <spec-path-or-slug> [--hard] [--resume <slug>]

• 仕様書のパス。明示されている場合は、指定先の内容をそのまま読み込みます。
• 単独のスラッグ。SPEC=$(python3 ${CLAUDE_SKILL_DIR}/scripts/cheese-factory.pyz artifact-path specs <slug>) で永続的な仕様書パスを解決し、その後 "$SPEC" を読み込みます。解決処理は仕様書をプロジェクトごとの永続コーパスに配置します（shared/formatting.md § コーパスの場所を参照）。
• --hard — /hard-cheese のメタ認知ゲートフラグを、カードごとの /cook --hard --auto とフェーズ 6 の /cure --hard --auto --stake medium+ に引き継ぎます。オーケストレーター自体はゲートを実行しません。skills/hard-cheese/SKILL.md を参照してください。
• --resume <slug> — .cheese/cheese-factory/<slug>/manifest.yaml を読み込み、完了とマークされた最新のフェーズを見つけて、次のフェーズから続行します。

/cheese-factory は、曖昧な依頼や範囲の定まっていない依頼を受け付けません。まず /mold に回してください。オーケストレーターは、仕様が確定していることを前提とします。

--auto は暗黙に適用されます。フェーズ 0 のゲート承認後、各ステップで引き継ぎの確認を行わずに、チェーンが自律的に実行されます。

/cheese-factory と代替手段の使い分け

仕様が、ファイルの重複しない 5 個以上の振る舞いカードに分解される場合に限り、/cheese-factory を使用してください。カード数がそれより少ない場合は /ultracook、単一で明確なタスクの場合は /cook、Anthropic Claude Code 上で専用のエージェントファイルをインストール済みの場合は /fromagerie を使用します。

分解の契約 — 振る舞いカード

カードとは、コミットする価値のある最小単位の振る舞いです。

フェーズ 0 の分解器は、仕様から 3 つの成果物リストを生成します。

1. seed[] — 2 個以上のカードが依存する基礎的な型／インターフェース／列挙型。
2. curds[] — 並列処理できる、ファイルの重複しない振る舞いの単位。それぞれに受け入れ基準が 1 つあります。
3. wiring[] — トポロジカルな依存関係を持つ統合タスク（バレル、登録、ルート、設定）。

5 つの基準

5 つの振る舞いに関する基準がすべてのカードに適用されます。全項目と「トークン予算は基準ではない」という根拠については、references/decomposer-prompt.md § 5 つの基準を参照してください。基準 4（ファイルの非重複）を満たさないカードは、共有内容を seed または wiring に移します。

マニフェスト形式

実行ごとのマニフェストは、.cheese/cheese-factory/<slug>/manifest.yaml に YAML 形式で書き込まれます。 YAML は人間／エージェント向けの構文です。契約はスキーマに沿った形式を維持し、 references/manifest-schema.json に記載されています。マニフェストは JSON と互換性のある YAML のサブセットに限定してください。使用できるのはマッピング、リスト、文字列、数値、 ブール値、null のみです。アンカー、エイリアス、タグ、複数ドキュメントのストリームは使用しないでください。

PR 計画も同じ規約に従い、.cheese/cheese-factory/<slug>/pr-plan.yaml に YAML 形式で書き込まれます。 その構造は references/pr-plan-schema.json に記載されています。${CLAUDE_SKILL_DIR}/scripts/cheese-factory.pyz pr_plan_to_branches は後方互換性のため YAML または JSON を読み込みますが、標準形式は YAML です。

検証（フェーズ 0）

${CLAUDE_SKILL_DIR}/scripts/cheese-factory.pyz validate_manifest と validate_decomposition が実行する 6 つのチェックについては、references/decomposer-prompt.md § 検証を参照してください。検証に失敗した場合は、違反箇所を明示して分解器を再実行します。ユーザーにエスカレーションする前に、最大 2 回まで再試行します。

フェーズ

8 つのフェーズがあります。オーケストレーターは上から順に進め、最後の項目に達するか、停止条件に該当した時点で終了します。

#	フェーズ	内容
0	プリコンパイル	仕様を読み込み、汎用の高性能サブエージェントで分解し、5 つの基準に照らして検証して、ユーザーの承認を得ます
1	シード	オーケストレーターが /cheez-write（tilth MCP を利用できない場合はホストの編集ツール）で直接編集し、コミットしてプッシュします
2	カード（並列展開）	N 個の汎用エージェントを並列起動します。それぞれがカードごとのパイプラインを実行し、コミットします
3	カードのマージ（集約）	カードのコミットをオーケストレーターのブランチにチェリーピックします → 競合がある場合は /melt
4	配線（ウェーブ内で順次実行）	統合ファイルのみを扱います。タスクごとに汎用エージェントを起動し、配線専用のプロンプトを渡します
5	配線の最終マージ	配線のコミットをオーケストレーターのブランチにマージします → ここで競合が発生した場合は停止します（分解のエラー）
6	マージ後のレビュー（新しいコンテキストで、ultracook 形式）	サブエージェントを 3 つ起動します：/press --auto、/age --auto、/cure --auto --stake medium+。1 回のみ実行します。
7	PR 計画と公開	高性能の PR プランナーサブエージェントがレイアウトを決定し、オーケストレーターがスキル検出（/pr-stack、/gh、フォールバック）を通じて公開を委任します

オプション：milknado のカード追跡バックエンド

milknado MCP が利用可能な場合（ツールセットに mcp__milknado__milknado_todo_add がある場合）、フェーズ 0 の分解中にカードの一覧を milknado のタスクグラフに保存します。カードごとに mcp__milknado__milknado_todo_add を使用し、mcp__milknado__milknado_graph_summary でマニフェストとともに追跡中のカードを表示します。これにより、ファクトリー実行中のカードのステータスをセッションをまたいで追跡できます。milknado が利用できない場合は、レポート内でカードの分解を行います（.cheese/cheese-factory/<slug>/manifest.yaml のマニフェスト YAML）。分解自体は変わりません。検出と縮退の契約については、../../shared/optional-plugins.md を参照してください。

フェーズ 0 — プリコンパイル

引数から仕様を読み込みます（または、--resume <slug> の場合はマニフェストを読み込み、次に未完了のフェーズから再開します）。

入力仕様の構造を検証します（バリデーターが分解エージェントの出力マニフェストに適用する、5 項目のカードチェックとは別です）。仕様には、次の項目が必要です：（a）列挙可能な受け入れ条件またはユーザーストーリーのリスト — 分解エージェントが各項目をカードに 1 対 1 で対応付けられるよう、箇条書きまたは番号付きの項目を少なくとも 1 つ含めること。（b）品質ゲート — 実行可能なコマンドを少なくとも 1 つ含めること。見出し名は問いません。内容が含まれているか確認してください。いずれかが欠けている場合は、速やかに失敗させます。

必須のワークツリーゲート：ホストのワークツリーの仕組み（Conductor、git worktrees、通常のブランチ）を検出し、デフォルトブランチで作業している場合は確認を促します。省略することはできません。

仕様のテキスト、5 つの基準、検証チェック、seed[]、curds[]、wiring[] とマニフェストのひな形を作成する指示を含めて、汎用の高性能分解エージェントを起動します（プロンプトテンプレートは references/decomposer-prompt.md）。

分解エージェントは、コードベースや外部ドキュメントを参照して分解の根拠を得る必要がある場合、内部で /culture または /briesearch を呼び出してもかまいません。

権限を事前に確認する：ホストごとの権限マニフェスト（git、プロジェクトの品質ゲートコマンド、ホスト固有のエージェント起動手段）をユーザーに提示します。承認されたら、ホストの設定に統合します。

Gate — ユーザー承認

計画全体を提示します。

## Cheese-Factory Plan: <slug>

### Seed (sequential)
1. <description> — files: [<list>]

### Curds (parallel)
| # | Behaviour | Acceptance criterion | Files | Test target |
|---|---|---|---|---|

### Wiring DAG
| # | Type | File | Depends on |
|---|---|---|---|

### Review Pipeline
Per-curd: /cook → /press → /age (inline-degrade) → /cure
Post-merge: /press → /age → /cure (fresh-context sub-agents)

A. Approve — start execution
B. Modify — change the decomposition
C. Re-decompose — different boundaries
D. Pause — hold off

この承認ステップでは、共有のハンドオフゲート ../../shared/handoff-gate.md を使用します。4つの選択肢はすべて、cheese-factory を内部で実行し続けます（スキルの切り替えはありません）。ゲートの語彙に従い、dispatch: コマンドではなく continue: 識別子を使用します。

• 承認 — continue: write-manifest-then-seed：.cheese/cheese-factory/<slug>/manifest.yaml を書き込み、phase: gate_approved を設定してから、Phase 1（シードの実行）に進みます。
• 変更 — continue: ask-for-decomposition-change：依頼された分解の変更について、的を絞った質問を1つ行い、計画を再表示します。
• 再分解 — continue: re-run-decomposer：ユーザーの境界に関する指示に従って、decomposer を再実行します。再試行は最大2回までです。
• 一時停止 — dispatch: none：マニフェストの下書きを残し、そのパスを報告します。

明示的な承認なしに進めないでください。

圧縮の区切り C1

破棄：仕様全文、権限マニフェスト、分解の推論。 保持：slug、仕様の概要（≤2K chars）、マニフェストのパス、品質ゲートのコマンド。

Phase 1 — シード（逐次、インライン）

シード項目は最小限にします。カードがコンパイルできなくなる共有型／プロトコルのみが対象です。オーケストレーターはシードをインラインで実行します（シードは常に小規模であるため、「コードを書かない」というオーケストレーターのルールに対する意図的な例外です）。

各シード項目について：

1. 変更を実装します。tilth MCP が利用可能な場合は /cheez-write を優先してください。利用できない場合は、ホストのネイティブ編集ツールにフォールバックします（README.md の cheez-* 移植性ルールに従います）。/cheez-write が利用できない場合でも、このスキルがハードフェイルしてはいけません。
2. 品質ゲート（プロジェクトの just check または同等のもの）を実行します。ゲートに失敗した場合は、停止します。
3. /commit が利用可能な場合はそれを使ってコミットし、利用できない場合は git commit を直接実行します。

ブランチにプッシュします。カードは HEAD からブランチを作成します。

マニフェストを更新します。

python3 ${CLAUDE_SKILL_DIR}/scripts/cheese-factory.pyz manifest_update set-phase --manifest <path> --phase seed_complete

Phase 2 — カード（ファンアウト）

ディスパッチの前に、decomposer のファイルリストを現在の作業ツリーに照らして再検証します。Phase 0 から時間が経過しており、シードによってパスが移動している可能性があります。

python3 ${CLAUDE_SKILL_DIR}/scripts/cheese-factory.pyz manifest_update check-files --manifest <path> --root <repo-root> --json

ファイルの欠落は通知情報であり、ブロッカーではありません。カードが新しいファイルを作成している場合や、分解時のパスが古くなっている場合があります。報告された欠落は、そのカードのディスパッチコンテキストに含め、ワーカーが（references/curd-prompt.md のファイルスコープに関するガイダンスに従って）リストの調整が必要になる可能性を把握できるようにします。

ホストのファンアウトプリミティブを使い、1回のメッセージで全カードワーカーを起動します。カードが5つを超える場合は、5つずつディスパッチします。

各カードワーカーは汎用のサブエージェントです（オーケストレーターと対等で、同じモデル、すべてのツール、すべてのスキル、すべての MCP を利用できます）。references/curd-prompt.md にあるカードごとのプロンプトを与えます。

カードが完了したら結果を収集します。失敗したカードは、エラーコンテキストを付けて1回だけ再試行します。retry_count: 1 と記録し、2回再試行してはいけません。

マニフェストを更新します。カードのステータス、ワークツリーのパス、ブランチ名、コミット SHA を記録します。

圧縮の区切り C2

破棄：decomposer の成果物、カードのディスパッチプロンプト、カードの返却サマリー。 保持：slug、マニフェストのパス、品質ゲートのコマンド、カードのブランチ一覧。 必要に応じてディスクから読み込むもの：配線 DAG。

Phase 3 — カードのマージ（ファンイン）

カード ID 順に、カードのコミットをオーケストレーターのブランチへチェリーピックします。

各カードについて（順番に）：

1. git cherry-pick <curd_commit_sha> を実行します。ホストのファンアウトでワークツリーを使用した場合は、ワークツリーのブランチをマージします。
2. コンフリクトが発生した場合は、/melt が利用可能ならそれを実行します。利用できない場合は、mergiraf → git rerere → 手動の順にフォールバックします。
3. /melt で解決できない場合は、停止し、Phase 7 でカードごとの PR に切り替えます。

すべてのカードをマージした後、品質ゲートを実行します。失敗した場合は停止して報告します。カードごとには合格していても、全体ではコンフリクトしています（decomposer のエラー）。

フェーズ 4 — 配線（ファンアウト、ウェーブ内は順次実行）

配線 DAG からトポロジカルなディスパッチ順序を計算します。

python3 ${CLAUDE_SKILL_DIR}/scripts/cheese-factory.pyz wiring_topo_sort --manifest <path>

返されたウェーブ順に配線タスクをディスパッチし、各ウェーブ内では順次実行します（同じ作業ディレクトリへの並行コミットは、git の index.lock で競合します）。

各配線ワーカーは、references/wiring-prompt.md のプロンプトテンプレートを使用する汎用サブエージェントです。

失敗した配線タスクは 1 回だけ再試行します。それでも失敗した場合は、マニフェストで未完了として記録します。

フェーズ 5 — 最終配線のマージ

配線コミットをオーケストレーターのブランチにチェリーピックします。

ここで競合が発生した場合は、停止してください。配線の競合は、分解時の DAG が誤っていたことを意味します（配線が実装領域に触れていた、または 2 つの配線タスクが DAG に記載されていない同じファイルを共有していた）。自動解決しないでください。

コンパクション境界 C3

破棄するもの：配線 DAG の詳細、curd ごとの差分、中間マージレポート。 保持するもの：slug、仕様パス（後続スキル用）、品質ゲート、変更されたすべてのファイルの一覧、すべてのコミット SHA（curd + seed + wiring）の一覧。

フェーズ 6 — マージ後レビュー（ultracook 形式の新規コンテキスト）

新規コンテキストのサブエージェントで、最終レビューパイプラインを実行します。

以下を順番に 3 回起動します。

1. マージ済みの差分に対して /press --auto を実行します。結果は .cheese/press/<slug>.md に書き込まれます。
2. マージ済みの差分に対して /age --auto を実行します。結果は .cheese/age/<slug>.md に書き込まれます。
3. age の指摘事項に対して /cure --auto --stake medium+ を実行します。結果は .cheese/cure/<slug>.md に書き込まれます。

各起動は、汎用のフルピアサブエージェントです。各サブエージェントが自身のフェーズのみを実行するよう、チェーン転送禁止の指示（/ultracook と同じ）を渡します。

1 回のみ実行し、cure の実行回数に上限はありません。各 curd では独自に press／age／cure を実施済みです。これは統合レベルのレビューです。

いずれかのフェーズが、その slug に status: halt: <reason> を書き込んだ場合は、その停止理由を伝えて停止します。/cure が next: done を書き込んだ場合は、フェーズ 7 に進みます。

フェーズ 7 — PR 計画と公開

references/pr-planner-prompt.md のプロンプトテンプレートを使用し、配線 DAG、マニフェスト、マージ済みの差分、仕様の要約を渡して、汎用の高性能 PR プランナー サブエージェントを起動します。

プランナーは、次の 4 つの形式のいずれかを出力します。

形式	条件	PR の構成
single	合計差分が小さく、密接に関連している	すべてのコミットを 1 つの PR にまとめます。
orthogonal_flat	curd が互いに異なる領域を変更し、seed／配線との依存関係がない	各 PR は main から分岐する N 個の PR。
stacked_linear	seed → curd → 配線の直線的な依存関係がある	gt／gh のスタック。
diamond_stack	seed と配線があり、curd 同士は独立している	seed PR（ベース）→ N 個の並列 curd PR → 配線 PR。

プランナーはグループ分けを .cheese/cheese-factory/<slug>/pr-plan.yaml に書き込み、制御を返します。

スキルの検出（オーケストレーター側）

PR を公開する前に、オーケストレーターは利用可能なスキルを検出し、適切な委任先を選択します。

必要な処理	優先するもの	フォールバック
スタックの公開	/pr-stack（Graphite gt または gh stack）	gh pr create --base <prev-branch> を手動で連鎖実行
コミット	/commit	git commit を直接実行
PR の公開	/gh	gh pr create を直接実行
マージ競合	/melt	mergiraf → rerere → kdiff3 を直接実行

検出方法：ホストの Skill ツールからスキルの呼び出しを試みます。認識されないスキルのエラーが発生した場合は、フォールバックします。フェーズの残りの処理では、検出結果をキャッシュして使用します。

公開

計画にある各 PR グループについて、次の手順を実行します。

1. pr-plan.yaml からグループのメタデータを読み取ります。
2. ブランチをプッシュします（${CLAUDE_SKILL_DIR}/scripts/cheese-factory.pyz pr_plan_to_branches を使用して、pr-plan.yaml をブランチ作成コマンドに変換します）。
3. PR を作成します（/gh が利用可能な場合は /gh を使用し、それ以外の場合は gh pr create を直接実行します）。
4. スタックの場合は、順序付きのブランチリストを指定して /pr-stack を起動します。
5. PR 番号と URL でマニフェストを更新します。

最終レポート

## Cheese-Factory Complete: <slug>

### Results
| Phase | Status | Detail |
|---|---|---|
| Seed | complete | 2 commits |
| Curds | 5/6 succeeded | Curd #4 failed after retry |
| Merge | complete | — |
| Wiring | 4/4 complete | — |
| Final merge | complete | — |
| Post-merge review | press: pass, age: 3 findings, cure: 3 applied |
| PR plan | diamond_stack | seed + 5 curds + wiring = 7 PRs |

### PRs
| PR | Title | Stack base |
|---|---|---|
| #101 | feat(orders): shared types | main |
| #102 | feat(orders): order entity | #101 |
| ... |

### Manual actions needed
- Curd #4 failed: {error_summary}

Manifest: .cheese/cheese-factory/<slug>/manifest.yaml

コンパクション戦略

各境界で破棄する前に、自己要約をマニフェストに書き込みます。

破棄する前に、phase_summary と carry_forward（形式は references/manifest-schema.json に記載）を書き込みます。--resume では、マニフェストから phase_summary を読み取ります。これは境界をまたぐ唯一の継続手段です。会話履歴に依存しないでください。

Spawn プリミティブの契約（ホスト非依存）

オーケストレーターは特定のホストプリミティブを指定しません。次の5つの不変条件をすべて満たすプリミティブであれば使用できます：（1）スポーンごとにコンテキストを新規作成する、（2）すべてのピアを継承する、（3）チェーン転送をしない（プロンプトで渡す）、（4）制御を返す、（5）引き継ぎスラッグを書き込む。ホストごとの例と、ファンアウトできない場合の代替手段（/ultracook にルーティング）は、references/spawn-primitive-reference.md に記載されています。

引き継ぎスラッグのスキーマ

各フェーズは、.cheese/<phase>/<slug>.md（または、カードワーカーごとの場合は .cheese/cheese-factory/<slug>/curds/<curd-id>.md）に、次の最小構成の引き継ぎスラッグを書き込みます。

status: ok | halt: <one-line reason>
next: <phase-name | done>
artifact: <path-to-richer-report-if-any>
<one-line orientation: what this phase did>

すでに詳細なレポートを書き込むフェーズ（/age、/press、/cure）では、同じファイルの先頭にスキーマを追加します。

品質ゲート

/cheese-factory は、プロジェクトの品質ゲートコマンド（通常は AGENTS.md に記載された just check）を次の4つの時点で実行します。

1. シードの後（フェーズ1）。
2. 各カードワーカー内（/cure ステップの後）。
3. カードのマージ後（フェーズ3、配線の前）。
4. フェーズ6の /cure の後。

ゲートが失敗した場合：停止して報告し、黙って修正しないでください。

--resume <slug>

マニフェストが参照するコミットが存在しなくなっている場合（リベースまたは削除された場合）は、フェーズを黙って再実行せず、すぐに失敗させます。それ以外の場合は、完了とマークされた最新フェーズの次のフェーズから続行し、Resuming <slug> from phase <N> と報告します。

エラーからの復旧

失敗	復旧
仕様の引数がない	停止します。cheese-factory requires an approved spec; run /mold first if you need to shape one と報告します。
分解ツールの出力に重複／基準違反がある	分解ツールを再実行します（最大2回まで再試行）。
シードのゲートが失敗	停止して報告します。カードをディスパッチしないでください。
カードが失敗	エラーのコンテキストを付けて1回再試行し、その後失敗としてマークします。
すべてのカードが失敗	停止します。マージ／配線は行いません。
カードのマージで競合	/melt を実行します。/melt も失敗した場合は、カードごとのPRに切り替えます。
配線エージェントが失敗	1回再試行し、それでも失敗した場合は未完了としてマークします。
フェーズ5で競合	停止します。分解ツールのエラーとしてユーザーに報告します。
フェーズ6の /press または /age が停止	停止状態を提示して停止します。
フェーズ6の /cure が所見を1つも適用できない	レポートを提示して停止します。
/pr-stack が利用できず、計画でスタックが必要	手動の gh pr create --base チェーンに切り替えます。
マニフェストがない状態で --resume を指定	すぐに失敗させます。

明示的なユーザー承認なしにフェーズ0のゲートを通過してはいけません。 部分的な作業を成功と報告してはいけません。

オーケストレーターが決して行わないこと

行うこと：フェーズ0で仕様を一度読み取る。フェーズごとの引き継ぎスラッグ（それぞれ2KB以下）を読み取る。各フェーズの後にマニフェストを更新する。サブエージェントの標準出力ではなく、スラッグの status フィールドと next フィールドからチェーンの進行を判断する。

決して行わないこと：

• コードベースのファイルを読む（探索はサブエージェントが行い、オーケストレーターはルーティングを行います）。
• ビルド／テストコマンドを実行する（検証はカードワーカーとマージ後のサブエージェントが行います）。
• 実装コードを書く（実装は調理エージェントと配線エージェントが行います。オーケストレーターが直接書き込むのは、フェーズ1での小規模なシード項目だけです）。
• フェーズ0の後に分解の判断を行う（計画はゲート承認時に確定します）。
• 1回を超えて再試行する（カードと配線は1回再試行した後、失敗としてマークします）。
• フェーズ5の競合を自動的に解決する（配線の競合は分解ツールのエラーです）。
• サブエージェントのトークン使用量を推定する（分解ではトークン数ではなく、振る舞いに関する基準を使用します）。
• サブエージェントのレポート全体を読む（引き継ぎスラッグの要約だけをもとに作業します）。

注意点

• /age のネストの深さ：curd ワーカーは /age を呼び出します。通常、/age は 6 つのレビュー用サブエージェントに処理を振り分けます（レベル 2、ブロックされています）。/cheese-factory では、サブエージェントの呼び出しにインライン縮退モードをサポートするよう /age に求めています。skills/age/SKILL.md の「インライン縮退モード」を参照してください。
• C2 後のコンテキスト消失：C2 の後、オーケストレーターは curd の詳細を把握していません。配線 DAG はディスク上で自己完結している必要があります。配線でマニフェストに記録されていない curd の内部情報を参照すると、配線エージェントは失敗します。
• 配線の競合状態：配線タスクは同じ作業ディレクトリにコミットします。ファイルが異なる場合でも git index.lock の競合を避けるため、フェーズ 4 ではタスクを並列ではなく順次ディスパッチします。
• bypassPermissions では Bash はバイパスされません：curd ワーカーは自由に Edit/Write を実行できますが、明示的な Bash 許可リストがないと git push や gh pr create は実行できません。すべての push / PR 操作はオーケストレーターが処理する必要があります。
• 古い worktree：curd の worktree はフェーズ 3 のマージ後も残ります。オーケストレーターはこれらをクリーンアップしません。パイプライン完了後に、ユーザーが /worktree-sweep（またはホストに相当するもの）を実行することを推奨します。

参照

• references/decomposer-prompt.md — 重量級分解サブエージェントのプロンプトテンプレート。
• references/curd-prompt.md — curd ワーカーごとのプロンプトテンプレート。
• references/wiring-prompt.md — 配線タスクごとのプロンプトテンプレート。
• references/pr-planner-prompt.md — PR プランナーサブエージェントのプロンプトテンプレート。
• references/manifest-schema.json — マニフェスト用 JSON Schema。
• references/pr-plan-schema.json — PR プラン用 JSON Schema。manifest-schema.json から $ref で参照されます。
• references/spawn-primitive-reference.md — ホストごとの呼び出し例と 5 つの不変条件。
• cheese-factory.pyz のサブコマンド（${CLAUDE_SKILL_DIR}/scripts/ 経由で実行）：validate_manifest、validate_decomposition（フェーズ 0）、validate_pr_plan、pr_plan_to_branches（フェーズ 7）、manifest_update（フェーズ 1/2/4 のマニフェスト書き込み）、wiring_topo_sort（フェーズ 4 のウェーブ順序付け）。

ルール

• サブエージェントは格下のワーカーではなく、対等な仲間です。モデルのグレードを下げたり、subagent_type を狭めたり、ツールや MCP へのアクセスを制限したりしないでください。
• チェーンは 8 つのフェーズで固定されています。追加のフェーズを作成したり、フェーズを省略したりしないでください（--resume を使用する場合を除く）。
• サブエージェントの復帰後、各フェーズのハンドオフスラッグを読み取ってください。サブエージェントの最後の行から成功を推測せず、ファイルを読んでください。
• 停止内容は一字一句そのまま提示してください。言い換えたり、表現を和らげたり、停止したフェーズを黙って「再試行」したりしないでください。
• フェーズ 0 のユーザー承認済み権限マニフェストで確認せずに、/gh を直接呼び出してはいけません。
• 共通のボイスカーネルを適用してください（このリポジトリの skills/age/references/voice.md にあります）。最終報告の冒頭では何が起きたかを伝え、残存リスクには certain | speculating | don't know のいずれかを付け、追加のフォローアップをでっち上げないでください。