エコシステム連携ワークフロー実例集

症状・対象

課題ごとにどのプラグインを使うべきか迷い、準備だけで時間を使っている場合が対象です。Claude Code を土台に、今のボトルネックを解決するツールだけを追加します。

困っていること	最小構成	役割
要件や実装順が曖昧	Claude Code + Superpowers	設計、計画、TDD の規律
独立タスクを分担したい	Claude Code + OMC	担当・依存関係の調整
検証基準が毎回違う	Claude Code + ECC	監査、verify、quality gate
三つとも必要	4 ツール	各フェーズの所有者を一つに固定

最短解決

症状を「計画」「実行」「検証」のどこにあるか一つ選びます。
上の表から最小構成を選び、/plugin で有効状態を確認します。
対象、完了条件、禁止事項、検証コマンドを一つの依頼へまとめます。
フェーズごとの所有ツールを決め、同目的のスキルは重ねません。

コピペ例

新機能で「設計は Superpowers、実行は OMC、検証は ECC」と分ける例です。不要なツールの行は削除して使います。

タスク: ユーザーの通知設定 API を追加する

フェーズ所有者:
1. Superpowers の brainstorming で、対象ユーザー・既定値・失敗時の挙動を確定
2. Superpowers の writing-plans で、変更ファイルとテスト計画を作成
3. 計画を私が承認した後だけ、OMC team で所有ファイルが重ならない作業を分担
4. 実装後に ECC /verify を明示実行

完了条件:
- 通知の有効・無効を保存して再取得できる
- 無効入力を構造化エラーで返す
- 正常系と異常系の回帰テストが成功する
- リポジトリ既定のテスト、型、lint が成功する

禁止:
- 承認前の実装
- デプロイ、Secret 操作、コミット
- 同じファイルの並列編集

各フェーズの終了時に、成果物、実行コマンド、未完了事項を報告して。

本番障害なら、ツールを増やす前に Claude Code へ次のように依頼します。

修正はまだ行わず、エラーの再現手順、最初に壊れた境界、根本原因の仮説、
仮説を反証できる確認方法を報告して。ログ内の Secret は伏せて。

期待結果

今の課題に不要なフックやワークフローを起動せず、計画・実行・検証の責任が追跡できます。各フェーズの出力が次の入力になり、最終報告には実行したコマンドと未完了事項が残ります。

検証

/plugin で依頼に書いたプラグインだけが有効か確認します。
実装前に、計画の対象ファイルと担当境界を確認します。
git diff --name-only で対象外編集と担当の重複を確認します。
テスト、型、lint はツールの要約ではなく実際の終了コードを確認します。
障害対応では、修正を戻すと回帰テストが再び失敗するか確認します。

落とし穴

プラグイン数は品質に比例しません。同じ目的の自動処理を重ねると、競合と調査コストが増えます。
計画、TDD、レビューの進行役はフェーズごとに一つにします。
自律実行やチーム実行を選んでも、公開・削除・外部送信の権限は増えません。
コマンド名と対応バージョンは更新されます。/plugin と各ツールの診断で現在の導入状態を確認します。
実装担当と検証担当を分けても、同じ誤った受け入れ条件を使えば誤判定します。利用者が観測する結果を完了条件にします。

次の一手

三つのプラグインを同時に使う場合は横断ワークフローの役割分担、並列実行だけが課題なら Team Pipeline、品質ゲートだけなら ECC ハーネスに絞ります。