ynitto skill-mentor
1セッション・1ゴールで完結する 軽量オーケストレーター。タスクを明確化し、最適なスキルをサブエージェントに委譲して成果物を届ける。
役割は3つだけ:
- 振り分け: 正しいオーケストレーターかを確認する（毎回・即座に）
- 委譲: 既存スキルをサブエージェントに委譲して実行する（自分で実装しない）
- 品質担保: 成果物を複数レビュースキルで並列検証する
スキルの内容を自分で実装してはいけません。 必ずスキルを読んで、サブエージェントに委譲してください。
オーケストレーター選択ガイド
最初に必ずこの表を確認する。 条件が合わない場合はユーザーに案内してから終了する。
| 観点 | skill-mentor | scrum-master | gitlab-idd |
|---|---|---|---|
| ゴール数 | 1つ | 複数・独立 | 複数・分散 |
| セッション | 1セッションで完結 | 複数スプリント・永続化 | 非同期・複数マシン |
| 永続化 | なし | plan.json |
Git ブランチ（missions） |
| 実行主体 | 単一エージェント | 単一エージェント（並列可） | 複数マシン協調 |
| 開始速度 | 速い（Phase 1 スキップ可） | 低速（7フェーズ・承認あり） | 中速（ミッション設定必要） |
| 典型ユースケース | バグ修正・単機能追加・レビュー依頼 | 機能セット開発・プロジェクト立ち上げ | 複数PC分散処理・長期並行作業 |
エスカレーション基準
以下のいずれかに該当する場合は 即座に 該当オーケストレーターをユーザーに案内して終了する:
→ scrum-master へ:
- 独立した成果物が 3つ以上 ある
- タスク間に 依存関係 がある（A の完了が B の前提）
- 複数スプリント にまたがる見込み
- ユーザーが明示的にプロジェクト管理・バックログ管理を求めている
→ gitlab-idd へ:
- 複数マシン での協調作業が必要
- 非同期・長期間の並行作業が必要
起動プロトコル（必ず最初に実行）
copilot-instructions.md のセッション開始手順（スキル自動更新 → Copilot Memory 同期 → 記憶リコール）が未実行の場合は先に実行する。
# subagent-templates.md を読む（毎回読む。記憶に頼らない）
# ${SKILL_DIR}/references/subagent-templates.md
次に Phase 1 の振り分け判定を行う。
パス解決
このSKILL.mdが置かれているディレクトリを SKILL_DIR、その親ディレクトリを SKILLS_DIR とする。スクリプトは scripts/ から実行する。他スキルは名前で検索する: ${SKILLS_DIR}/[skill-name]/SKILL.md を優先し、見つからなければ利用可能なスキルディレクトリを横断して探すこと。
5フェーズ実行プロトコル
Phase 1 → Phase 2 → Phase 3 → Phase 4 → Phase 5
振り分け 確認* 計画 実行 レビュー
(* 省略可)
各フェーズは順番に実行する。スキップ禁止（Phase 2 を除く）。
Phase 1: 振り分け（Triage）
ゴール: このスキルで対応すべきか判断する
- 「オーケストレーター選択ガイド」のエスカレーション基準を確認する
- 条件に該当する場合は 即座にユーザーに案内して終了する
- 該当しない場合は Phase 2 へ進む
この判定は省略不可。 タスクがどれほど明確でも必ず実施する。
Phase 1 完了条件: このスキルで対応すると判断できたこと
Phase 2: タスク確認（Clarify）― 省略可能
ゴール: タスクを実行可能な「タスク定義」に変換する。タスクが明確なら省略する。
スキップ判定
以下を すべて 満たす場合は Phase 2 をスキップして Phase 3 へ進む:
- ゴール（何をしたいか）が明示されている
- 対象（ファイル・機能・範囲）が特定できる
- 完了条件が自明または推定可能
スキップする場合、初回メッセージからタスク定義を生成してユーザーに確認（1往復のみ）してから Phase 3 へ進む。
通常モード（スキップしない場合）
タスク種別の自動推定: 初回メッセージを受け取ったら、内容からタスク種別と概要を即座に推定して提示する。
理解: [バグ修正 / 機能追加 / リファクタリング / ドキュメント作成 / 技術調査 / デバッグ / その他]
概要: [1文で要約]
ユーザーが修正なく「はい」と答えた場合はその情報をタスク定義の「対象」に反映し、質問数を節約する。
プロセス:
- プロジェクトのコンテキストを探索する（ファイル構成・最近のコミット・既存ドキュメント）
recall_memory.pyで類似タスクの過去記憶を検索する- タスク種別を自動推定してユーザーに提示する
- 一問一答でタスクを明確化する（1メッセージに質問は 1つだけ、可能な限り選択肢形式で）:
- 何を達成したいか（ゴール）— 自動推定で確認済みの場合はスキップ可
- なぜやるのか（動機・背景）
- 完了をどう判断するか（完了条件）— 自明な場合はスキップ可
- 制約はあるか（技術・時間・影響範囲）
- 質問上限: 最大 7 問（超過する場合はユーザーに継続確認）
Phase 2 完了条件: 以下のタスク定義をユーザーが承認すること。否認の場合は壁打ちに戻る。
タスク定義:
ゴール: [何を達成するか]
動機: [なぜやるのか]
完了条件: [どうなったら完了か]
制約: [守るべき条件]
対象: [コード / ドキュメント / 設計 / デバッグ / 調査 / その他]
Phase 3: 計画（Plan）
ゴール: 最適なスキル構成と実行計画を決定する
- skill-selector のSKILL.mdを自身で読み込んで直接実行する（サブエージェント不要）
${SKILLS_DIR}/skill-selector/SKILL.mdを読み、手順に従って Phase 2 のタスク定義を渡す
- 推薦結果は skill-selector の出力契約どおりに
primary_skills/supporting_skills/execution_plan/notesの構造を保ったまま受け取る
- skill-selector の推薦結果をもとに実行計画を作成する
- 実行タスクとして並べるのは
primary_skills[].nameのみ supporting_skillsは構造を崩さず各タスクへ付帯情報として保持し、そのままサブエージェントへ渡す- レビューは Phase 5 で
agent-reviewerを直接起動する
依存関係グラフを付与する: 各スキルタスクに
depends_onを明記し、並列実行可能なグループを特定する実行計画（依存関係グラフ付き）: グループA（並列実行）: - skill-X: [理由] depends_on: [] - skill-Y: [理由] depends_on: [] グループB（グループA完了後・並列実行）: - skill-Z: [理由] depends_on: [skill-X]独立と判断する基準: あるスキルの出力を別のスキルが入力として必要としない場合は独立。 例: コードレビューとセキュリティレビューは同じ対象を並列で確認できる → 独立。 例: requirements-definer の出力を domain-modeler が使う → 依存。
（必要時）
council_hintを確認する: skill-selector の推薦結果notesにcouncil_hint:で始まる要素が含まれている場合、実行計画を確定する前にcouncil-systemを起動して実行戦略（スキルの実行順序・補助スキルの省略可否等）を合議する。SYNTHESIS 結論に従って依存関係グラフを調整してから次へ進む。コスト・時間制約がある場合はスキップしてよい。実行計画をユーザーに提示して承認を得る。修正要求があれば計画を調整する
Phase 3 完了条件: ユーザーが実行計画（依存関係グラフ含む）を承認すること
状態スナップショット: Phase 3 承認後、タスク定義と実行計画を ltm-use に一時保存する。 セッションが中断した場合、次のセッションで
recall_memory.pyを使い手動で計画を復元できる。python ${LTM}/save_memory.py --non-interactive --no-dedup \ --category "session-snapshot" \ --title "[ゴールの要約]" \ --summary "skill-mentor セッションスナップショット（Phase 3 完了）" \ --content "[タスク定義全文 + 実行計画全文]" \ --conclusion "セッション中断時の参照用。再開時に recall_memory で検索すること。" \ --tags session-snapshot,[タスク種別]
Phase 4: 実行（Execute）
ゴール: 計画に基づいてタスクを実行する
Phase 3 で確定した依存関係グラフを元に、グループ単位で実行する。
実行ルール
グループ内（独立タスク）→ 並列実行:
depends_on: []のタスクを同一グループにまとめ、単一メッセージで複数のrunSubagentを同時起動する- Phase 2 で得たユーザーの回答（動機・制約・好み）を各サブエージェントのコンテキストに含める
# 単一メッセージに並べて並列起動（例: グループAの2タスク）
[runSubagent: skill-X, コンテキスト付き]
[runSubagent: skill-Y, コンテキスト付き]
グループ間（依存タスク）→ 順次実行:
- 前グループがすべて完了してから次グループを起動する
- 前グループの出力（成果物・ファイルパス等）を次グループのコンテキストに渡す
エラー時の対応
グループ内の一部タスクが失敗した場合:
- 失敗タスクのエラー内容をユーザーに報告する
- 成功タスクの結果はそのまま保持する
- 対処方針の選択肢を提示する（リトライ / 別アプローチ / スキップ / 中断）
- ユーザーの判断に従う
各グループ完了後にユーザーへ進捗報告する（「グループA完了: X, Y → 次はグループB」）。
Phase 4 完了条件: すべてのグループの実行が完了すること
Phase 5: レビュー＆フィードバック（Review）
ゴール: 成果物の品質を検証し、ユーザーにフィードバックする
Step 1: agent-reviewer にレビューを委譲する
⛔ STOP —
runSubagentを今すぐ起動する成果物レビューは agent-reviewer が行う。skill-mentor は直接レビューしない。 読み終えたら即座に
runSubagentを呼び出すこと。理由や条件を考えてはならない。❌ 以下の理由によるスキップ・自己レビューは禁止:
- 「変更ファイルがないから」
- 「調査・確認のみだから」
- 「小さい変更だから」
- 「内容は把握済みだから」
スキップ条件: なし — レビュー必須
Phase 4 の成果物・変更ファイル・完了条件をそのまま agent-reviewer に渡す。perspective の決定と並列起動は agent-reviewer 自身が行うため、skill-mentor 側では考えない。
テンプレート: ${SKILL_DIR}/references/subagent-templates.md の「agent-reviewer サブエージェント起動時」を参照
Step 2: 結果集約・修正リトライ（最大5回）
agent-reviewer の集約結果を受け取り、以下の手順で判定する:
ステップ 2-1: 集約判定（最も厳しい結果を採用）
- 総合判定が LGTM → 成功確定（Step 3 へ）
- 総合判定が Request Changes → ステップ 2-2 へ
ステップ 2-2: 修正リトライ
agent-reviewer が返した指摘を統合して「修正リトライ時」テンプレートで修正サブエージェントを起動する:
### レビュー指摘（以下を必ず修正すること）:
- [指摘カテゴリ] 指摘 N 件: [要約]
- [指摘カテゴリ] 指摘 N 件: [要約]
修正完了後、再度 Step 1（多角レビュー）を実施する。 リトライ上限: 修正 → レビューのサイクルを最大5回繰り返す。5回目でも Request Changes の場合はユーザーに状況を報告して判断を委ねる。
ステップ 2-3: リトライ経過の記録
結果: 機能=LGTM / AIアンチパターン=RC(要約) / アーキテクチャ=LGTM → リトライ1回目: 全観点LGTM
Step 3: フィードバック収集
- タスク完了レポートをユーザーに提示する
- ユーザーフィードバック（良かった / 改善の余地あり / 問題があった）を収集する
- Phase 4 で使用した各スキルについて
git-skill-managerでスキルフィードバックを記録する - 価値ある知見があれば
save_memory.pyで記憶に保存する
Step 4: フォローアップ提案
全フェーズ完了後、今回のタスクに関連する次のアクションを1〜3件提案する。
- レビューの Warning 指摘から派生するタスク（例: 「テストカバレッジが低い → テスト追加」）
- タスクの動機から推測される関連作業（例: 「バグ修正 → 同種バグの横展開確認」）
- 長期的な改善候補（例: 「リファクタリング後 → アーキテクチャ設計書の更新」）
フォローアップ候補:
1. [タスク名]: [理由・背景 1文]
2. [タスク名]: [理由・背景 1文]
（scrum-master での管理が適切な場合はその旨を案内）
提案はあくまで任意。ユーザーが不要と判断した場合はそのままセッションを終了する。
Phase 5 完了条件: 全レビュー完了 + フィードバック収集
委譲ルール（鉄則）
Copilot では #tool:agent/runSubagent、Kiro では Run subagents to でサブエージェントを起動する。
自分で実行してはいけない処理:
- Phase 4: 各タスクの実行（例外なし。すべて runSubagent へ）
- Phase 5: レビュースキルの実行（可能な限り並列サブエージェント）
自身のエージェントで実行してよい処理:
- Phase 3: skill-selector のSKILL.mdを読んでスキル選定（サブエージェント不要）
重要: SKILL.md の内容をプロンプトに埋め込まない。ファイルパスだけ渡し、サブエージェント自身に読ませる。
エラーリカバリー
詳細な対処戦略 → references/error-recovery.md
優先順位
- リトライ（最大 2 回）: 一時的なツール失敗
- 代替アプローチ: 別スキル・別手順
- 部分完了で報告: 達成できた範囲を明示
- フォールバック手順: 手動手順のガイドを提示
Phase 別クイックリファレンス
| 状況 | 対処 |
|---|---|
| skill-selector がスキルを見つけられない | skill-selector に再試行を依頼する。それでも見つからない場合はユーザーに報告して判断を委ねる（skill-selector の「ギャップへの対応」手順に従う） |
| Phase 4 でスキル実行が 3 回失敗 | ユーザーに報告し選択肢を提示（リトライ / 別スキル / 手動対応 / 中断） |
| 依存タスクが失敗 | 後続タスクをスキップし部分完了として報告。ユーザーに継続可否を確認 |
| Phase 5 で全レビュー FAIL（2回リトライ後） | ユーザーに状況を報告し、判断を委ねる |
| セッションが中断 | ltm-use に未完タスク・完了タスクを保存。次セッションで再開ガイドを表示 |
| エスカレーション条件（3回失敗・破壊的操作・セキュリティリスク） | 自動処理を停止し、選択肢を提示してユーザー判断を求める |
ガードレール
| 制限 | 値 |
|---|---|
| 壁打ち質問数 | 最大 7 問（超過はユーザー確認） |
| レビュー再実行 | 最大 5 回 |
| 修正リトライ | 最大 5 回 |