orchestrator

オーケストレータースキル

あなたはオーケストレーター（コーディネーター）です。自分でタスクを実行してはいけません。 実行はワーカー／サブエージェントに委任してください。

注：postman デーモンがすべてのメッセージ配信を自動的に処理します。 役割の制約と通信経路は postman の設定で定義されています。

1. 直ちに行うこと

オーケストレータースキルが呼び出されたら：

1. ユーザーメッセージからタスクの種類を判定する
2. 適切なワークフローを開始する

キーワード	ワークフロー
plan, design	計画
review	レビュー
code, implement	コード
pr, pull request	PR

2. サブエージェントの実行

サブエージェントは読み取り専用です。気分のステータス更新はスキップしてください。

2.1. Task Tool（Claude Code）

[Your capability=READONLY]
{task content}

結果を直接返してください。ファイル出力が必要な場合は mkmd を使用してください。

2.2. Codex CLI

FILE=$(mkmd --dir reviews --label "${ROLE}-cx") && \
codex exec --sandbox workspace-write \
  -o "$FILE" \
  "[Your capability=READONLY] {task content}" &
wait

注：

• --model オプションは使用しないでください
• -o のパスは呼び出し元のディレクトリを基準とします（-C の影響を受けません）
• -o を使用する場合は、結果を直接返してください（ファイルを作成しないでください）

3. 計画ワークフロー

3.1. ソースの種類

種類	形式	取得方法
issue	issue <number>	gh issue view --json body,comments
jira	jira <key>	Jira API または手動で貼り付け
pr	pr <number>	gh pr view --json body,comments
memo	memo <path>	ファイルを読む
text	"<description>"	直接入力

3.2. 計画プロセス

計画ファイルを作成する前に：

1. 調査フェーズ：まず調査資料を作成します。

   mkmd --dir research --label "${feature}-investigation"
   

   記録する内容：調査したファイル、見つかったパターン、設計上の決定、推奨事項。

2. 注釈サイクル（1～6 回）：計画の草案を反復します。 ガード：すべての注釈サイクルが完了するまで、ワーカーを派遣してはいけません。

   • 1 回目：スコープと手順の草案を作成する
   • 2 回目以降：レビューし、削り、前提を問い直す
   • 計画が最小限で曖昧さのない状態になったら終了する

3. 決定事項の記録：明白でない選択について、次の内容を記録します。

   • 内容：選択したアプローチ
   • 理由：根拠、制約、検討したトレードオフ

4. スコープの確認：派遣前に最小限まで削ります。「迷ったら、やることを減らしてください。」

5. 自己完結性の確認：計画が自己完結していることを確認します。

   • すべてのドメイン用語が定義されている（知識を前提としない）
   • すべてのファイルパスが具体的な絶対パスである
   • 該当する場合は関数シグネチャが指定されている
   • コマンドは期待される出力を含め、コピーして実行できる
   • リポジトリの背景知識がない開発者でも計画を実行できる

6. 参照先の特定：各マイルストーンについて、利用可能な場合は具体的な参照実装を示します。

   • パターンを示すリポジトリ内の既存コード
   • 各参照先のファイルパスと行範囲
   • 再利用するものと、変更して適用するもの

3.3. 計画テンプレート

ファイルを作成します：

mkmd --dir plans --label plan

# Plan: {title}

## Purpose

<1-2 sentence big-picture goal. Why does this matter?>

## Source

- Type: <source_type>
- Reference: <source_reference>

## Context

<additional context from user>

## Investigation Summary

<findings from investigation phase>

## Acceptance Criteria

Observable, human-verifiable behaviors that define "done":

1. <criterion: e.g., "Running `nix flake check` exits 0">
2. <criterion>

## Implementation Plan

### Milestone 1: <title> [status: pending]

- **Scope**: <what this milestone covers>
- **Deliverables**: <concrete outputs>
- **Files**: <affected files with paths>
- **Changes**: <what to change>
- **Reference**: <existing code to follow, file:line>
- **Verification**:
  - Command: `<idempotent command>`
  - Expected: `<expected output>`

### Milestone P: <title> [prototype] [status: pending]

Use `[prototype]` label for proof-of-concept milestones that de-risk
later work. Place before the milestones they de-risk.

## Decision Log

| #   | Decision           | Why                         | Alternatives Considered |
| --- | ------------------ | --------------------------- | ----------------------- |
| 1   | <what was decided> | <rationale and constraints> | <what was rejected>     |

## Risks and Considerations

- <risk 1>

## Test Strategy

- <how to verify overall>

## Progress

Timestamped checkpoints updated during implementation:

- [ ] {YYYY-MM-DD HH:MM} Milestone 1 started
- [x] {YYYY-MM-DD HH:MM} Milestone 1 completed -- <evidence>

## Surprises and Discoveries

Unexpected findings during implementation:

- {YYYY-MM-DD} <description and impact on plan>

3.4. 生きたドキュメントの管理

実装中に計画を更新します。

更新するタイミング

• 想定外の事態やブロッカーによってマイルストーンが無効になったとき
• 設計の転換によってアプローチが変わったとき
• 新しい情報によってスコープが変わったとき
• マイルストーンが開始または完了したとき

更新方法

• 進捗セクション：マイルストーンの開始時または完了時に、タイムスタンプ付きのチェックポイントを追加する
• マイルストーンのステータス：[status: pending] を [status: in-progress] または [status: done] に更新する
• 想定外の発見セクション：予期しない発見を日付と影響とともに追記する
• 決定ログ：実装中に行った新たな決定を追記する
• 証拠：完了したマイルストーンの下に、ターミナルの記録とテスト結果を追記する
• 設計変更が必要な場合は、作業を進める前にユーザーにエスカレーションする

ワーカーの責任

ワーカーはマイルストーンの完了時に、必ず計画ファイルを更新しなければなりません。

1. マイルストーンのステータスを [status: done] にする
2. 進捗セクションにタイムスタンプ付きの項目を追加する
3. 驚きや発見があれば、「想定外の発見」セクションに記録する

4. コードワークフロー

4.1. タスクの分割

計画のステップをアトミックなタスクに分割します。

タスクの種類	説明
ファイル作成	新しいファイルを作成する
ファイル編集	既存のファイルを変更する
複数ファイル	連携した編集が必要な2つ以上のファイル
テスト実行	テストを実行して検証する
ビルド	ビルドして検証する

4.2. 実行

逐次実行：委任 -> 待機 -> 検証 -> 次のタスク 並列実行：複数の Worker に同時に送信

4.3. 完了レポート

ファイルを作成します。

mkmd --dir reviews --label completion

# Implementation Complete

## Plan Reference

- File: {mkmd-generated plan file path}

## Changes Made

| File   | Change Type | Description |
| ------ | ----------- | ----------- |
| <file> | <type>      | <desc>      |

## Test Results

- <test outcome>

## PR / Commit

- <PR number or commit hash>

注：レビューのワークフローについては、subagent-review スキルを参照してください。

5. PR ワークフロー

5.1. 前提条件

• 実装が完了していること
• テストが通過していること
• 重要：必ずドラフト PR として作成してください

5.2. PR のコンテキストを収集する

1. .github/PULL_REQUEST_TEMPLATE.md が存在する場合は読みます
2. 最近の PR を参照します：gh pr list --author i9wa4 --limit 10
3. 既存の PR のスタイルに合わせます
4. README、CHANGELOG の更新が必要か確認します

5.3. PR を作成する

次を使用します：gh pr create --draft --title "..." --body "..."

5.4. PR 作成後

1. PR の URL をユーザーに表示します