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

Claude Code（CC）、Superpowers（SP）、oh-my-claudecode（OMC）、Everything Claude Code（ECC）の4ツールは、それぞれ単独でも機能します。しかし適切に組み合わせると、各ツールの弱点を補完し合い、開発効率が大幅に向上します。

この記事では3つの実践シナリオを通じて、ツール連携の具体的なパターンを解説します。

シナリオ1: 新機能実装（フルスタック）

要件定義からコミットまでを一気通貫で進める、フルスタック機能実装のワークフローです。

ステップ1 -- 要件整理

Superpowers の brainstorming スキルで要件をクリスタライズします。このスキルは批判的思考で仮定を洗い出し、要件の曖昧さを排除します。

「ユーザーの行動履歴をダッシュボードに表示する機能」をブレインストーミングしたい

superpowers の brainstorming スキルを起動（「〜をブレインストーミングしたい」「〜の設計を検討したい」などの発話で自動発火）。実行すると、SP が複数の観点（UX、パフォーマンス、プライバシー、スケーラビリティ）から問いを投げかけ、要件の輪郭を明確にします。

ステップ2 -- 実装計画

要件が固まったら、SP と ECC の計画系スキルで実装計画を作成します。

実装計画を作って

superpowers の writing-plans スキルを起動（「計画を作りたい」等の発話で自動発火）。SP writing-plans が人間が読める計画書を生成し、ECC blueprint がアーキテクチャ上の懸念点（依存関係、技術負債、リスク）を付記します。

> /blueprint

ステップ3 -- 並列実装

OMC ultrawork で並列エージェントを起動し、計画を同時並行で実行します。ECC coding-standards スキルが各エージェントのコーディング規約への準拠を保証します。

> ultrawork

OMC がタスクを自動分解し、独立したサブタスクをそれぞれ別エージェントにディスパッチします。フロントエンドとバックエンドの実装が同時進行します。

ステップ4 -- TDD

実装と並行して、ECC と SP の TDD スキルでテストを整備します。

> /tdd-workflow

ECC tdd-workflow がテストファーストの進行を管理し、superpowers の test-driven-development スキルがセッション全体にその規律を強制します（「TDD で進めたい」等の発話で自動発火）。

ステップ5 -- コードレビュー

実装完了後、SP と ECC の両方でレビューを実施します。

コードレビューをお願いしたい

superpowers の requesting-code-review スキルを起動（「コードレビューをお願いしたい」等の発話で自動発火）。SP requesting-code-review がレビュアーへの依頼フォーマットを整え、ECC code-reviewer エージェントが自動レビューを実行します。

> /code-review

ステップ6 -- 完了検証とコミット

SP の検証スキルで完了条件を満たしているか確認してからコミットします。

実装が完了しました

superpowers の verification-before-completion スキルを起動（「完了しました」「done」「finished」等の発話で自動発火）。ビルド、テスト、型チェック、lint がすべてパスしていることを確認後、コミットします。

シナリオ2: バグ修正（本番障害）

本番で発生した緊急バグへの対応ワークフローです。調査から修正、検証、デプロイまでを最速で進めます。

ステップ1 -- 根本原因の特定

CC の /doctor コマンドで環境状態を確認し、OMC trace で実行トレースを分析します。

> /doctor
> /oh-my-claudecode:trace

/doctor が設定・依存関係・権限の異常を検出し、OMC trace がエージェントの実行履歴からエラーの発生パターンを特定します。

ステップ2 -- 修正

ECC build-error-resolver と SP systematic-debugging を組み合わせて修正を進めます。

> /build-fix

ECC build-error-resolver（/build-fix）がビルドエラーを自動修正します。「このエラーをデバッグしたい」と発話すると、superpowers の systematic-debugging スキルが自動発火し、根本原因にアプローチするデバッグの手順を強制します。表面的な対処ではなく、原因の除去を優先します。

ステップ3 -- 検証

ECC verification-loop と OMC ultraqa で修正を多面的に検証します。

> /verify
> ultraqa

ECC verification-loop（/verify）がビルド・テスト・lint の連続検証ループを実行し、OMC ultraqa がエッジケースを含む追加検証を行います。

ステップ4 -- 隔離デプロイ

CC の git worktree 機能で隔離されたブランチを作成し、SP finishing-a-development-branch でブランチのクローズ手順を踏みます。

# worktreeで隔離作業

「ブランチを完了したい」と発話すると、superpowers の finishing-a-development-branch スキルが自動発火します。SP のスキルがブランチクローズ前のチェックリスト（リベース、テスト、レビュー依頼）を強制し、急いでいるときの手順スキップを防ぎます。

シナリオ3: 大規模リファクタリング

複数ファイルにまたがる大規模リファクタリングのワークフローです。影響範囲の特定から段階的実行、品質保証まで体系的に進めます。

ステップ1 -- 影響範囲の分析

OMC architect エージェントと CC の Grep / Glob でコードベース全体を把握します。Claude Code に次のように依頼すると、内部的に architect エージェント（Opus）が起動し、アーキテクチャ上の問題点を深い推論で列挙します。

> OMC の architect エージェントに「このコードベースの依存関係グラフを分析して」と依頼して

多角的レビューが必要な場合は /oh-my-claudecode:ccg で Claude / Codex / Gemini の3モデル同時検討に切り替えられます。

影響を受けるファイルの網羅的な列挙は CC の Grep / Glob で進めます。

注意: ECC search-first スキルは「影響ファイルの特定」用途ではなく、実装前に既存ライブラリ・ツール・パターンを事前リサーチする Research-before-coding ワークフローです。依存関係グラフ分析や影響範囲調査には適していません。このステップでは起動しないでください。

ステップ2 -- 計画と合意形成

SP writing-plans で詳細な実行計画を作成し、OMC ralplan で計画の妥当性を検証します。

実装計画を作って

superpowers の writing-plans スキルを起動（「計画を作りたい」等の発話で自動発火）。

> ralplan

ralplan は計画に対して批判的なレビューを行い、見落としや矛盾を指摘します。この段階で計画を固めることで、実行中の手戻りを防ぎます。

ステップ3 -- チーム編成と実行

OMC team でエージェントチームを編成し、リファクタリングを並列実行します。/team N:executor "タスク" の形式で N 体の executor を起動する標準構文が使えます。

> /team 4:executor "APIレイヤーをリファクタリングして。src/api/** を担当"

各 executor が独立したコンテキストで作業し、OMC がファイル競合を防ぎながら進捗を管理します。担当ファイルの境界をプロンプトで明示することで、同一ファイルへの同時編集を防止します。外部 CLI ワーカー（Codex / Gemini）を混在させたい場合は omc team N:codex "..." / omc team N:gemini "..." も利用できます。

ステップ4 -- 品質保証

ECC security-scan と SP verification-before-completion で最終品質を確認します。

> /security-audit

ECC のセキュリティスキャンがリファクタリングによる脆弱性の混入を検出します。「全作業が完了しました」と発話すると、superpowers の verification-before-completion スキルが自動発火し、すべての完了条件を確認します。

ツール選択ガイド

どのツールを組み合わせるかは、タスクの規模と複雑さで決まります。

場面	推奨ツール	理由
小規模修正（1-2ファイル）	CC 単体	オーバーヘッドなし
計画が必要な実装	CC + SP	構造化されたワークフローと規律強制
並列実行が有効な実装	CC + SP + OMC	チームパイプラインと並列ディスパッチ
多言語・大規模プロジェクト	CC + SP + OMC + ECC	言語別レビューアーと網羅的リソース活用
本番障害の緊急対応	CC + OMC + ECC	トレース分析と自動修正の速度優先
セキュリティが重要な変更	CC + ECC + SP	セキュリティスキャンと検証の多重化

ツール選択の判断フロー

タスクが明確で1-2ファイルの変更？
  YES → CC 単体
  NO  ↓

計画と設計の検討が必要？
  YES → SP を追加
  NO  ↓

複数タスクの並列実行が可能？
  YES → OMC を追加
  NO  ↓

多言語対応・専門エージェント・追加コマンドが必要？
  YES → ECC を追加

共通原則

3つのシナリオを通じて共通するパターンがあります。

計画フェーズに時間を投資する: SP のブレインストーミングと計画スキルは、実装中の手戻りを大幅に減らします。急いでいるときほど計画を省略したくなりますが、本番障害でも調査フェーズを丁寧に行うことが最速の解決につながります。

ツールの重複機能は明示的に選択する: TDD、コードレビュー、並列実行など、複数ツールが同じ機能を提供している場合は、どちらのスキルを使うかを明示します。自動検出に任せると意図しない方が起動することがあります。

検証は別レーンで実施する: 実装エージェントと検証エージェントは同じコンテキストで動作させません。OMC ultraqa や SP verification-before-completion を独立したパスで実行することで、実装バイアスを排除した客観的な検証が得られます。

あわせて読む

Superpowers + OMC + ECC を横断的に組み合わせる - ツール共存の基本的な仕組み
oh-my-claudecode の Team Pipeline でステージド実行する - チームパイプラインの詳細
TDD ワークフローを Claude Code で実践する - テスト駆動開発の実践
エージェントチームで大規模タスクを並列遂行する - チーム編成の詳細

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