orchestrate

位置づけ: 親はオーケストレーターであり実行者ではない

このスキルの目的は、親（メインループ）の出力品質に依存せずタスクの品質を担保すること。品質は「サブエージェントの焦点の絞られたコンテキスト」と「親による機械的な検収」から生まれる。よって親は次の規律を守る:

• 自分でコードを書かない・広く読まない。読むのは検収のスポットチェック（範囲指定 Read）とモード判定に必要な最小限のみ
• サブエージェントの自己申告を信用しない。「テストが通った」は親が同じコマンドを再実行して確認する
• 各フェーズの成果物を検収してから次へ進む。不合格なら理由を添えて再 dispatch（差し戻し）
• 判断（モード・分解・検収・縮退）は親、作業（調査・設計・実装）はサブエージェント

モード判定（最初に必ず行う）

引数の先頭に 調査 / 設計 / 実装 があれば明示指定。なければ依頼文から判定する:

シグナル	モード	実行フェーズ
疑問形・「調べて」「原因は」「どうなってる」「把握したい」	調査	1 のみ
「設計して」「方針を出して」「計画して」「どう作るべき」「案を比較して」	設計	1 → 2
「実装して」「直して」「追加して」「作って」「対応して」	実装	1 → 2 → 3 → 4
「レビューして」「チェックして」「見て指摘して」（新規変更を伴わない）	レビュー	レビュー委譲のみ

• 複数解釈が成り立ち判定できない場合のみ AskUserQuestion で 1回だけ 確認する（毎回聞かない。動詞が明確なら表に従う）
• 調査/設計モードで完了したら、そこで止まる。次アクション（「このまま実装しますか」）の提示はよいが、勝手に実装へ進まない
• 実装モードでも途中で前提が崩れたら止まる。調査の結果「変更不要」「原因が別」「依頼と矛盾する事実」が出たら、実装せずその発見を報告する

オーケストレーション不要の判定（バイパス）

対象が自明（単一ファイル・数十行以内・調査不要。typo 修正、文言変更、定数値の単純変更など）なら、サブエージェントを使わず親が直接編集し、フェーズ4 の機械検証だけ行う。オーケストレーションは手段であり目的ではない。

ただし src/constants/ScoringConstants.ts の重み変更は「単純な設定値変更」ではない（スコア・ML・バックテスト・ドキュメントに波及する）。バイパスしない。

レビューモード（既存レビュースキルへの委譲）

レビューのオーケストレーションは review-* スキル群に実装済みのため、親は自前でレビューエージェントを組まず Skill tool で委譲する。スコープ引数（PR #N / vs:<branch> / range / ファイル列挙。なし = main 差分）はそのまま透過する:

依頼	委譲先
レビュー・指摘のみ	/review-all
指摘の反映まで（「レビューして直して」）	/review-fix
収束まで自動反復（「収束するまで」）	/review-fix-loop
単観点のみ明示（「セキュリティだけ」「スコアリングの正しさだけ」など）	該当する /review-<name> 1件（review-arch / review-code / review-comments / review-naming / review-test / review-recovery / review-security / review-scoring）

委譲後は統合レポート（/tmp/arima-review-all-result.md、修正まで回したなら /tmp/arima-review-fix-result.md）の Summary 表と HIGH アクションを親が要約して最終レポートに出す。親が指摘の再検証や独自レビューを重ねない（FAIL 照合は review-all 側の責務）。

共通規律

進捗の可視化（必須）

サブエージェント実行中に親が沈黙すると「止まってる？」と見える。区切りで一文ずつ出す: モード判定結果 → 各フェーズ開始（dispatch 数を添える）→ 検収結果（合格/差し戻し）→ 完了サマリ。

コンテキストの受け渡し

• サブエージェントへファイル全文を貼らない。パス + 行番号（file:line）+ 1行要約で渡し、読む作業は本人にやらせる
• 各プロンプトに「返答フォーマット」を必ず明記する（サブエージェントの最終メッセージは親への生データであり、人間向け文章ではない）
• 前フェーズの成果物（調査レポート・実装計画）は要点を抜粋して渡す。全文転記は計画本体のみ可

エージェント数の規律

調査 1〜4体 / 設計 1体（大型タスクのみ2案並列 + 親が比較）/ 実装は計画ステップ数分。これを超える fan-out が必要に見えるなら、タスクの分割単位が粗すぎるか、review-all など既存オーケストレーションスキルの守備範囲。エージェント間の矛盾を裁定する追加 Explore（フェーズ1 検収で発火）は初期分解の体数に数えない（1〜4体はあくまで初回の並列分解の上限）。

失敗時（1件の失敗で全体を止めない）

サブエージェントの異常終了・空返答・検収不合格は、失敗理由を添えて 1回だけ 再 dispatch。2回失敗したらそのユニットだけ親が直接処理するか、できなければ「未完了ユニット」として最終レポートに明記する。

フェーズ1: 調査（Explore agents・並列）

1. 依頼を独立に調べられるサブクエスチョンに分解する（例:「現状の実装箇所」「既存の類似前例」「影響範囲・呼び出し元」「テストの現状」「DB スキーマ・クエリへの波及」）
2. 相互に依存しないため 単一メッセージで並列 dispatch する（subagent_type: Explore、探索の広さを指定: 既定は "medium"。呼び出し元・影響波及の全列挙が要る調査、非決定的挙動の原因探索、複数の命名規約/配置を横断する必要がある場合は "very thorough"）

プロンプトテンプレート:

調査タスク: <サブクエスチョン>
既知のコンテキスト: <親が知っている関連パス・事実（あれば）>
規律: 主張には必ず file:line の根拠を付ける。事実と推測を区別し、推測には（推測）と明記する。
返答フォーマット:
- 結論: 1〜3行
- 根拠: file:line + 1行要約の箇条書き
- 関連ファイル一覧
- 未解決・追加調査が要る点

検収基準: 結論を支える主張に file:line があるか（無ければ差し戻し）。エージェント間で矛盾する報告があれば、争点を明示した追加 Explore 1体で裁定する。合格したら親が 調査レポート（結論 → 根拠 → 未解決点）に統合する。

フェーズ2: 設計（Plan agent）

Plan agent 1体に設計させる。例外: docs/ に手順が明文化された定型作業（新コマンドの追加・既存リポジトリへのクエリ追加など）は Plan agent を省略してよいが、その場合も計画（ステップ・対象ファイル・受け入れ基準）を親がテキストで書き出してから実装に入る。省略の可否はフェーズ1の結果で確定する: 調査で判明した実際の触点が明文化された手順の範囲に収まるなら省略可。手順の記述を超える触点（未文書のファイル・想定外の層）が出たら省略せず Plan agent を立てる。

プロンプトテンプレート:

設計タスク: <目標>
必ず先に読むこと:
- docs/ARCHITECTURE.md（層構成・スコアリング/ML パイプライン・バックテスト）
- docs/DEVELOPMENT.md（技術スタック・命名規約・コーディング規約）
- .claude/skills/design-principles/SKILL.md（設計原則）
- スコアリング/ML に触るなら docs/MODELS.md、DB に触るなら docs/DATABASE.md
調査レポート:
<フェーズ1 の統合レポート>
返答フォーマット: 実装計画
- ステップ分割（各ステップ: 目的 / 対象ファイル / 変更概要。ステップ間の依存関係を明記）
- テスト方針（追加・変更するテストと置き場所。__test__/ 併置、src/test/helpers/testDb.ts の一時 SQLite DB を使う）
- 受け入れ基準（機械検証コマンドと期待結果）
- リスクと代替案（あれば）

大型タスク（新しい層の追加・スコア要素の増減・ML パイプライン変更・DB スキーマ変更）は観点を変えた2案（例: 最小変更案 / 規約理想形案）を並列 dispatch し、親が理解容易性・規約適合で比較して採用案を決める。

検収基準: 親が計画を docs/ARCHITECTURE.md / docs/DEVELOPMENT.md と突き合わせる。最低限チェックする項目 — 層の置き場所が正しいか（計算は domain、参照系は queries/、更新系は aggregates/、CLI は commands/）/ 重み・閾値を src/constants/ の単一定義以外に書いていないか（SCORE_WEIGHTS 合計 1.0 の維持）/ スコアリングと ML の特徴量統一を崩していないか / 命名規約との整合 / テスト方針の有無 / 受け入れ基準が機械検証可能か。違反があれば指摘を添えて差し戻し。

設計モードならここで 実装計画 を最終レポートとして出力して終了。

フェーズ3: 実装（general-purpose agents）

計画のステップ単位で dispatch する。依存し合うステップは直列（前ステップの結果を次のプロンプトに反映）、触るファイル集合が互いに素なステップのみ並列。迷ったら直列。

プロンプトテンプレート:

実装タスク: 実装計画のステップ <N>
必ず先に読むこと: docs/ARCHITECTURE.md / docs/DEVELOPMENT.md / .claude/skills/design-principles/SKILL.md / .claude/skills/review-code/SKILL.md
計画（該当ステップ）:
<ステップの全文>
関連する調査結果:
<file:line + 1行要約の箇条書き>
規律:
- 計画外のファイルに触らない。計画の欠陥に気づいたら実装で勝手に補わず、返答で報告する
- テストを追随させる（__test__/ 併置、src/test/helpers/testDb.ts の createTestDb で一時 DB を作る。E2E は console を spyOn で黙らせる）
- 実装後に `bun run c`（型チェック。`bun c` は bun create と解釈され失敗するので不可）/ `bun run lint` / `bun test` を実行する
返答フォーマット:
- 変更ファイル一覧（各1行要約）
- 検証コマンドと結果（失敗はそのまま貼る）
- 判断に迷った点・計画からの逸脱（あれば理由付き）

検収基準（ステップごと）: ① git diff --stat で計画外のファイルが触られていないか ② 親が bun run c を再実行 ③ 逸脱報告があれば妥当性を判断（不当なら差し戻し、計画の欠陥なら計画を更新して続行）。

フェーズ4: 検証

1. 機械検証（親が自分で実行・必須）: bun run c → bun run lint → bun test。失敗は該当ステップの実装エージェントに失敗ログを添えて差し戻す（最大2周）。基準線は「型チェック 0 エラー / lint 0 errors（warnings は既存分を増やさない）/ bun test 全 pass」。スコアリング・ML に触れた場合は bun start backtest の主要指標も実行前後で比較して報告する
2. レビュー（自動実行しない・ユーザー確認制）: 機械検証が通っても、レビューを親の判断で勝手に実行しない。差分が 300 行超、またはスコアリング／ML／DB スキーマ／外部取得（JRAFetcher・HorseDataExtractor）に触れる場合は「/review-all 相当のレビューを回すか」を AskUserQuestion で 1回だけ 確認し、承認されたときだけ実行する。却下・無回答相当（スキップ指示）なら最終レポートに「レビュー未実施（ユーザー判断）」と明記して先へ進む
3. ユーザーがレビューを明示的に依頼した場合（「レビューして」「敵対的レビュー」等）は確認不要でその指示に従う。指摘反映まで回したい指示があるときは /review-fix に委譲する

最終レポート

モードに応じた成果物を最終メッセージに出す（途中のフェーズ報告に散らさない）:

• 調査: 結論（1〜3行）→ 根拠（file:line）→ 未解決点 → 提案する次アクション
• 設計: 実装計画全文 → 親の検収で確認した規約適合点 → リスク
• 実装: 変更サマリ（ファイル一覧 + 各1行）→ 機械検証の結果（コマンドと実際の出力要約）→ レビュー結果 → 未完了ユニット・残課題（無ければ「なし」と明記）

検証に失敗したまま完了扱いにしない。失敗が残る場合は「何が失敗し、何を試し、どこで止まっているか」を事実のまま報告する。