mcpField
A
analyze

analyze

github.com/yeachan-heo開発40.6k81 回インストール4 日前に更新
リポジトリ

analyze について

Analyzeは、変更前にアーキテクチャ、バグ、性能、依存関係を調査するスキルです。関連ファイルの文脈を集めてarchitectエージェントに分析を依頼し、根拠を含む構造化された調査結果を返します。

主な機能

  1. 01アーキテクチャ、バグ、性能の調査
  2. 02依存関係と変更影響の分析
  3. 03複数ファイルからの文脈収集
  4. 04architectエージェントへの振り分け
  5. 05ファイル根拠付きの構造化結果

活用シーン

  1. 01接続切断の根本原因を特定
  2. 02モジュールの構造や動作を把握
  3. 03依存関係への変更影響を評価

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/yeachan-heo/oh-my-claudecode --skill analyze

インストール後、Claude Code で/analyzeを入力して読み込まれたか確認します。

詳細

Analyze は、アーキテクチャ、バグ、パフォーマンスの問題、依存関係を詳しく調査します。徹底的な分析のために architect Claude エージェントに処理を振り分け、根拠を添えた構造化された調査結果を返します。

<Use_When>

  • ユーザーが「analyze」「investigate」「debug」「why does」「what's causing」と言った場合
  • ユーザーが変更を加える前に、システムのアーキテクチャや動作を理解する必要がある場合
  • ユーザーがバグやパフォーマンスの問題の根本原因分析を求めている場合
  • ユーザーが依存関係の分析や、変更案の影響評価を必要としている場合
  • 複数のファイルを読み、それらを横断して推論する必要がある複雑な質問の場合 </Use_When>

<Do_Not_Use_When>

  • ユーザーがコードの変更を求めている場合 — 代わりに executor エージェントまたは ralph を使用します
  • ユーザーが受け入れ条件を含む詳細な計画を求めている場合 — 代わりに plan スキルを使用します
  • ユーザーが簡単なファイル検索やシンボル検索を求めている場合 — 代わりに explore エージェントを使用します
  • 1 つのファイルを読めば答えられる簡単な事実を尋ねている場合 — 直接読み取って回答します </Do_Not_Use_When>

<Why_This_Exists> 詳細な調査には、簡単な検索やコード変更とは異なるアプローチが必要です。分析タスクでは、幅広くコンテキストを収集し、複数ファイルを横断して推論したうえで、調査結果を構造化する必要があります。これらのタスクを architect エージェントまたは Codex に振り分けることで、計画や実行のワークフロー全体を使う負担をかけずに、適切な深さの分析を行えます。 </Why_This_Exists>

<Execution_Policy>

  • 徹底的な調査のため、分析は architect Claude エージェントに振り分けます
  • 根拠に基づく推論を可能にするため、architect エージェントを起動する前に必ずコンテキストファイルを収集します
  • 生の観察結果だけでなく、構造化された調査結果を返します </Execution_Policy>
1. **分析の種類を特定する**: アーキテクチャ、バグ調査、パフォーマンス、依存関係分析のいずれか 2. **関連するコンテキストを収集する**: 関連する主要なファイルを読み取るか、特定します 3. **分析エージェントに振り分ける**: `Task(subagent_type="oh-my-claudecode:architect", model="opus", prompt="Analyze: ...")` 4. **構造化された調査結果を返す**: 根拠、ファイル参照、実行可能な推奨事項を添えて分析結果を提示します

<Tool_Usage>

  • 主な分析ルートとして Task(subagent_type="oh-my-claudecode:architect", model="opus", ...) を使用します
  • 幅広い分析では、関連ファイルを特定してから architect に振り分けるため、まず explore エージェントを使用します </Tool_Usage>
ユーザー: 「WebSocket 接続が 30 秒後に切断される理由を分析して」 アクション: WebSocket 関連のファイルを収集し、コンテキストとともに architect に振り分け、具体的なファイル名と行番号を示した根本原因分析と、推奨する修正方法を返します。 適切な理由: 調査対象が明確で、根拠を含む構造化された出力です。 ユーザー: 「src/api/routes.ts から始まる依存関係の連鎖を調査して」 アクション: explore エージェントでインポートグラフを把握してから、影響分析のために architect に振り分けます。 適切な理由: 事実の収集には explore を、推論には architect を使用しています。 ユーザー: 「auth モジュールを分析して」 アクション: 「auth モジュールは認証を処理します」とだけ返します。 不適切な理由: 調査のない浅い要約です。モジュールの構造やパターン、潜在的な問題を調べ、ファイル参照を添えた具体的な調査結果を提示する必要があります。 ユーザー: 「パーサーのバグを修正して」 アクション: 分析スキルを実行します。 不適切な理由: これは分析の依頼ではなく、修正の依頼です。代わりに executor または ralph に振り分けます。

<Escalation_And_Stop_Conditions>

  • 分析の結果、コード変更が必要だと判明した場合は、調査結果を報告し、修正には ralph または executor の使用を推奨します
  • 分析範囲が広すぎる(「すべてを分析して」など)場合は、対象を絞るようユーザーに依頼します
  • Codex が利用できず、architect エージェントも失敗した場合は、収集したコンテキストを報告し、手動で調査する方法を提案します </Escalation_And_Stop_Conditions> <Final_Checklist>
  • 分析が具体的な質問または調査対象に対応している
  • 該当する場合、調査結果に具体的なファイル名と行番号が記載されている
  • バグ調査では、症状だけでなく根本原因が特定されている
  • 実行可能な推奨事項が提示されている
  • 確認済みの事実と仮説が区別されている </Final_Checklist>

タスク:{{ARGUMENTS}}

コメント