design-orchestration

設計オーケストレーション（メタスキル）

目的

アイデアを設計に落とし込み、設計をレビューし、検証済みの設計のみを実装に進めることを徹底します。

このスキルは設計を生成しません。 ほかのスキル間の進行を制御します。

---

運用モデル

これは創造的なスキルではなく、ルーティングと実施を徹底するスキルです。

次の事項を判断します。

• 次に実行すべきスキル
• エスカレーションが必要かどうか
• 実行が許可されているかどうか

---

制御対象のスキル

このメタスキルは、次のスキルを調整します。

• brainstorming — 設計の生成
• multi-agent-brainstorming — 設計の検証
• 後続の実装または計画スキル

---

起動条件

次の場合にこのスキルを起動します。

• ユーザーが新しい機能、システム、または変更を提案したとき
• 設計上の決定に重大なリスクが伴うとき
• 速度より正確性が重要なとき

---

ルーティングロジック

ステップ 1 — ブレインストーミング（必須）

検証済みの設計がない場合：

• brainstorming を起動します
• 次の成果物を必須とします。
  • 理解の確定
  • 初期設計
  • 決定ログの開始

これらの成果物なしに先へ進んではいけません。

---

ステップ 2 — リスク評価

ブレインストーミングの完了後、設計を次のいずれかに分類します。

• 低リスク
• 中リスク
• 高リスク

次のような要素を考慮します。

• ユーザーへの影響
• 元に戻せない度合い
• 運用コスト
• 複雑さ
• 不確実性
• 新規性

---

ステップ 3 — 条件付きエスカレーション

• 低リスク
  → 実装計画に進みます

• 中リスク
  → multi-agent-brainstorming を推奨します

• 高リスク
  → 実質的なレビューを必須とします。明示的な委任の許可がある場合に限り multi-agent-brainstorming を使用し、許可がない場合は、記録を残したうえで単一エージェントによるレビューを実施します

必須の実質的なレビューを、気づかれないように省略してはいけません。レビューの深さは、エージェントを起動したり、ユーザーのワークフローを上書きしたりする許可ではありません。

---

ステップ 4 — マルチエージェントレビュー（起動した場合）

multi-agent-brainstorming を実行する場合は、次を必須とします。

• 完了した理解の確定
• 現在の設計
• 決定ログ

次のことを許可してはいけません。

• 新たなアイデア出し
• スコープの拡大
• 問題定義の再開

認められるのは、批評、修正、決定の解決のみです。

---

ステップ 5 — 実行準備状況の確認

実装を許可する前に、次を確認します。

• 設計が承認されている（単一エージェントまたはマルチエージェント）
• 決定ログが完成している
• 主要な前提条件が記録されている
• 既知のリスクが認識されている

条件を満たさない場合：

• 実行をブロックします
• 適切なスキルに戻します

---

実施ルール

• 検証済みの設計なしに実装を許可してはいけません
• 必須レビューの省略を許可してはいけません
• 気づかれないようなエスカレーションやデエスカレーションを許可してはいけません
• 設計フェーズと実装フェーズを統合してはいけません

---

終了条件

このメタスキルは、次の条件を満たす場合に限り終了します。

• 次のステップが明示されていること、かつ
• 必須の先行ステップがすべて完了していること

終了時の選択肢：

• 「実装計画に進む」
• 「multi-agent-brainstorming を実行する」
• 「確認のため brainstorming に戻る」
• "レビュー済みの設計で最終判定が APPROVED、REVISE、または REJECT と報告された場合は、ワークフローを必ずその判定に応じて進め、選択した次のステップを明示してください。"

---

設計方針

このスキルの目的は次のとおりです。

• 適切な判断には時間をかける
• 適切な実行を迅速に進める
• 重大なミスを防ぐ

優れたシステムは早期に問題を検出します。 劣ったシステムは本番環境で問題を起こします。

このメタスキルは、前者を徹底するためにあります。

使用する場面

重要な機能やシステムに関する判断において、設計、リスク評価、実装準備状況のレビューが必要な場合に使用します。すでに承認済みの設計や、プロジェクトで必須とされているワークフローを尊重してください。範囲が限定された定型的な修正に、必要のない成果物を作成したり、ブレインストーミングを必須にしたりする必要はありません。

例

ユーザーの依頼：

@design-orchestration を使ってこのインターフェースをレビューし、影響が最も大きい設計上の問題を特定したうえで、実装可能な改善案を提案してください。

制限事項

• ルーティングスキルによって、実行、公開、支出、委任の権限が付与されることはありません。Understanding Lock／Decision Log は、実際のプロジェクト成果物または簡潔な証拠として解釈してください。創作すべき不足ツールとして扱ったり、許可された作業を繰り返し中断する理由にしたりしないでください。
• 出力を、環境固有の検証、テスト、専門家によるレビューの代替として扱わないでください。
• 必要な入力、権限、安全上の境界、成功基準が不足している場合は、作業を中断して確認を求めてください。